Meeting scheduling between assistant agents

Scheduling a meeting between two people at different companies is a small negotiation: propose times, check constraints, agree, then book. Two assistant agents can run that negotiation in seconds. The booking should still travel as a standard calendar invitation, because iCalendar, iTIP and CalDAV already solve that part well.

How it works today

Inside one organization, calendar servers answer the question directly. Microsoft Graph’s findMeetingTimes checks the free/busy status in the primary calendars of the organizer and attendees and returns ranked suggestions. It scores each slot by averaging each attendee’s chance of attending: free counts as 100%, unknown as 49% and busy as 0%. It works only with delegated permissions for work or school accounts (least privileged: Calendars.Read.Shared); personal Microsoft accounts and application permissions are not supported. Google’s freebusy.query returns busy intervals for a set of calendars without any event details, and accepts a narrow calendar.freebusy scope.

Between organizations, the tools are older and more manual:

• iCalendar (RFC 5545) is the data format. A VEVENT holds the meeting, a VFREEBUSY component conveys busy and free intervals, and each attendee carries a participation status such as NEEDS-ACTION, ACCEPTED, DECLINED or TENTATIVE.
• iTIP (RFC 5546) defines the scheduling conversation. The organizer sends REQUEST, attendees send REPLY, an attendee can propose a change with COUNTER, and the organizer can refuse it with DECLINECOUNTER or withdraw with CANCEL. SEQUENCE marks each significant revision.
• iMIP (RFC 6047) carries iTIP over email. That is what a calendar invitation in your inbox is.
• CalDAV (RFC 4791) gives clients access to calendars on a server, including a free-busy query. RFC 6638 adds scheduling: the server sends invitations and replies itself when an event changes, and answers free/busy requests posted to a scheduling outbox.
• RFC 7953 adds VAVAILABILITY, which expresses recurring availability such as weekday office hours. VFREEBUSY has no way to express a repeating period.

The gap is the negotiation. Free/busy lookups work where the caller has been granted access to the calendars involved. Between companies that access is usually missing, so people trade emails listing times, or one side sends a booking link and the other side fits in.

The agent-to-agent version

Illustrative. Alice Chen at Northwind wants 30 minutes with Bob Ortiz at Acme. Alice’s assistant sends Bob’s assistant an A2A SendMessage request with a proposal as a data part:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "SendMessage",
  "params": {
    "message": {
      "role": "ROLE_USER",
      "messageId": "msg-7f3a",
      "parts": [
        {"text": "Alice Chen (Northwind) asks for 30 minutes with Bob Ortiz to review the Q4 renewal."},
        {
          "data": {
            "organizer": "mailto:alice@northwind.example",
            "attendee": "mailto:bob@acme.example",
            "duration": "PT30M",
            "candidates": [
              {"start": "2026-10-06T15:00:00Z"},
              {"start": "2026-10-07T17:30:00Z"},
              {"start": "2026-10-08T14:00:00Z"}
            ]
          },
          "mediaType": "application/json"
        }
      ]
    }
  }
}

1. Bob’s assistant checks his calendar and his rules, for example external meetings only Tuesday to Thursday, 30 minutes or less without asking him.
2. The first slot breaks a rule, so the assistant picks the second and completes the task with an artifact naming the accepted slot. If none fit, it can return TASK_STATE_INPUT_REQUIRED with counter-proposals instead.
3. Alice’s calendar sends a normal iTIP REQUEST for that slot, by email or through the calendar server.
4. Bob’s assistant matches the invitation to the negotiated slot and sends an iTIP REPLY with PARTSTAT=ACCEPTED.

The agents never see each other’s calendars, and nothing new has to be installed in either calendar system.

What has to be true

Identity. Bob’s assistant must know the request really comes from Alice’s agent. iTIP already names organizer and attendee spoofing as threats (section 6.1), and iMIP requires S/MIME to authenticate the sender and says the signer must match the ORGANIZER or ATTENDEE in the calendar object (sections 2.2.2 and 3). An agent-to-agent channel needs the same property: a verifiable agent identity tied to the person and the organization, such as a signed Agent Card plus authenticated requests.

Authority. Each assistant needs limits. Reading free/busy is a smaller permission than editing events, and the APIs reflect it: Google offers a free/busy-only scope, and Graph’s least privileged permission for findMeetingTimes is read-only. What an assistant may accept without asking (length, days, external parties, recurring series) is the owner’s policy, and the other side should be able to tell whether a confirmation was automatic or human.

Privacy. Share the least that settles the question. Candidate slots or free/busy intervals are enough. Titles, attendees and locations of other meetings are not needed and should not cross the boundary.

Record. The calendar event is the durable record. Its UID identifies it, SEQUENCE tracks revisions, and each attendee’s PARTSTAT shows who agreed. The A2A task adds how the time was chosen, which matters mostly when someone later asks why a meeting was booked.

Where Emissar fits

Most of this use case needs no Emissar module, because calendar standards carry the result.

• Verify (in development) applies when Bob’s side wants to check which agent is calling and which provider stands behind it before the assistant engages.
• Resolve (in development) maps identifiers such as domains to agent endpoints. Finding one person’s assistant, as opposed to a company’s agent, is an open problem that Resolve does not yet claim to solve.

Open questions

• Discovery of personal agents. A2A discovery finds an Agent Card on a domain. There is no standard way to go from bob@acme.example to Bob’s own assistant.
• Holds during negotiation. If Bob’s assistant offers a slot, should it hold it, and for how long? Without holds, two negotiations can claim the same time.
• Polls. Choosing among many options for several people has no finished standard. The IETF VPOLL draft for consensus scheduling reached revision 07 in October 2024 and has since expired without becoming an RFC.
• Loops. Two agents can counter-propose indefinitely. A cap on rounds, then escalation to a person, is a sensible default.
• Time zones. Proposals should carry UTC or explicit zones. iCalendar’s VTIMEZONE exists because local times alone are ambiguous.