A2A is the protocol that lets separate AI agents talk to one another and pass work between them, so an agent built by one team can delegate to an agent built by another. Where MCP connects a single agent to tools and data, A2A connects agents to other agents.
In plain language
A single AI agent can plan, call tools, and finish a task on its own. But real work often spans more than one agent. One team builds an agent that is good at reading contracts; another team builds an agent that is good at checking compliance rules. To get the job done, the first agent needs to hand part of the work to the second. A2A is the shared set of rules that makes that handoff possible.
Before a protocol like this, connecting two agents meant writing custom glue for every pair. Agent A had to know the exact API of Agent B, and that code broke whenever either side changed. A2A replaces that with one agreed format. An agent publishes a short description of what it can do, often called an Agent Card, and other agents can read it, send a task, and receive results through the same channel. Adding a new agent to the network no longer means rewriting the others.
It helps to place A2A next to MCP, because they solve different halves of the same picture. MCP connects one agent down to its tools and data, a database, a calendar, a file system. A2A connects one agent across to another agent. An agent might use MCP to reach its own tools and use A2A to delegate a sub-task to a peer that is better suited for it. The two are complementary, not competing.
A2A is a protocol, not a model and not an app you download. It does not make any agent smarter or more trustworthy on its own. It standardises how agents announce themselves, send a task, report progress, and return an answer. Whether the agent on the other end is reliable, and whether it should be allowed to act, are separate questions that still need authentication, authorization, and human oversight.
An everyday picture
Think of a company where each department has its own specialists. Inside one office, a worker reaches for tools on their own desk, that is the MCP picture. A2A is the etiquette that lets a worker in one department phone a specialist in another and say, here is the task, send back the result when you are done. The phone line and the shared way of asking are what let strangers cooperate without learning each other's private filing systems.
Where it shows up
A2A shows up wherever work is split across more than one agent or more than one team. Google has pointed to examples in commerce, data streaming, DevOps, and telecommunications, where a request flows through several specialised agents in turn. It also matters for orchestration and workflow systems that route a job to whichever agent is best placed to handle each step, and for ecosystems where agents from different vendors are expected to interoperate.
A small example
Google has described cross-language teams of agents working together over A2A, for instance a Python agent and a Go agent collaborating to check whether a contract meets compliance rules. Neither agent has to be rewritten in the other's language or framework; they coordinate by exchanging tasks and results through the shared protocol.
Common misunderstanding
One line to take with you
MCP gives one agent reach into tools and data; A2A gives many agents a way to delegate and hand off work to each other. It is plumbing for collaboration between agents, useful as systems grow past a single agent, and it moves the hard questions of trust and permission to where they belong, the design of the handoff.
Frequently asked
They connect different things. MCP links a single agent to its tools and data sources, a database, a file system, a calendar, through one shared interface, so the agent can act on the world. A2A links one agent to another agent, so a task can be delegated or handed off between them. A useful shorthand is that MCP is vertical, agent down to tools, while A2A is horizontal, agent across to agent. An agent can use both at once, MCP to reach its own tools and A2A to ask a peer for help. They are complementary protocols, not rivals.
Neither. A2A is a protocol, an agreed set of rules for how one agent finds another, sends it a task, and receives the result. It does not think or generate answers, and it is not a product you download. What you actually build or run are agents that speak A2A, plus the small description each agent publishes about what it can do. The model inside each agent stays the same model; A2A is just the shared format they use to talk to one another. Treat it the way you would treat HTTP or an API standard, plumbing that two independent programs agree on, not an application in itself.
The fact that two agents can exchange tasks says nothing about whether they should. A2A carries a request, it does not decide if the sender is allowed to make it or if the receiver should comply, so identity and permission have to be designed in around it. Treat each connected agent the way you would any outside service. Confirm who it really is with authentication, decide what it is allowed to ask for with authorization, and keep a human approval step before an agent triggers anything irreversible such as a payment or an external message. Watch for a delegated task that quietly widens its own scope, and for instructions smuggled inside content one agent passes to another, a relative of prompt injection. The setup question mirrors the one for MCP. What can this agent ask of others, what can others ask of it, and who is accountable when work crosses the boundary.