Agent-to-Agent Interoperability

By December 2025 the Model Context Protocol had more than 10,000 active public servers and had been donated by Anthropic to the newly formed Agentic AI Foundation under the Linux Foundation, alongside Block's goose and OpenAI's AGENTS.md (MCP blog, 9 December 2025). That settled the question of how an agent talks to a tool.

It does not answer how an agent talks to another agent, and the difference is not cosmetic.

Two protocols, two shapes

MCP is client-server and vertical. The agent is the client, the server exposes tools, resources and prompts, and the server does not reason. Calls are typed, synchronous in shape, and the client holds all the intent.

The Agent2Agent protocol, announced by Google in April 2025 and donated to the Linux Foundation on 23 June 2025, is peer-to-peer and horizontal. Both ends are agents. Neither has the other's context. A task handed across an A2A boundary is delegated, not called: the receiving agent may plan, may take minutes or hours, may come back with clarifying questions, and may itself delegate onward.

That produces requirements MCP does not have:

Discovery. A2A uses an Agent Card, a metadata document describing what an agent can do and how to reach it. This is the level-1 index problem again, one layer up: you cannot load every peer agent's full capability description into context, so you need a cheap description and an expensive body.

Long-running, multi-turn tasks. A delegated task has a lifecycle with states, not a single response. The protocol has to carry status updates, intermediate artefacts and completion separately.

Opacity as a feature. Neither agent exposes its internal state, memory or tools. That is what makes cross-organisational delegation possible at all, and it is also what makes debugging a failed collaboration hard.

Where the two compose

The clean layering is: A2A between agents, MCP between an agent and its own tools. An agent that receives an A2A task uses MCP internally to do the work, and the peer never sees which servers it called. In practice the boundary blurs, because an A2A peer can be wrapped as an MCP server and often is, which works but throws away the lifecycle semantics that motivated A2A.

When it breaks

Trust does not compose. Delegating to a peer means delegating to whatever that peer delegates to, transitively, and the Agent Card does not describe the second hop. Authorisation scoped at the first boundary says nothing about the third.

Prompt injection crosses the boundary as data. A peer's returned artefact is untrusted input. If it lands in your agent's context without a trust label, the lethal trifecta reassembles itself across organisational lines, and now the attacker did not even need to reach your systems directly.

Capability descriptions are marketing. An Agent Card is written by the agent's author, not measured. There is no conformance test that says the agent can do what the card claims, which makes automated peer selection a reliability problem, not a routing problem.

Cost and latency become someone else's decision. A delegated task's token spend is set by the peer. Budgeting across an A2A boundary currently has no standard mechanism, so the calling agent cannot bound what a delegation will cost before making it.