The problem: delegation across a boundary

Lesson 1 of 5 in A2A and Agent Interop — Honestly Sized.

Your supervisor agent needs a legal-review step. The legal-review agent exists — but a different team built it, on a different framework, running in a different cloud subscription, behind a different identity provider, and they ship it on their own release cadence.

Inside one codebase this is a function call. Across that boundary you suddenly need four things you never had to think about: a way to discover what the other agent can do, a wire format both sides agree on, a task model that survives work taking twenty minutes instead of two seconds, and an auth story that isn’t a shared secret in a config file.

Build those four things by hand for every pair of agents and you get the classic N×M adapter problem: ten agents, ninety bespoke integrations, each one rotting on someone else’s deploy schedule.

Agent2Agent (A2A) is the open protocol that standardises those four things. Google announced it on 9 April 2025 as a protocol letting agents built by different vendors or frameworks communicate, exchange information securely, and coordinate actions — and donated it to the Linux Foundation two months later.

The design intent matters more than the wire details. Google’s launch post lists five principles: embrace agentic capabilities (agents collaborate as peers rather than being flattened into tools), build on existing standards (HTTP, SSE, JSON-RPC), secure by default, support long-running tasks, and modality agnostic (text, but also audio and video). The first principle is the one that shapes everything else: A2A assumes the remote agent is opaque — you do not see its prompts, its memory, its internal plan, or which model it runs. You send it work and it sends back results.

Two axes of the same interop problem (A2A project docs; Google launch post, April 2025)
Dimension	MCP — the vertical axis	A2A — the horizontal axis
What it connects	One agent to tools, data sources, and prompts.	A client agent that formulates work to a remote agent that acts on it.
Unit of interaction	A tool invocation with a typed schema in, typed result out.	A Task — stateful, potentially long-running, delivering artifacts.
How much the caller sees	Everything: the schema is the contract, and the server is a transparent capability.	Deliberately little. The remote agent is opaque — no shared prompts, plan, or memory.
Discovery	Server lists its tools; the host wires servers in per configuration.	A JSON Agent Card advertising identity, skills, endpoint, and auth requirements.
What it is not	Not an orchestration framework; it does not decide when to call anything.	Not an agent framework, not a tool-call protocol, and not an MCP replacement — the project says so explicitly.

“MCP for tools, A2A for agents” is a heuristic, not a wall

That phrase is community shorthand distilled from Google’s framing (“A2A complements Anthropic’s Model Context Protocol”) and the vertical/horizontal wording above — not a literal quote from either spec. And the boundary is porous by design: the A2A docs say an A2A server can expose some skills as MCP-compatible resources when those skills are well defined and callable in a stateless, tool-like way.

So the honest distinction is not “agents versus tools.” It is: does the interaction need to be stateful, multi-turn, and opaque? If yes, that is A2A’s shape. If a single stateless call with a typed schema does the job, wrapping it as an MCP tool is simpler and you should. Both project teams frame the protocols as complementary layers — treating them as competitors will send you looking for a winner that neither community is trying to crown.

Interactive sorting exercise: Three shapes of integration. Sort each need: an MCP tool, an A2A task to a peer agent, or nothing protocol-shaped at all (just call the function).

Key terms: A2A, MCP, multi-agent system, orchestration, subagent, tool

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.