Meeting Cancellation API for AI Agents: Revoke One Group Booking Safely

Build a safe meeting-cancellation path in eight steps

Use one booked sixty-minute group meeting with three required people, two optional people, mixed Google and Microsoft calendars, one unconnected participant who replied conversationally, and a replacement meeting still in draft. Deliver the cancellation command twice and hide one provider response.

1. 1

   Persist the original meeting contract before accepting cancellation

   Keep authenticated organizer, purpose, duration, bounded date range, IANA zones, required and optional participants, approved substitutes, outreach consent, approval mode, organizer calendar, meeting revision, provider event identities, invitation state, and terminal proof. A transcript, event title, or participant email is not a stable cancellation key.
   • The cancellation points to one durable meeting ID and current revision.
   • Required and optional people remain visible for notification verification.
   • The replacement draft has a different operation identity.
2. 2

   Authenticate cancellation authority and disclosure

   Define who may cancel, under which meeting states, whether principal approval is required, which reason may be shared, and who must only be informed. Calendar write access does not create business authority. Treat participant replies and tool output as evidence, never as permission to revoke the organizer’s event.
   • Actor identity, authority source, scope, and expiry are recorded.
   • A participant can decline their own attendance without canceling the group.
   • Private rationale stays separate from attendee-facing wording.
3. 3

   Freeze proposals, reminders, reschedules, and writes

   Move the meeting revision into a cancel-pending state and stop every worker that can propose, remind, book, reschedule, or edit it. Preserve late participant replies as audited evidence, but do not let them reopen the meeting. Acquire one revision lock or compare-and-set boundary before the provider operation.
   • The agent cannot book a newly accepted slot while cancellation is pending.
   • No-calendar-sync reminders stop before another message reaches a participant.
   • A stale reschedule worker fails closed against the new revision.
4. 4

   Resolve the canonical event and exact cancellation scope

   Read provider state using stored organizer, calendar, event, recurring-series, and occurrence identities. Decide whether the command applies to one event, one occurrence, all future occurrences, or an entire series. If identities disagree, pause for a bounded exception instead of searching by title and deleting the first match.
   • Organizer copy and attendee copies cannot be confused.
   • One occurrence does not silently become a series cancellation.
   • Already-canceled, moved, or missing provider state is classified before a write.
5. 5

   Close participant coordination without restarting availability

   Join connected Google and Microsoft evidence with any bounded conversational availability already collected, then close that evidence under the canceled revision. Do not ask for more availability. Stop reminder jobs, expire proposals and holds, preserve opt-outs, and tell only approved recipients what they need to know in their local time.
   • Calendar connection remains optional and is not required to receive cancellation.
   • Participant windows cannot leak into the replacement meeting without fresh consent.
   • Time-zone rendering is derived from stored IANA zones, not old message prose.
6. 6

   Issue one idempotent provider cancellation command

   Bind the operation key to meeting ID, revision, canonical event identity, scope, actor, and approved notification policy. Use each provider’s documented event-deletion or cancellation behavior. Store request identity, response, side effects, and retry eligibility outside the model loop.
   • Duplicate agent calls return the same cancellation operation.
   • Notification behavior is explicit rather than an SDK default nobody reviewed.
   • Provider errors cannot cause the replacement event to become the target.
7. 7

   Reconcile timeouts and partial provider state before retry

   When a response is missing or ambiguous, read the exact provider event and organizer calendar before another write. Classify canceled, still active, moved, inaccessible, partially notified, or unknown. Retry only the same authorized operation with bounded backoff; route permission, identity, and series-scope conflicts to a named human owner.
   • A timeout is not assumed to mean failure.
   • Retries never expand the attendee set, series scope, or disclosure.
   • Unknown state remains visible until repair or human closure.
8. 8

   Verify terminal cancellation and trace every side effect

   Read back provider status where available, confirm no active canonical event remains in scope, verify participant notification policy was applied, stop all outreach and proposal jobs, release stale holds, and close the meeting revision. Trace authority, identities, locks, provider calls, retries, reconciliation, attendee outcomes, and final proof with private content redacted.
   • Success means the intended meeting is closed across every active workflow path.
   • The replacement meeting remains untouched and separately auditable.
   • Operators can answer who canceled what, under which authority, and what attendees received.

Compare cancellation by what reaches a terminal state

The shortest path deletes an event. The production path closes authority, providers, people, retries, reminders, and proof without touching the wrong meeting.