Agent interoperability & A2A.
The moment your agent has to work with an agent someone else built, every assumption you were quietly relying on breaks: you cannot see its prompt, you cannot import its functions, and you cannot make it finish before your request times out. Agent-to-agent protocols exist for that specific situation — and the useful mental model is that MCP hands your agent a tool, while A2A introduces it to a peer that has its own goals, its own latency, and its own bad days.
Two protocols, two different relationships.
They are complementary, not competing, and the distinction is about what sits on the other end:
- MCP — agent to capability. The far side is passive: a database, a filesystem, an API, a search index. Your agent decides, calls, and gets a result. You own the loop.
- A2A — agent to agent. The far side is an actor with its own model, its own tools, and its own judgement. You delegate an outcome and it runs its own loop to get there. You own only the request.
The practical consequence: with MCP you are debugging your reasoning over someone's data. With A2A you are debugging a conversation between two systems whose reasoning you can only observe from the outside. That is a genuinely harder operational problem, and it is the reason to be sure you need it.
A2A was introduced by Google in 2025 and donated to the Linux Foundation in June 2025, which is what turned it from a vendor protocol into a neutral one. At its one-year mark in April 2026 the project reported support from more than 150 organisations and integration across the major cloud platforms. Treat that as evidence the standard is durable — not as evidence you need it.
The four things any agent protocol has to solve.
Strip away the branding and every design in this space is answering the same four questions. A2A's answers are worth knowing because they are the ones the ecosystem converged on:
- Discovery. How does one agent learn what another can do? A2A publishes an Agent Card — a machine-readable document at a well-known URL declaring the agent's skills, endpoint, and authentication requirements. It is the equivalent of a service's OpenAPI document, and it is what makes dynamic delegation possible instead of hard-coded integration.
- Task lifecycle. Agent work is long-running and does not fit request/response. A2A models a task as a first-class object with an identity and a state machine — submitted, working, input-required, completed, failed — so the caller can poll or subscribe rather than hold a connection open for four minutes.
- Content negotiation. Two agents may not agree on modality. Messages are composed of parts (text, files, structured data), so a peer can return an artifact rather than being forced to describe it in prose.
- Identity. Agents authenticate as themselves, using ordinary web mechanisms rather than anything novel — because a delegating agent needs to know who it is talking to before it acts on the answer. See agent identity & permissions.
What the protocol does not give you.
This is where teams get hurt, because the protocol solves transport and discovery and then hands the hard parts back:
- No shared semantics. Both agents can speak valid A2A and still disagree about what "urgent" means, what a customer ID looks like, or whether an amount is gross or net. Wire compatibility is not agreement.
- No trust. A remote agent's output is untrusted input to yours. Everything you know about prompt injection applies with full force, and now the attacker's payload arrives inside a response you asked for — which feels authoritative in a way a scraped web page does not.
- No compound-reliability guarantee. Chain four agents at 95% each and you are at roughly 81%. Delegation multiplies failure the same way multi-agent systems do, and the protocol cannot help.
- No cost or latency ceiling. You do not control the peer's model, its step count, or its bill. Set your own timeouts and budgets on the calling side, because nothing on the other side is obliged to.
- No end-to-end trace, unless you build one. A remote task is opaque by default. Propagate a correlation ID and record what you sent and what came back, or debugging becomes archaeology — see agent observability.
When it is actually the right tool.
The honest test is an organisational one, not a technical one. Reach for an agent-to-agent protocol when the far side is genuinely not yours:
- Different owner. Another company, another business unit, a vendor. You cannot import their code, and you should not want their credentials.
- Different lifecycle. They deploy on their schedule. A versioned protocol boundary is the thing that lets both sides move independently.
- Opaque by requirement. They cannot show you the prompt or the data — regulated, proprietary, or simply not your business.
If none of those hold — if the "other agent" is a function in your own repository — a protocol adds a network hop, a serialisation format, and a distributed-systems failure mode in exchange for nothing. Call the function. In-process delegation is not less sophisticated; it is just honest about where the boundary is.
Expose an Agent Card before you consume one. Publishing what your agent can do, with a clear task lifecycle and real authentication, is a small amount of work that forces you to write down your own capability boundaries — and teams almost always discover that their agent's advertised skills and its actual skills are not the same list. Consuming remote agents can wait until you have a peer worth the compound failure risk.
Related: what is MCP for the tool-facing half, multi-agent systems for whether to split the work at all, and tool-calling standards for how the wire formats compare.