AI Scheduling Agent Observability: Trace a Hard Meeting End to End

Build meeting-level observability in eight steps

Use one fixture throughout: four required participants, one optional observer, two companies, Google and Microsoft calendars, and one person without calendar access. The trace must explain the meeting from instruction to confirmed invitations, even when that journey spans two days and several workers.

1. 1

   Create one durable meeting identity

   Assign a meeting_request_id before calendar reads, participant outreach, or model planning. Store the original instruction plus a typed brief: organizer, purpose, duration, date window, deadline, IANA time zone, required people, optional people, approval policy, and allowed contact channels. Increment a revision whenever a field that can change the result is edited.
   • Propagate the meeting ID through model, worker, provider, messaging, approval, and booking records.
   • Do not use a model run ID, HTTP request ID, or provider event ID as the meeting identity.
   • Bind every proposal and approval to the revision that produced it.
2. 2

   Model participant state as first-class telemetry

   Give every person a role, required flag, time zone, availability source, consent state, outreach state, response freshness, and blocking reason. Use explicit states such as connected, awaiting_response, needs_clarification, declined, available, and provider_error. A meeting trace should answer who is blocking progress and why without reading an email thread.
   • Silence from a required person is a wait state, not consent or availability.
   • An optional decline changes attendance scoring, not required quorum.
   • Keep private event titles and participant message bodies out of routine trace attributes.
3. 3

   Version every piece of availability evidence

   Normalize connected Google and Microsoft free/busy plus conversational responses into intervals with participant ID, source, retrieved or received time, time zone, source version, and error state. Record query bounds and provider status. Never turn a missing calendar response into open time. Mark proposals stale when required evidence changes.
   • Record whether evidence came from Google, Microsoft, or a participant response.
   • Distinguish denied access, expired access, throttling, partial response, and provider outage.
   • Expose evidence age without exposing event metadata.
4. 4

   Emit domain events instead of prose logs

   Record events such as brief_validated, availability_requested, participant_replied, proposal_generated, approval_requested, booking_started, booking_reconciled, and meeting_confirmed. Each event carries meeting ID, revision, actor class, attempt, outcome, reason code, and safe timing fields. Free-form logs can add detail, but the event vocabulary powers reliable queries.
   • Separate a business state such as required decline from an infrastructure error.
   • Do not record secrets, access tokens, calendar descriptions, or full participant messages.
   • Keep reason codes stable across REST, MCP, worker, and provider wrappers.
5. 5

   Trace retries at the side-effect boundary

   Give calendar reads, participant messages, reminders, approvals, and event writes their own spans or activities. Record attempt number, retry policy, provider request ID where safe, and final classification. A failed Google read can retry without resending outreach. A booking timeout must reconcile the organizer calendar before another write.
   • Use idempotency keys for meeting creation, outreach, and booking commands.
   • Mark retryable, terminal, and human-decision outcomes separately.
   • Alert when the same side effect succeeds more than once for one idempotency key.
6. 6

   Measure waits without calling people errors

   Track active processing separately from time waiting on a required participant, organizer approval, provider recovery, or the next permitted reminder. Set deadlines and wake timers on the meeting record. A healthy two-day coordination job should not page an operator for being two days old if it is inside policy and has a known next action.
   • Every waiting state has an owner, deadline, and next wake condition.
   • Alert on expired deadlines, exhausted reminders, missing timers, and state with no allowed transition.
   • Report participant wait, provider wait, and internal processing as different measures.
7. 7

   Instrument the single booking commit

   Before writing, record the approved proposal, attendee set, organizer calendar, fresh evidence version, and booking key. After the provider call, persist the returned event identifier and fetch or reconcile the event. Completion proof includes start, end, time zone, required attendees, optional attendees, organizer calendar, and invitation dispatch state.
   • An HTTP success without verified event shape is not meeting completion.
   • An uncertain response enters reconciliation rather than blind retry.
   • Partial invitation or attendee mismatch becomes a recoverable exception with evidence.
8. 8

   Build dashboards around meeting outcomes

   Start with meeting counts by state, confirmation rate, bounded-exception rate, time in each wait class, stale-evidence rebuilds, provider failures, clarification loops, approval expiry, duplicate attempts, and reconciliation outcomes. Sample traces by reason code. Let an operator move from a chart to one redacted meeting timeline and one safe action.
   • A dashboard distinguishes booked, declined, cancelled, expired, and needs-review outcomes.
   • Metrics can be segmented by provider and workflow version without exposing participant identity.
   • Runbooks name when to retry, reconnect, request a decision, reclaim, or stop.

Compare observability by the scheduling work it can explain

Provider logs and agent traces are useful inputs. The question is whether an operator can explain and recover one cross-company meeting from instruction to invitation.