Meeting Rescheduling API for AI Agents: Repair a Booked Group Without Ghost Events

Build a post-booking repair path in eight steps

Use one sixty-minute implementation review with three required people, one optional observer, mixed Google and Microsoft calendars, and one unconnected customer. The event is already booked. A required participant becomes unavailable, one old invitation reply arrives during repair, and the first update response times out.

1. 1

   Parse change intent before touching the event

   Accept a typed command with authenticated actor, meeting ID, expected revision, requested action, reason class, allowed date range, duration, attendee change, location change, notification policy, approval mode, and idempotency key. Separate move, change_duration, replace_participant, cancel, and cancel_and_rebook. Natural-language wording can propose the command; policy code must authorize its scope.
   • Calendar edit permission does not prove business authority to move or cancel the meeting.
   • A request to change one field cannot silently rewrite participants, duration, or disclosure.
   • Ambiguous scope returns one clarification instead of an event write.
2. 2

   Load the canonical meeting and its people contract

   Read the durable scheduling record, current provider event, organizer, purpose, duration, IANA zones, required and optional participants, substitutes, outreach consent, connected free/busy sources, conversational windows, approvals, invitation state, and prior operations. Treat the provider event as a side effect linked to the record, not the only source of truth.
   • The agent can distinguish the canonical event from stale duplicates or copied holds.
   • Required and optional roles survive the mutation unless the authorized command changes them.
   • Private event titles and unrelated calendar details stay outside the matching record.
3. 3

   Open one repair revision and pause competing writers

   Create a repair revision with owner, cause, dependency set, expiry, and terminal states. Invalidate proposals derived from the old event time. Pause reminder, webhook, and booking workers that could act on the prior revision. Late participant replies remain evidence only if identity, meeting, scope, time zone, consent, and freshness still fit the repair.
   • Two workers cannot open competing repairs for the same canonical meeting.
   • An old approval cannot authorize a new slot or participant set.
   • A late reply cannot restore a proposal that the organizer withdrew.
4. 4

   Refresh only the availability the change made stale

   Read current approved Google and Microsoft free/busy for every required person affected by the new window. Ask the unconnected customer for bounded replacement windows through the approved channel when existing evidence no longer covers the range. Normalize source, retrieval or reply time, IANA zone, consent, expiry, and provider error. Silence and missing access remain unknown.
   • Valid participant windows outside the changed scope are preserved rather than requested again.
   • Optional attendance is ranked only after every required person passes.
   • Calendar connection remains helpful and optional, not a prerequisite for participation.
5. 5

   Choose the smallest repair that satisfies intent

   Intersect required availability, then apply working hours, buffers, deadline, location, notice, and approved substitute rules. Compare move-in-place, duration reduction, participant substitution, and cancel-and-rebook under explicit policy. Return one accountable proposal with local times, participant roles, evidence versions, expiry, provider action, and the human decision still required.
   • The agent does not replace a required person because a smaller optional set is easier to book.
   • A duration or substitute exception names the authority that can approve it.
   • No-overlap returns a bounded date, duration, attendee, or cancellation decision.
6. 6

   Bind approval and commit one provider mutation

   Bind approval to repair revision, exact slot, duration, required people, optional decision, organizer calendar, disclosure, and provider action. Re-check current required evidence. Use a stable operation key and provider precondition where supported. Prefer updating the canonical event when identity should remain; use cancel-and-rebook only when policy and provider behavior require a new event.
   • Repeated approval or queue delivery returns the existing operation result.
   • The old event is not deleted before the replacement path has an authorized recovery plan.
   • Notification scope is explicit for changed, removed, and added participants.
7. 7

   Reconcile timeouts and partial provider state

   When an update or delete response is lost, mark the operation uncertain. Read provider state by stored event and correlation identifiers before retry. If a replacement was created but old cancellation failed, quarantine both IDs, stop reminders, and return one recovery action. Never report a clean reschedule from a successful HTTP response alone.
   • Retry follows reconciliation, not panic.
   • Every side effect records attempted payload, provider result, revision, and safe next action.
   • A partial repair stays visible until one canonical event is proven.
8. 8

   Verify invitations and close the old path

   Read back the final event and verify time, zone, organizer, location, every required participant, optional decision, cancellation state of any superseded event, and invitation delivery or response state available from the provider. Close old proposals and reminders, publish one completion result, and preserve a redacted audit trail for later recovery.
   • One canonical event remains active for the meeting intent.
   • Every participant receives the current invitation or a precise exception is assigned.
   • Completion is the verified repaired meeting, not the update request.

Compare post-booking change paths by what they finish

The useful API does more than mutate an event. It repairs the people contract and proves which invitation is current.