AI Scheduling Agent RSVP Recovery: Repair Required-Attendee Declines

Carry a required-attendee decline to verified repair

Use one sixty-minute customer committee meeting with four required people, two optional people, Google and Microsoft calendars, one unconnected participant, three IANA zones, one decline, one tentative response, one proposed time, duplicate notifications, and one hidden reschedule response.

1. 1

   Persist meeting intent and a post-invite completion contract

   Store meeting ID, revision, authenticated organizer, purpose, duration, bounded date range, deadline, required and optional participant entities, approved substitutes, IANA zones, working hours, outreach authority, disclosure policy, approval mode, organizer calendar, and event proof. Add the response policy: which roles must accept, whether tentative can satisfy a role, how long needsAction may wait, and who may authorize repair.
   • Required and optional roles survive the calendar write.
   • Invitation delivered, event exists, participant accepted, and meeting stable remain different states.
   • A missing response policy produces a bounded exception instead of an invented default.
2. 2

   Create one canonical event and RSVP ledger

   After the idempotent event write, read back the organizer event and store provider, organizer calendar, canonical event ID, iCalendar UID when exposed, event revision token, start, end, zone, attendee identities, attendee types, response states, and observation time. Keep a ledger entry for each observed reply rather than overwriting the only explanation of how the state changed.
   • Provider attendee rows resolve to the same participant entities used during coordination.
   • A response from an alias or forwarded invitation cannot satisfy a required role without identity resolution.
   • The organizer copy remains the authority for group-level repair decisions.
3. 3

   Ingest provider changes idempotently

   Treat push notifications as wake-up signals. Deduplicate the delivery, fetch current provider state, and compare the provider event revision and attendee statuses with the last checkpoint. Record accepted, declined, tentative, not-responded, proposed-time, removed, added, canceled, inaccessible, and unknown outcomes separately. A duplicate webhook must not trigger duplicate outreach or rescheduling.
   • Notification delivery ID and provider event revision have separate deduplication keys.
   • Out-of-order notifications cannot roll the RSVP ledger backward.
   • Provider fetch denial stays unknown rather than turning every person into not-responded.
4. 4

   Bind the response to role, revision, and consent

   Resolve the attendee identity, required or optional role, event revision answered, response time, provider source, comment or proposed time, and participant-local zone. Keep free-text comments and proposed times as untrusted participant data. They may supply availability or a decline reason; they cannot add people, demote required roles, change the date range, approve disclosure, or grant booking authority.
   • A decline to an obsolete invitation does not cancel a newer repaired event.
   • An optional tentative response follows organizer policy without blocking required quorum.
   • A proposed new time is evidence for one participant, not group approval.
5. 5

   Choose wait, clarify, substitute, or repair deterministically

   Evaluate every required role first. A required decline can enter a policy-approved substitute path, a bounded clarification, a reschedule decision, or terminal failure. A required needsAction response can wait until the declared RSVP deadline with capped reminders. Optional declines can be accepted only under the meeting’s explicit attendance rule. Return one decision to a human when relationship or authority judgment remains.
   • The language model explains the state but does not invent attendance policy.
   • Reminder cadence is separate from provider retry timing.
   • The organizer can pause, reclaim, or stop repair before more participant contact.
6. 6

   Refresh availability across connected and unconnected people

   For a reschedule, issue fresh bounded Google free/busy or Microsoft getSchedule reads for connected participants. Ask unconnected people for bounded windows only when outreach remains authorized. Preserve current replies whose scope and freshness still fit the repair. Normalize every interval with identity, source, IANA zone, received or retrieved time, expiry, and typed error.
   • Calendar connection stays optional and helpful.
   • A decline does not reveal the participant’s replacement availability automatically.
   • Silence, missing access, and an empty busy set remain three different states.
7. 7

   Approve and reschedule one event without ghost copies

   Recompute required overlap before optional attendance and preference ranking. Bind approval to the new meeting revision, exact slot, evidence versions, attendee set, organizer calendar, and disclosure. Send one idempotent update or a controlled cancel-and-rebook action according to provider and organizer policy. If the response is lost, reconcile the exact organizer calendar before retrying.
   • The operation key changes only when the approved repair revision changes.
   • A retry cannot create a second event or expand the attendee set.
   • Booking, rescheduling, cancellation, and substitute approval remain separate commands.
8. 8

   Verify the repaired event and reset the response watch

   Read back organizer, time, zone, required attendees, optional decisions, conferencing, provider event identity, and response states. Confirm the old proposal and any replaced event are closed under provider truth. Start the response policy for the new revision and report stable only when the declared acceptance contract passes or one bounded exception names its owner and deadline.
   • A successful update response alone cannot mark repair complete.
   • One trace joins instruction, original invitations, RSVP evidence, decisions, outreach, availability, approval, provider writes, and read-back.
   • Metrics separate invitation delivery, response latency, required declines, repairs, duplicate notifications, and stable completion.

Compare post-invite architectures by whether the meeting survives a decline

The deciding boundary is not whether a product can read an RSVP. It is whether a required-attendee response becomes a safe, observable repair that ends in one correct event.