AI Scheduling API: Build Recurring Group Meetings as a Series of Decisions

Build recurring scheduling execution in eight steps

Use one monthly customer council with three required people, two optional specialists, Google and Microsoft calendars, one adviser who will not connect a calendar, and a six-month planning horizon. The local-time preference is 10:00 AM New York, but every occurrence must survive daylight saving changes, participant corrections, and one canceled month.

1. 1

   Separate series intent from occurrence state

   Create a series_intent with authenticated organizer, purpose, duration, recurrence rule, start and end boundary, anchor IANA time zone, local-time policy, required and optional roles, approved substitutes, working-hour rules, outreach policy, approval mode, organizer calendar, and cancellation authority. Give every occurrence its own ID, revision, attendee resolution, evidence, proposal, approval, provider event, and terminal state.
   • The recurrence rule generates candidates; it does not prove participant availability.
   • Required and optional status can be versioned without rewriting past occurrences.
   • Book, update, skip, cancel-one, and cancel-series are separate authorized actions.
2. 2

   Open a bounded planning horizon

   Materialize only the next approved window, such as the next three occurrences, rather than coordinating an endless series. Record the horizon owner, generation time, source series revision, and renewal point. Freeze completed occurrences. When the series policy changes, invalidate only future occurrence work derived from the old revision.
   • A horizon cannot extend beyond the organizer’s approved end boundary.
   • Past invitations remain auditable and immutable in the coordination ledger.
   • A worker can regenerate the same occurrence IDs without creating duplicate work.
3. 3

   Collect consent and availability at the right cadence

   Read approved Google and Microsoft free/busy for connected participants. Ask the unconnected adviser for bounded windows through an approved channel, with disclosed purpose, local-time wording, response deadline, reminder cap, and opt-out path. State whether one reply covers one occurrence, the current horizon, or a declared date range. Never treat an old ‘mornings work’ message as permanent consent or permanent availability.
   • Possessing a recurring attendee address does not grant unlimited outreach.
   • A participant can correct a zone, withdraw a window, decline one date, or leave the series.
   • Missing access, silence, and expired evidence are not open time.
4. 4

   Resolve every occurrence against current people

   For each generated date, join participant identity, required or optional role, connected free/busy, bounded reply windows, source, freshness, consent, provider error, and IANA zone. Intersect every required person first. Score optional attendance and preferences only after the hard set passes. If the role owner changes, reopen that occurrence instead of editing a name after the slot is selected.
   • One valid month does not make the same slot valid next month.
   • Optional attendance can improve a slot but cannot make a failed quorum look complete.
   • Private event titles and unrelated attendees stay outside the matching record.
5. 5

   Make daylight saving policy explicit

   Choose whether the series preserves organizer wall-clock time, participant working-hour policy, a fixed UTC instant, or a fresh slot search per occurrence. Store the anchor IANA zone and the resolved instant for each event. If a transition pushes a required participant outside approved hours, return a bounded exception rather than silently moving the meeting or accepting the violation.
   • Time-zone abbreviations never replace IANA zones in durable state.
   • Every proposal shows local times for the people who must approve it.
   • A DST change invalidates derived slots when the working-hour policy no longer passes.
6. 6

   Commit the series without losing occurrence identity

   Bind approval to the series revision, materialized occurrence set, exact attendee roles, slots, organizer calendar, and invitation wording. Use a series-level operation key plus one stable idempotency key per occurrence. Persist provider series and instance identifiers, correlation IDs, attendee notification scope, and the exact event state read back after each write.
   • A repeated batch returns existing occurrence results instead of creating another series.
   • Provider recurrence IDs are mapped to internal occurrence IDs before side effects begin.
   • A partial batch cannot be reported as a completed horizon.
7. 7

   Repair one occurrence before touching the series

   When a participant declines, a calendar changes, or a provider write times out, classify the smallest broken unit. Reconcile uncertain provider state before retry. Preserve the series policy and unaffected occurrences. Reopen only the stale people and evidence, obtain any required approval, then update or replace the canonical instance according to provider rules.
   • A one-date exception cannot cancel or move the whole series by accident.
   • Cancel-one and cancel-future operations require explicit scope confirmation.
   • Error responses name occurrence, revision, side-effect state, owner, and safe next action.
8. 8

   Observe completion at series and occurrence levels

   Emit traces for horizon generation, outreach, replies, availability reads, DST resolution, proposals, approvals, booking attempts, reconciliation, updates, invitation verification, skips, and human reclaim. Mark each occurrence complete only after the final event, time zone, required attendees, optional decision, and invitation state are read back. Report series health as a rollup, not a substitute for occurrence proof.
   • Operators can see which future occurrence is waiting and why.
   • Logs redact private calendar and message content while preserving decision evidence.
   • The terminal result is verified invitations, an authorized skip, or a bounded exception.

Compare recurring scheduling by the work each layer owns

The deciding question is not whether a tool can repeat an event. It is whether current people, consent, availability, exceptions, and invitations are carried to completion for every date.