How to Build an AI Scheduling Agent That Actually Books Group Meetings

The eight-part AI scheduling agent architecture

Build the coordination path before you pick a model or calendar provider. The agent needs a durable meeting record, deterministic policy, provider adapters, participant messaging, and a commit boundary. Natural-language reasoning sits around that system. It should not replace it.

1. 1

   Translate the instruction into a meeting-intent record

   Start with a typed record, not a prompt transcript. Store an organizer, duration, date window, preferred windows, excluded windows, meeting time zone, location or video requirement, booking deadline, and an explicit authorization mode. Split attendees into required and optional. Give the record a stable meeting_request_id before the first calendar call or participant message.
   • Reject an empty required-participant list.
   • Ask for clarification when duration, date window, or organizer authority is missing.
   • Preserve the original instruction for audit, but run the workflow from typed fields.
2. 2

   Normalize identity, locale, and time zones

   Resolve each participant to an email address or approved conversational identity. Store an IANA time-zone name when known and keep API timestamps in an RFC 3339 form. Never treat a numeric UTC offset as a permanent time zone; daylight-saving transitions will eventually make the agent wrong. Mark unknown locale or working hours as missing data rather than inventing them.
   • Keep the organizer’s stated time zone separate from each participant’s display zone.
   • Record the source of every identity and time-zone value.
   • Recompute candidate slots when a participant corrects their zone or working hours.
3. 3

   Resolve access and consent per participant

   For each person, decide whether the agent can read connected free/busy, must request availability, or must stop for approval. Ask only for the calendar permission needed by the job. Google Calendar exposes a free/busy query, and Microsoft Graph exposes getSchedule; neither requires copying private event titles into the scheduling record. Consent is a state transition, not a checkbox hidden in onboarding.
   • Keep private event details out of logs and model context.
   • Store access decisions separately for Google, Microsoft, and conversational fallback.
   • Give participants a path to decline, correct, or revoke access.
4. 4

   Fetch connected free/busy through provider adapters

   Use one internal availability shape even though Google and Microsoft return different payloads. Convert busy intervals into a canonical time line, attach provider and retrieval time, and keep provider errors with the participant record. A partial provider response is not an empty calendar. It is incomplete evidence and must not create a false open slot.
   • Bound the query window and duration before calling providers.
   • Cache only inside a short, explicit freshness window.
   • Treat throttling, expired credentials, and permission denial as different recovery cases.
5. 5

   Collect missing availability conversationally

   Calendar sync should improve the path, not become an admission ticket. If a participant is not connected, send a plain request that names the meeting, duration, date window, organizer, time zone, and response deadline. Parse replies into the same canonical availability shape used for API data. When an answer is ambiguous—‘Tuesday afternoon’ with no zone—the agent asks one narrow follow-up instead of guessing.
   • Use an approved channel and retain a consent record for outreach.
   • Cap reminders and expose an opt-out.
   • Escalate silence from a required participant; do not silently treat them as optional.
6. 6

   Generate candidates with quorum and policy rules

   Intersect all required availability first. Then score candidates against optional attendance, organizer preferences, working hours, notice period, buffers, and the booking deadline. Keep the rejection reason for every discarded slot. That explanation is what lets an operator understand why the agent picked Wednesday at 2:00 rather than Tuesday at 11:00.
   • Never trade away a required participant to improve an optional-attendance score.
   • Apply policy before model preference.
   • Return no-overlap with the smallest useful constraint set for recovery.
7. 7

   Commit once with an idempotency boundary

   Re-check fresh free/busy immediately before writing. Derive an idempotency key from the meeting request, selected slot, and booking revision. Write one organizer event, send updates through the calendar provider, and store provider event identifiers before acknowledging success. A retry after a timeout must read the prior commit result before attempting another insert.
   • Make repeated commit calls return the same booking result.
   • Use optimistic versioning when a reschedule races the original booking.
   • Keep soft holds separate from the final invitation record.
8. 8

   Verify completion and expose recovery

   A successful HTTP response is not enough. Verify the canonical event identifiers, invitation state, required attendees, start and end timestamps, and the organizer’s calendar. Emit state changes such as availability_waiting, candidate_ready, commit_started, confirmed, and needs_review. Every terminal failure needs a reason, the last safe checkpoint, and a next action.
   • Trace provider calls and participant messages by meeting request ID.
   • Alert on stuck states and duplicate-commit attempts.
   • Keep a human approval lane for sensitive meetings and unresolved exceptions.

Four approaches to agent-driven group scheduling

The fastest demo is rarely the shortest path to a dependable booking. Compare approaches at the completion boundary, not at the first calendar query.