AI Scheduling Agent Identity Resolution: Stop Booking the Wrong Participant

Build participant identity resolution in eight steps

Use one group meeting with an organizer, three required people, one optional observer, Google and Microsoft calendars, a shared executive-assistant mailbox, one person with two email aliases, and one unconnected participant replying through a private link. Duplicate two provider events and correct one identity after proposals exist.

1. 1

   Write a meeting-intent schema with participant entities

   Persist authenticated organizer, purpose, duration, bounded date range, deadline, IANA zones, required and optional roles, approved substitutes, outreach policy, approval mode, organizer calendar, and terminal proof. Give each intended human a participant ID that is independent from email, provider subject, calendar ID, or display name.
   • Required attendance is attached to a participant entity and role.
   • Aliases can change without changing the human’s meeting identity.
   • A transcript is provenance, not the canonical participant table.
2. 2

   Store identity claims with source, authority, and freshness

   Represent work email, personal email, provider subject, tenant, calendar, phone, reply token, delegate relationship, display name, locale, and IANA zone as claims. Record who asserted each claim, how it was verified, what actions it permits, when it expires, and whether it conflicts with another claim.
   • A matching display name is never sufficient proof.
   • A calendar connection proves access to a subject, not every business role.
   • Revoked or stale aliases stop authorizing reads, outreach, or writes.
3. 3

   Separate the human, account, calendar, and delegate

   Keep four different objects: the intended person, an addressable account, an authorized calendar subject, and an actor allowed to respond or approve for that person. A shared mailbox may carry a message without becoming the attendee. An executive assistant may coordinate under delegate rules without being the executive’s calendar identity.
   • One account cannot silently stand in for two people.
   • Delegate authority has scope, action, source, and expiry.
   • The invitation target and the conversation actor remain independently auditable.
4. 4

   Resolve connected free/busy inside the consent boundary

   Map each authorized Google or Microsoft calendar subject to one participant claim, then read private free/busy for the approved interval. Keep provider errors, missing access, and ambiguous account ownership as unknown. Do not merge calendars across people merely because addresses forward or names match.
   • Calendar detail stays private while availability retains source and retrieval time.
   • A person with two calendars can contribute one combined availability result under explicit rules.
   • Required and optional roles are evaluated after identity resolution, not before.
5. 5

   Bind conversational outreach and replies to opaque meeting context

   For an unconnected person, send one bounded request through an approved channel with purpose, local time, deadline, reminder cap, correction, and opt-out. Bind the response path to meeting ID, revision, participant ID, channel message ID, and nonce or equivalent opaque context. Treat reply text as availability data, never as authority to rename people or add attendees.
   • Forwarded links and replies trigger identity review rather than silent reassignment.
   • A duplicate delivery maps to one participant evidence record.
   • Calendar connection remains optional and helpful.
6. 6

   Normalize time zones, aliases, and corrections as revisions

   Convert bounded windows into instants while preserving original wording and IANA zone. When a person corrects an address, zone, or delegate, create a new identity revision, identify proposals that used the old claim, and refresh only affected evidence. Never rewrite history in place.
   • A daylight-saving boundary cannot make two aliases look like conflicting people.
   • Old reply and event identities stay available for reconciliation.
   • A correction cannot expand consent or required attendance by itself.
7. 7

   Make proposals and booking idempotent over participant IDs

   Intersect current required participant evidence, rank optional people and preferences afterward, and bind approval to participant IDs, roles, chosen aliases, exact slot, evidence versions, organizer calendar, and disclosure. Use one booking operation key. If provider writes duplicate or time out, reconcile attendee identities before retry.
   • Two aliases for one person do not count as two required attendees.
   • The wrong account cannot satisfy a required role because it shares a name.
   • Repeated approval returns one canonical event and invitation set.
8. 8

   Verify intended humans, not only attendee strings

   Read back organizer, time, zone, provider event identities, every required attendee address, optional decision, and invitation state. Join those addresses to the approved participant revision and flag ambiguity. Trace identity claims, resolutions, delegate acts, outreach, corrections, proposals, writes, retries, and terminal proof with private values redacted where possible.
   • Every required participant entity maps to one verified invitation target.
   • Duplicate or orphan attendee strings become repair work, not success.
   • Operators can explain why the system believed each account represented each person.

Compare identity handling by what the system can prove

The winning architecture maps people, roles, accounts, calendars, delegates, and replies without making an email string carry every meaning.