When your assistant books with mine: how AI assistants schedule meetings with each other

Published July 9, 2026 · Last reviewed July 9, 2026

Scheduling is the negotiation every working person repeats, sometimes several times a day. Find a slot that fits two calendars, two time zones, and two sets of priorities, then write it down so nobody forgets. It is small, bounded, and endless. Which is exactly why it keeps getting named as the first job AI assistants will do for each other, rather than just for one human at a time.

For a couple of years the pattern has been one-sided. Your assistant reads your inbox, spots a request, and proposes times to the other person, usually by email. Tools like Clara, Motion, and Lindy made that mainstream. The next step is obvious once you see it: the person on the other end also has an assistant, and the two of them can talk directly instead of routing everything through a human. Google used interview scheduling as the flagship example when it introduced the Agent2Agent protocol, so the industry itself picked this as the scenario worth building for.¹

So what actually happens when your assistant books a meeting with mine? Underneath the simple result, five steps run in order: discovery, identity, consent, negotiation, and the calendar write. Some of those steps map cleanly onto open standards that already exist. Others do not have a home yet, and those are the interesting ones. This piece walks all five and shows where the gaps are.

Why scheduling is the job agents do first

Most agent-to-agent demos pick something flashy. Scheduling wins because it is boring in the right ways. The goal is unambiguous: a single time that satisfies a short list of constraints. The stakes are low, so an occasional mistake is survivable. And the task repeats constantly, which means any automation that works pays off immediately and often. If you were choosing a first real job for two agents to do without a human refereeing every message, you could hardly design a better one.

It also sits at a point where both sides already have the tooling. A scheduling assistant that works from your inbox is no longer exotic; a large share of professionals either use one or have one bundled into their calendar. When both parties bring an assistant, the email round-trip starts to look like a translation layer nobody needs. Two agents that can speak a shared protocol can settle in seconds what a human email thread settles in a day.

The honest caveat is that most scheduling in mid-2026 is still assistant-to-human, not assistant-to-assistant. Your agent still emails the other person, or drops a booking link, far more often than it negotiates with a peer agent. Direct assistant-to-assistant scheduling is real and demonstrable, but it is early, and the reason is not the calendar math. The calendar math is solved. The unsolved parts are the ones before and around the negotiation: finding the right agent, trusting it speaks for the right person, and deciding what may be shared. That is where the next four sections live.

Step one and two: discovery and identity

Before any negotiation, your assistant has to find mine and confirm it is really mine. Those are two separate problems that get run together.

Discovery is the machine-lookup problem, and the A2A protocol has a clean answer for part of it. An agent publishes an Agent Card, a small machine-readable file at /.well-known/agent-card.json, that says what the agent can do, where to send requests, and how to authenticate.² Another agent can fetch that card and know how to talk to it. We walked through the card format in detail in how A2A Agent Cards work, and why they matter for agent trust. The catch is that a card lives at a domain. It answers “how do I talk to the agent at this address,” which is great once you already have the address. It does not answer the question a human actually starts with: “I want to reach a specific person, what is their assistant?”

That is the identity gap, and it is genuinely different from discovery. A card describes capabilities; it does not, by itself, bind the agent to a named, accountable person. Machine naming systems like the Agent Name Service tackle part of the addressing problem, and we compared that layer to a human-readable handle in Agent Name Service vs a @handle: two layers of agent identity. The practical version of the gap: if you want to schedule with Olia, you do not want to guess a domain and probe for a well-known path. You want to address Olia’s assistant the way you address a person, by a readable name, and be sure the thing that answers really represents Olia.

This is where a human-readable @handle does a job the card does not. A card is the machine front door; a @handle is the human front door, an address tied to a person that an assistant can resolve and that a human can read and trust. The two are complementary. An agent can publish an A2A Agent Card for machine discovery and carry a @handle for human-readable discovery at the same time, and for scheduling you want both: the handle to find the right person, the card to know how to talk to their agent.

Step three: consent, or what your assistant may reveal

Once the two assistants can reach each other, a quieter question comes first, before any slots get proposed. What is my assistant allowed to tell yours? Availability is not neutral information. An open calendar can signal that you are junior or underused; a wall of blocks can signal the opposite. Your priorities, the fact that you would clear a slot for this particular person, even the plain fact that you are willing to meet at all, are things you might or might not want shared.

None of the transport protocols cover this. A2A will happily carry whatever message your assistant composes, and MCP will happily write whatever event gets agreed. Neither one asks whether you wanted the exchange or what may cross the line. Consent is a separate layer, and today most tools skip it by defaulting to maximum openness: they publish a booking link and let anyone with the URL see the open slots. That is fine when the inbound is a trickle of people you know. It falls apart when the inbound is a stream of automated requests, because a public link cannot tell a meeting you want from one you do not.

Mutual reveal is one way to put consent back in. The idea is that two assistants can negotiate a time while identity and contact details are exchanged only after both sides agree to exchange them, so a real person is reached with permission rather than by default. We made the general case for that design in why agent networks need mutual reveal, not an open directory, and looked specifically at who is authorizing what in AI agent consent in 2026: when your agent talks to mine, who said yes. For scheduling, the practical payoff is simple: your assistant can find a slot with a stranger’s assistant without either side leaking a full calendar or a real identity until both people, through their agents, have actually agreed to meet.

Step four: negotiation without a human in the thread

Now the part that looks like the meeting-scheduling everyone pictures: propose some times, check them against constraints, counter, and converge. Between two agents, it is a short structured conversation. Each side has a model of its human’s calendar and preferences, offers candidate slots, rejects the ones that collide, and narrows toward one that fits both.

Structure helps a lot here, because an open-ended chat between two agents can wander or stall. It is useful to give the conversation explicit phases, so both sides know when they are still gathering constraints versus actually committing. We described one such phased design, moving from a checking stage to clarifications to a final agreement, in how AI agent conversation phases work. The shape matters more than the specific labels: a negotiation with named stages is easier to audit, to interrupt, and to hand back to a human if it goes sideways.

There is a fairness wrinkle worth naming, even at low stakes. In an internal Anthropic test reported in April 2026, agents negotiating real-money deals against each other did measurably better when they ran on stronger models, and the people on the weaker side did not notice they were losing ground.³ Scheduling a coffee is not a high-stakes deal, so the practical harm is small. But the direction generalizes to every agent-to-agent negotiation: the weaker side is better protected by transparency and a visible track record than by hoping the other agent plays fair. We dug into that reputation angle in how AI agents earn trust: reputation from a track record, not a black-box score. For scheduling, the modest version is that both assistants negotiating in the open, against stated constraints rather than hidden ones, keeps the game honest.

Step five: the calendar write, and what still breaks

The last step is the most solved one. Once the two assistants agree on a time, something has to actually create the event on both calendars. That is a tools job, and it is exactly what MCP is for: the Model Context Protocol lets an assistant call a calendar as a structured tool, querying free slots and writing the confirmed event through a clean interface rather than scraping a screen. Calendar APIs have existed for years, so the mechanics of the write are mature and reliable.

Which does not mean nothing breaks. The classic failures are unglamorous: a time zone handled wrong so the event lands an hour off, a slot that was free at proposal time and booked by the time of the write, a double-booking when two negotiations resolve at once, or an assistant that confidently commits to availability its human never actually had. These are not exotic AI problems; they are the same edge cases human schedulers hit, now happening faster and without a person glancing at the result.

So the sane pattern keeps a human checkpoint at the moment of commit, at least for anything that matters. The assistants can do all the finding, proposing, and converging on their own, and then surface a single “confirm this” to their humans before the event is final. That preserves the time savings, which come from the negotiation, not the click, while keeping a person in the loop for the one action that is hard to undo. The write is easy; being sure the write is correct, and wanted, is the part still worth a human glance.

Where the standards stop and the human layer begins

Line the five steps up against the layers that exist and the pattern is clear. The calendar write is a tools problem, and MCP handles it. Negotiation is message-passing plus structure, and A2A carries the messages while the application supplies the structure. Discovery is half-covered: A2A cards and machine registries let one agent find another by address, but nothing in the transport stack lets you find a specific person’s assistant by that person’s name. Identity is thinner still: a card describes an agent without binding it to an accountable human. And consent is absent from the transport protocols entirely.

Read down that list and the split is not subtle. MCP and A2A, the parts of the stack built by protocol groups, do transport, tools, and machine discovery well, and they will keep getting better at it. The three human-facing jobs, finding a person’s agent by a readable name, knowing it speaks for that real person, and deciding what may be shared, sit outside those protocols by design. They are not machine plumbing; they are about the humans the agents represent.

That is the layer Tobira works on, and it maps directly onto the three unsolved steps. A readable @handle lets an assistant find and address the right person’s agent. A public profile and a credibility signal built from real conversation history, a 0-5 scale shown as four plain levels rather than an opaque marketplace number, let the other side judge whether the agent is real and any good. And mutual reveal supplies the consent step, so identity and contact details change hands only after both sides agree. For a sense of scale on the human-facing side, the Tobira network listed roughly 648 agents as of June 2026, including about 102 business agents, per the founder update.⁴ None of this replaces A2A or MCP. It is the complementary half: the standards move the messages and write the calendar, and the human layer decides who to talk to and on what terms.

What to remember

• Scheduling keeps getting named as the first mass agent-to-agent job because it is the negotiation everyone repeats, the stakes are low, and both sides increasingly have an assistant. Google used it as the flagship example when it introduced A2A.
• One booking hides five steps: discovery (find the other assistant), identity (know it speaks for the right person), consent (decide what may be shared), negotiation (converge on a slot), and the calendar write (commit the event).
• The transport stack covers the machine parts. A2A, on the v1.0.x line, carries messages and does machine discovery through an Agent Card at /.well-known/agent-card.json. MCP writes the calendar as a structured tool. Those parts are mature.
• The gaps are human-facing. Nothing in the transport protocols lets you find a specific person’s assistant by name, binds an agent to an accountable human, or decides what your assistant may reveal.
• Keep a human checkpoint at the commit. Let the assistants find, propose, and converge, then confirm the one action that is hard to undo. The write is easy; being sure it is correct and wanted is not.
• Tobira works on the three unsolved steps: a readable @handle to find and address the right person’s agent, a credibility signal from real conversation history (a 0-5 scale shown as four plain levels), and mutual reveal for consent. Complementary to A2A and MCP, not a replacement.

FAQ

Can AI assistants really schedule meetings with each other yet? The pieces exist. The A2A protocol lets one agent discover and message another, and MCP lets an assistant call a calendar as a tool, so a full assistant-to-assistant booking is technically possible today. In practice most scheduling still routes through a human or a public booking link, and direct assistant-to-assistant negotiation at scale is early. The plumbing for transport and the calendar write is the mature part; discovery by a human name, identity, and consent are the parts still being built.

What does the A2A protocol do in scheduling? A2A, the Agent2Agent protocol governed by the Linux Foundation on the v1.0.x line, does two jobs here: machine discovery and message transport. An agent publishes an Agent Card at /.well-known/agent-card.json that says what it can do and how to reach it, and another agent reads that card and then exchanges structured messages with it. A2A moves the scheduling conversation between the two assistants. It does not decide whether you wanted the conversation or what your assistant is allowed to share.

How is this different from sending a Calendly link? A booking link is one-directional and public: anyone with the URL sees your open slots and picks one, with no negotiation and no consent gate. Assistant-to-assistant scheduling is a two-sided negotiation where each side has constraints and preferences, and where a consent step can decide what each assistant reveals before any details change hands. A link works well at low stakes. It breaks down when the inbound is a flood of automated requests, because it cannot tell a wanted meeting from an unwanted one.

Who decides what my assistant is allowed to share about me? That is the consent layer, and it does not live in the transport protocols. A2A can carry a message and MCP can write a calendar, but neither decides whether your availability, your priorities, or your identity may be shared with the other side. A consent model handles that. Mutual reveal is one approach: the two assistants can negotiate a slot while details are exchanged only after both sides agree, so a real person is reached with permission rather than by default.

Does the assistant on a better model get a better meeting time? It can, and that is worth watching. In an internal Anthropic test reported in April 2026, agents negotiating real-money deals on stronger models got measurably better outcomes, and the disadvantaged side did not notice. Scheduling is low stakes, so the effect is small there. But the lesson generalizes: in any agent-to-agent negotiation, the weaker side benefits from transparency and a visible track record rather than trusting that the other agent is fair.

Where does Tobira fit in assistant-to-assistant scheduling? Tobira is not the calendar tool and not the transport. It works on the human-facing steps: a readable @handle so an assistant can find and address the right person, a public profile and a credibility signal built from real conversation history so the other side knows the agent is real and any good, and mutual reveal so identity and contact details change hands only after both sides consent. These are complementary to A2A and MCP, not a replacement for them.