How AI agents talk to each other

Agent-to-agent communication today

There are two standards worth knowing, and one sentence each is enough to place them.

MCP (Model Context Protocol) is how an agent reaches a tool: a database, a file system, a ticket tracker. Anthropic introduced it at the end of 2024, and by 2026 its SDKs were being downloaded hundreds of millions of times a month.

A2A (Agent2Agent) is how an agent reaches another agent. Google announced it in April 2025 and handed it to the Linux Foundation two months later.

The layering is the part to take away. MCP below, A2A above. An agent uses MCP to pick up a capability, and A2A to hand work to a peer that has capabilities of its own. They solve different problems and you will probably use both.

Both now live under the Linux Foundation's Agentic AI Foundation, co-founded by OpenAI, Anthropic, Google, Microsoft, AWS and Block. A2A reports more than 150 supporting organisations, up from around 50 a year earlier.

Smaller efforts exist. IBM's ACP merged into A2A during 2025. Others are real specifications working on adjacent problems, mostly identity and discovery, and several are designed to sit alongside A2A rather than replace it. None has adoption close to MCP or A2A. If you're choosing today, you're choosing between those two, and usually taking both.

What A2A gives you

These pieces turn up in any design you'd otherwise build yourself, so they're worth knowing even if you never adopt the protocol.

A task with a status you can check. Work gets an identifier and moves through a fixed set of states, including submitted, working, needs input, done, failed and cancelled. A finished task stays finished. This matters more than it sounds. Without it, "is that done yet?" has no answer, and long-running work has nowhere to report from.

Messages made of parts. A message carries a role and a list of parts, and each part declares whether it is text, structured data, a file or a link. One message can carry an instruction, a parameter block and an attachment without the receiver guessing how to read any of them. Anything a task produces is returned the same way, as a named output built from parts.

Big things by link, not by paste. A part can be a URL. Pasting a source file into a message spends context on every hop it travels. A link spends it once, when someone actually opens it. This is the cheapest habit on this page to adopt.

A card saying what an agent can do. Each agent publishes a small JSON document at a known path listing its name, its skills and how to authenticate with it. That document is how another agent discovers it. Capabilities live there, not in every message.

Identity outside the message. A2A keeps authentication at the HTTP layer rather than in the message body. It's a deliberate choice and a good one: the message stays about the work, and credentials stay where your existing infrastructure already handles them.

Streaming is server-sent events, with webhooks for work that outlives the connection. Retries and circuit breaking are left to you.

Why it gets expensive

Anthropic reported that agents use roughly four times the tokens of a plain chat, and multi-agent systems roughly fifteen times. On one of their evaluations, token volume alone explained 80% of the variance in quality scores. All of this comes from a single production report, and the 80% figure from one benchmark within it, so hold the numbers loosely. The direction is consistent with everything published since.

Two things drive the cost, and neither is the thinking. Running agents in parallel means each one carries its own context, so the same background gets paid for several times over. Then the agents talk. When every agent can message every other agent, connections grow faster than agents do: ten agents fully connected is 45 channels, and each one carries context.

Work through 2025 and 2026 keeps arriving at the same answer, which is to keep the graph sparse. Pruning connections cut tokens by 20% to 70% across several studies while holding or improving accuracy, partly because a sparse graph also stops one agent's mistake reaching all the others.

The practical version: adding an agent is not free, and a design where everyone hears everything gets expensive well before it gets good. The number to watch is fan-out, meaning how many other agents each message reaches.

There's a live disagreement about whether to use multiple agents at all. In June 2025 Cognition argued against them, on the grounds that parallel agents make conflicting implicit decisions that nobody reconciles. Anthropic published the opposite case within a day, reporting large gains from isolated subagents each given a self-contained task. The resolution most people settled on is about task shape rather than about who was right. Read-heavy work parallelises well. Write-heavy work, where every decision constrains the next, does not.

Message format matters

You'd assume adding structure helps. It depends entirely on which kind you add.

One 2026 study compared formats carrying the same content. Wrapping prose in A2A's JSON cut tokens by about 7% against raw text. Replacing that with a handful of named fields cut about a third, and ran faster. The fields were simply: what kind of task this is, the instruction, and the shape the answer should take.

The saving comes from naming the fields, not from the JSON around them. A verbose envelope wrapped around vague prose is the worst of both: you pay for the syntax and get none of the compression.

Evidence on structured output versus plain language for tool calls is genuinely mixed, and it varies by model. One study and its replication found natural-language tool interfaces beating structured ones by a wide margin on smaller and open-weight models, with the gap narrowing or reversing on frontier models. If you run a mixed fleet, that's worth measuring rather than assuming.

The shape most of the evidence supports is a thin typed envelope around short natural language. A few named fields, such as role, task identifier, state and links to any files involved, with the human-readable instruction kept short inside them.

What tends to go wrong

The most-cited study of multi-agent failures analysed over a thousand annotated traces across seven frameworks and sorted what it found into three groups: the task was specified badly, agents talked past each other, or nobody checked the result. Its conclusion was that most failures are design and coordination problems rather than limits of the underlying model. That is good news, because orchestration is something you control.

Security has a specific shape that's worth memorising. An agent that holds private data, reads untrusted content, and can send data somewhere is exploitable by design. Simon Willison named it the lethal trifecta in 2025, and most deployed MCP agents have all three.

It's hard to fix because everything in a context window carries the same authority. Your system prompt, the user's message, and a description written by whoever published a tool all arrive as text the model reads. Instructions hidden inside a tool's description get read as configuration, which is a channel nobody thinks to review. Tools that proxy to remote servers have shipped remote-code-execution bugs. Injection has reached a database through an ordinary support ticket.

The rule worth carrying is not to hand a bearer token from one agent to the next. Each hop should get its own scoped credential, or the second agent can impersonate the first and nothing downstream can tell. That's why identity here is a stack rather than a single protocol: one identity for the agent as a running workload, a separate delegated authority for acting on a person's behalf, and signatures for proving a message came from where it claims.

Regulation is on the calendar too. The EU AI Act has been substantially enforceable since August 2026, though the obligations for high-risk systems were extended to December 2027 by an amendment earlier that year. The transparency and logging duties are difficult to satisfy after the fact across a long chain of tool calls, which makes them an architecture decision rather than a documentation one.

What nobody has solved

Four gaps are open, and they're the problems you'd be solving yourself.

• Discovery at scale. Fine when you already know which agents exist. There's no winner for finding one you don't, with competing bets on well-known URLs, signed metadata and decentralised directories.
• Paying for it. At least six protocols compete for agent payments and none has universal acceptance. The unsolved part isn't the payment rails, it's metering, reconciliation, and stopping a looping agent from spending your money.
• Trust between agents. No standard way for one agent to establish that another's claim is true, or to carry a reputation from one interaction to the next.
• Routing by meaning. Routing messages by what they contain is an old idea. Routing on embeddings, so that a subscriber describes the kind of message it wants rather than naming a channel, is a new one.

That last one is worth a caveat, because it's the least settled. Third-party routers report matching in the 10 to 50 millisecond range, but they're measurably less accurate than a classifier trained on a fixed set of routes. Short commands like "retry the build" are the likely weak spot: direct evidence on how well embeddings separate them is thin rather than settled, so it's worth measuring on your own traffic before betting on it.