AI Scheduling Agent Participant Outreach: Build a State Machine That Waits

Build the participant-outreach state machine in eight steps

Use one sixty-minute meeting with three required people, two optional people, Google and Microsoft calendars, one unconnected external participant, one corrected email address, one ambiguous reply, duplicate worker delivery, and a booking deadline three days away.

1. 1

   Persist a meeting-intent contract before any message leaves

   Record authenticated organizer, purpose, duration, bounded date range, booking deadline, IANA zones, required and optional participants, approved substitutes, organizer calendar, outreach channels, reminder caps, disclosure policy, approval mode, and terminal proof. Give every meeting, revision, and participant a durable identity outside the model transcript.
   • A required person cannot become optional because they did not reply.
   • Every outreach task points to one current meeting revision.
   • The original instruction remains provenance, not mutable workflow state.
2. 2

   Resolve identity, authority, consent, and channel

   Map each intended human to approved addresses, connected calendar subjects, delegate relationships, and permitted contact channels. Record who authorized outreach, what purpose may be disclosed, which actions a delegate can take, when authority expires, and how the participant can correct or opt out. Treat names and message text as evidence, not identity proof.
   • A shared mailbox is not silently treated as the attendee.
   • Calendar access does not create permission to contact someone through every channel.
   • Participant replies cannot add people or widen the organizer’s instruction.
3. 3

   Read connected free/busy before creating unnecessary outreach

   Query approved Google and Microsoft free/busy for the bounded interval. Normalize participant ID, source, retrieval time, IANA zone, busy intervals, error state, and expiry. Calendar connection is optional and helpful. A valid connected result can satisfy the availability step without sending another request.
   • Private event titles, descriptions, and attendee lists stay outside agent context.
   • Denied access, missing calendars, throttling, and provider failure remain distinct states.
   • A stale result becomes evidence-expired, not secretly available.
4. 4

   Create one versioned outreach task for each missing participant

   Build a task with meeting ID, revision, participant ID, purpose-safe wording, duration, bounded date window, local-time display, reply deadline, approved channel, message identity, reminder policy, correction path, and opt-out. Commit the task and its outbox record together before a delivery worker sends anything.
   • A worker restart cannot invent a second logical request.
   • Required and optional participants can receive different deadline treatment under declared policy.
   • The request asks only for availability needed by this meeting.
5. 5

   Keep delivery, receipt, reply, and parsed availability separate

   Model states such as pending, dispatching, sent, delivery-unknown, delivered, replied, needs-clarification, declined, opted-out, expired, superseded, and closed. A provider acceptance response is not proof that the intended person read the request. A human reply is not usable availability until identity, zone, bounds, and meaning are resolved.
   • Late delivery receipts cannot move a newer task backward.
   • A forwarded response opens one identity exception instead of reassigning the participant.
   • Original wording and normalized intervals remain linked for audit and correction.
6. 6

   Normalize replies and recompute from current evidence

   Convert explicit windows into instants while preserving the participant’s wording and IANA zone. Ask one narrow clarification for ‘Tuesday afternoon’ without a zone or bound. When a reply, calendar connection, correction, or provider change arrives, append a new evidence revision and invalidate only proposals that depended on superseded facts.
   • A connected calendar arriving after outreach can stop future reminders without erasing the conversation.
   • Duplicate replies collapse under one participant evidence identity.
   • Daylight-saving conversion is recalculated from the named zone and date.
7. 7

   Run reminders from policy, not model impatience

   Schedule reminders from participant role, deadline, delivery state, local quiet hours, organizer policy, prior contact, and opt-out. Re-check current meeting and evidence revisions before sending. Stop reminders when a usable reply arrives, a calendar connects, the meeting changes, the person declines, authority is revoked, or a human reclaims the thread.
   • Every reminder has a cap and an explicit next state.
   • A required participant’s silence becomes a visible blocking exception.
   • Optional silence cannot block required overlap when policy allows exclusion.
8. 8

   Close outreach only after one verified booking outcome

   Intersect fresh evidence for every required person, rank optional attendance and preferences afterward, bind approval to the current participant and evidence revisions, and issue one idempotent event write. Reconcile uncertain provider responses, read back required attendees, and close every outreach and reminder task only when invitations are verified or the meeting reaches an authorized non-booked terminal state.
   • No reminder can fire after the meeting is confirmed or canceled.
   • A duplicate agent command returns the existing meeting result.
   • Traces show identity, consent, delivery, reply, reminder, proposal, write, and terminal proof without exposing private content.

Compare participant outreach by the state it owns

The shortest path produces text. The production path governs identity, delivery, evidence, reminders, recovery, and completion for every required person.