MCP vs A2A vs ACP: A Field Guide to How AI Agents Communicate

One agent with good tools is useful. Several agents that can hand work to each other stop being a chatbot and start being an organization. Underneath either setup sits the same unglamorous question: how does everything talk to everything else?

Three protocol names dominate that conversation: MCP, A2A, and ACP. They get compared as if they were three competitors, and that framing is wrong in a useful way. Two of them never competed at all, and the two that did have already merged. This essay is the map. Each protocol also has its own deep dive in this series: MCP, A2A, and ACP.

Two different jobs

Start with the distinction that dissolves most of the confusion. An agent has two kinds of conversations, and they need different plumbing.

• Agent to tool. The agent needs a capability: run this query, send this email. The other side isn't intelligent. It executes and returns. This is MCP's job.
• Agent to agent. The agent needs a colleague: another autonomous system that plans, works over time, and might come back with questions. This is A2A's job, and it was ACP's job too, which is exactly why one of them had to go.

Comparing MCP to A2A is comparing a screwdriver to a phone. The real comparison was A2A versus ACP, and the market resolved it.

MCP: the hands

The Model Context Protocol, from Anthropic, standardizes how a host application connects its model to capabilities. The host embeds an MCP client, the tool side runs an MCP server, and tool calls flow between them as structured JSON-RPC: model picks a tool, client routes the call, server executes and returns a result the model can reason over. Before MCP, every model-tool pairing was a custom integration and the ecosystem was drowning in glue code. After it, tools are written once and work everywhere, which is why it became the layer everyone standardized on almost immediately. The mistakes teams make with it are about discipline rather than protocol: too many tools per agent, too little attention to the trust boundary. The MCP deep dive covers both.

A2A: the coworkers

A2A, started by Google and now under the Linux Foundation, standardizes delegation between autonomous agents. Discovery happens through Agent Cards published at well-known URLs, so an agent that can't finish a task can find a peer whose declared skills fit. Work travels as tasks with a real lifecycle, and the state that justifies the whole protocol is input-required: the remote agent can pause mid-task, ask the requester a question, and resume. Agents stay opaque to each other, no shared memory, no shared tools, which is what lets systems from different vendors and frameworks collaborate without trusting each other's internals. It's org design as a wire protocol, and the same rules apply: it shines at boundaries and adds overhead where none exist. The A2A deep dive goes deeper, including when not to bother yet.

ACP: the one that merged

ACP, from IBM's BeeAI effort, attacked the same agent-to-agent problem with a REST-first philosophy: agents as plain HTTP services, discovery through an Agent Manifest, sync responses for fast tasks and async SSE streams for long ones. It was a credible, simpler rival to A2A for much of 2025, and then IBM did the mature thing and folded it into the A2A effort under the Linux Foundation. The concepts survived inside the winner; the separate spec did not. If you're evaluating protocols today, ACP is history, but instructive history: the ACP essay pulls out what the merge teaches about betting on young standards without getting burned.

How they compose in production

In a real deployment the two surviving protocols stack. Picture a procurement workflow. Your purchasing agent uses MCP to read inventory and pull contract terms: tool calls, all of it. Then it needs quotes evaluated against a supplier's own agent, an autonomous system your company doesn't control. That handoff goes over A2A. Your agent finds the supplier agent's card, hands over the evaluation, answers whatever input-required questions come back, and gets a structured result. That agent, in turn, is using its own MCP servers on its side of the fence. Every agent is an MCP client downward and an A2A peer sideways.

The composition is also why the layering matters for safety and evals. Tool calls are auditable actions you can permission per agent, which pairs naturally with narrow, one-job agent design. Delegations are commitments between non-deterministic systems, which your evaluation suite has to grade as coordination, not just output, a problem I dig into in testing non-deterministic agents.

What to adopt, in what order

• Now, for everyone: MCP. Tool access is where agents earn their keep, the ecosystem is mature, and the cost is low. Pick the two or three internal systems with the most agent leverage and stand up servers for them.
• When a boundary appears: A2A. The trigger is organizational, not technical: agents owned by different teams, companies, or vendors that must collaborate. Inside one team, an orchestrator and function calls remain simpler.
• Never: a proprietary agent-messaging layer. The standards war is over. Building your own dialect now buys you nothing except a migration project later.
• If you're on ACP: port to A2A. The concepts map nearly one to one, so the migration is mostly mechanical.

The bottom line

The agent communication map is settled enough to act on. MCP is the standard for giving agents capabilities, A2A is the standard for letting them delegate, and ACP's merge means you don't have to hedge between rivals at the agent-to-agent layer. At most companies the protocol choice turns out to be the easy part. The hard questions are which workflows deserve agents at all, what each agent may touch, and how you'll know the system is working. Those are strategy and operating-model questions wearing a technical costume.

That's the layer I work at: helping leadership teams turn agent plumbing into an actual AI strategy with owners, boundaries, and measurable outcomes. If you're drawing this map for your own company, let's talk →