A2A Explained: How AI Agents Delegate to Each Other

A single agent with good tools is an employee. Useful, bounded, and easy to reason about. The interesting problems start when one agent can't finish the job alone and needs to hand part of it to another agent, possibly one built by another team, or by another company entirely. That handoff is what A2A exists for.

This is the second essay in a series on how agents communicate. The first covered MCP, the agent-to-tool layer. The third covers ACP, the rival protocol that merged into this one, and the comparison piece ties it all together. The short version of where A2A sits: MCP connects an agent to capabilities, A2A connects an agent to peers.

Why tools aren't enough

You can get surprisingly far pretending other agents are tools. Wrap an agent in an API, expose it through MCP, call it like a function. I've done it. It works right up until the work stops being a function call, and real work usually does.

A tool call is synchronous and stateless: send arguments, get a result. Delegated work isn't like that. It drags on for minutes or days. Sometimes it fails halfway and somebody has to decide what happens next; sometimes it stops with a question. A hiring agent asked to source candidates might need to ask the requesting agent whether remote is acceptable before it can continue. A function signature has no room for "hang on, I need more information from you." A task does.

How A2A actually works

Google published A2A in 2025 with a long list of launch partners, then handed it to the Linux Foundation, which is exactly what you want to see in a protocol you might bet on: no single vendor holding the pen. Mechanically it's built on boring, proven parts, HTTP and JSON-RPC and server-sent events, and that's a compliment. The interesting design is in three ideas.

Discovery through Agent Cards. Every A2A agent publishes a card, a JSON description at a well-known URL that says what the agent can do, what skills it offers, and how to authenticate with it. When an agent can't complete a task, it doesn't need a hardcoded integration to a specific peer. It reads cards, finds an agent whose declared skills match the need, and delegates. It's a resume plus a front door, machine-readable.

Tasks with a real lifecycle. Delegation creates a task object with states: submitted, working, completed, failed, and the one that makes the whole protocol worth having, input-required. When the remote agent hits something it can't resolve alone, it pauses the task in that state and loops back to the requester with a question. The requester answers, the task resumes. Long-running work streams progress over SSE, and results come back as structured artifacts rather than a blob of prose.

Opacity by design. This is the piece people miss. A2A agents don't share memory, tools, or internal state. Each one is a black box that accepts tasks and returns results. Your agent doesn't get to see how the other agent works, and that's a feature. It means the two sides can be built on different frameworks, run by different companies, and neither has to trust the other with anything more than the task itself. Two businesses work the same way. They exchange commitments, and neither hands the other a login to its systems.

The org-design lens

I keep telling teams to design each agent like a very stupid employee with exactly one job. A2A is what turns those employees into an organization. One agent owns travel booking, another owns expense policy, another owns calendar negotiation, and they coordinate through explicit, inspectable task handoffs rather than one bloated genius agent trying to hold everything in its head.

The parallel goes further than people expect. Everything we know about human organizations starts applying: clear ownership beats overlapping mandates, and the interface between teams matters more than what's inside them. A handoff without a status update is where work goes to die. A2A essentially forces good org design onto your agents, because the protocol only carries tasks, statuses, and artifacts. If you can't express the collaboration in those terms, you haven't defined the jobs clearly enough.

An honest word about timing

Here's the part vendors won't tell you: most companies don't need A2A yet. If all your agents live in one codebase, run on one framework, and answer to one team, a shared orchestrator with plain function calls is simpler and easier to debug. A2A earns its complexity at boundaries: between departments that ship independently, or between your company and a vendor's agent. No boundary, no need for a boundary protocol.

The other cost is verification. Two autonomous, non-deterministic systems negotiating with each other multiplies the ways a workflow can go subtly wrong, and your evals have to grow to match. I wrote about that problem in testing non-deterministic agents: every new component in the pipeline is a new place for failure to hide. Multi-agent handoffs are exactly such a component. Budget for grading the coordination, not just each agent's individual output.

So my playbook is unglamorous. Get MCP right first, because tool access is where the immediate ROI lives. Design narrow agents with clean ownership. Then, when a real boundary shows up, and it will, adopt A2A at that boundary instead of inventing a bespoke agent-messaging scheme you'll regret. The standard exists precisely so that this seam is not your problem to design.

The bottom line

A2A is the org chart layer of the agent stack: discovery through Agent Cards, delegation through tasks, collaboration between black boxes that never have to trust each other's internals. It complements MCP rather than competing with it, one protocol for hands, one for coworkers. If you're deciding how those layers fit your own stack, the field guide to all three protocols is the map.

And if you're staring at a multi-agent architecture decision right now and want a second opinion from someone who has shipped these systems, let's talk →