Group coordination across several people's agents

A group plan (a dinner for six, a team offsite, a family weekend) is a negotiation with many parties. Each person’s agent knows its owner’s calendar, budget and preferences, so agents can gather constraints and find options much faster than a group chat. The hard part is structural: A2A connects two agents at a time, so someone has to coordinate.

How it works today

Groups coordinate in chat threads, shared documents and poll tools. The result usually becomes a calendar invitation. iTIP (RFC 5546) handles that step well: the organizer sends one REQUEST to every attendee, and each attendee answers with a REPLY that sets their participation status (RFC 5545 defines values such as ACCEPTED, DECLINED and TENTATIVE). An attendee can propose a change with COUNTER.

What iTIP does not do is choose among options. The IETF worked on a VPOLL component for consensus scheduling, voting on alternative times or tasks, but the draft stopped at revision 07 in October 2024 and has expired without becoming an RFC. RFC 7953 lets people publish recurring availability, such as weekday evenings, but it does not rank options or resolve conflicts.

Group messaging has its own standard for privacy. Messaging Layer Security (RFC 9420, 2023) gives end-to-end group key establishment for groups from two to thousands of members, with forward secrecy and post-compromise security, so the delivery service cannot read the messages.

The agent-to-agent version

A2A defines an A2A Client, which initiates requests, and an A2A Server, which processes tasks (section 2.2). There is no group primitive. The practical pattern is a coordinator: the organizer’s agent opens one task with each member’s agent, collects constraints, proposes options and gathers answers. A contextId groups related tasks on one server, and clients should not invent one unless they know how that server treats it (section 3.4.1), so the coordinator keeps its own group identifier.

Illustrative. Priya’s agent coordinates a dinner for six and asks each member’s agent for constraints:

{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "SendMessage",
  "params": {
    "message": {
      "role": "ROLE_USER",
      "messageId": "msg-grp-0412",
      "parts": [
        {"text": "Priya is organizing dinner for six on a weeknight between Oct 13 and Oct 17. Which evenings work, and what limits apply?"},
        {
          "data": {
            "groupPlanId": "dinner-oct-7a1c",
            "candidateEvenings": ["2026-10-13", "2026-10-14", "2026-10-15", "2026-10-16"],
            "ask": ["available", "budgetPerPersonMax", "mealRequirements", "autoAccept"]
          },
          "mediaType": "application/json"
        }
      ]
    }
  }
}

1. Each member’s agent answers from its owner’s rules: which evenings are free, a per-person budget cap, and only the requirement that matters (for example “needs a vegetarian option”), not the reason behind it.
2. The coordinator picks the evening most people can make and two venues within everyone’s cap.
3. It sends the proposal to each agent. Agents whose owners allowed it accept. The rest move their task to TASK_STATE_INPUT_REQUIRED and ask their person.
4. Once a quorum accepts, the coordinator books the venue and sends one iTIP REQUEST to everyone, so the plan lands in each calendar.

What has to be true

Identity. The coordinator must know each answer came from that member’s agent, and members must know the coordinator really acts for Priya. Every hop is a separate client-server connection, so each one needs its own authentication.

Authority. An agent may commit only its own person. Priya’s agent can propose, but it cannot accept for Sam. Money makes this sharper. AP2 v0.2 defines Checkout and Payment Mandates for one user’s purchase through a shopping agent, verified by the merchant and by the payment side respectively. The specification does not address splitting one purchase across several payers, so a group deposit today means each person pays their own share or one person pays and is repaid.

Privacy. The coordinator learns everyone’s constraints. Ask for the least that decides the plan: yes or no per candidate, a cap, a requirement. If members also talk as a group, an end-to-end encrypted channel such as MLS keeps the messages away from whoever relays them.

Record. The final plan should go to every member as the same artifact: the chosen time and place, who accepted, and what each person owes. The calendar event and each attendee’s participation status carry the durable part.

Where Emissar fits

Group plans among friends are not where Emissar starts, and most of the coordination needs no Emissar module. Modules become relevant at the edges:

• Front Door (open to design partners) applies on the business side, when the coordinator books the restaurant or venue through that business’s agent.
• Verify (in development) can tell a member’s agent which provider stands behind the coordinator before it shares anything.
• Mandate (spec in progress) is the kind of credential a member would need to let their agent pay a share up to a limit.
• Settle (planned) would move those shares, on AP2 or x402, checked against Mandate limits.

Open questions

• Who coordinates, and is it fair? The coordinator’s owner controls the ranking. Members may want to see how options were scored.
• Quorum and dropouts. Groups rarely agree unanimously. What counts as agreed, and what happens to a booking when someone drops out after paying?
• Social judgment. Declining, compromising and choosing between friends are not tasks to delegate by default. A human should see anything that says no on their behalf.
• Group identity. There is no standard identifier for “this group of agents working on this plan” across servers.
• Polls. Without VPOLL or an equivalent, every coordinator invents its own voting format.