How AI Agents Actually Talk to Each Other
And why "MCP vs A2A" is a fight that doesn't exist
TLDR
Three protocols. One of them isn’t really in the race anymore. MCP shipped in November 2024 and now has more than 10,000 servers. A2A shipped in April 2025. ACP shipped a month earlier, in March 2025, and folded into A2A five months after that. By December 2025, both survivors were sitting under the Linux Foundation.
So the acronym soup you keep scrolling past is really two questions. How does an agent reach a tool? How does one agent reach another? MCP answers the first. A2A answers the second. They were never competing. Anyone framing this as “MCP vs A2A” is selling a fight that doesn’t exist.
The problem protocols actually solve
Before any of this, connecting an agent to the outside world meant writing glue. One model, one tool, one bespoke integration. Add a second model and a second tool and you’re maintaining four. Ten models and ten tools is a hundred connectors nobody wants to own. Engineers call it the N×M problem, and it’s the same reason we standardized on HTTP, ODBC, and USB.
Agents made it worse, because an agent doesn’t just call one tool once. It reasons, calls, reads the result, reasons again. We covered what that loop looks like under load in Designing AI Agents That Think in Real Time, and what a full production agent stack actually costs to run in From Prompts to Partners: How LinkedIn Built Its Agentic Stack. Once you’re running agents that call tools and hand work to other agents, the glue stops being a nuisance and becomes the system. That’s what these protocols replace.
MCP: how an agent reaches a tool
MCP is agent-to-tool. Anthropic open-sourced it in November 2024, and the shape is deliberately boring, which is why it stuck.
A host application, Claude, Cursor, VS Code, whatever the user is actually in, carries an embedded MCP client. The user asks for something. The client formats the request and routes it to the right MCP server. The server does the real work: queries the database, hits the API, reads the file. Then it hands back a structured response, and the agent keeps reasoning. Messages are JSON-RPC 2.0. Local servers talk over stdio; remote ones talk over Streamable HTTP.
That’s the whole contract. Build one Postgres MCP server and every MCP-speaking client can use it, which is how the count crossed 10,000 inside a year. The interesting problems show up when those servers go remote, multi-tenant, and authenticated, exactly where we went deep in Building Secure, Scalable Remote MCP Servers. The protocol is simple. Running it in production is not.
A2A: how an agent finds and delegates to another agent
A2A is agent-to-agent. Google announced it in April 2025 to solve the problem MCP doesn’t touch: an agent that can’t finish a task alone needs to find one that can, even when the other agent was built by a different team, on a different framework, running somewhere else entirely.
Discovery works through an Agent Card: a JSON document the agent publishes describing what it can do, how to authenticate, and where to send work. For public agents it lives at a well-known path, /.well-known/agent-card.json, following RFC 8615. If you’ve ever done service discovery in a microservices estate, this is the same idea with a different filename, the Agent Card is a service descriptor for autonomous agents. (We wrote about where that pattern helps and where it bites in Atlassian’s Playbook on Microservices.)
Delegation runs as a Task with an actual lifecycle: submitted, working, then completed, canceled, or failed. The state worth knowing is input-required. When the second agent hits a point where it needs more from the caller — a missing parameter, a confirmation, a clarification — it doesn’t guess and it doesn’t die. It pauses in input-required, asks, and resumes when the answer comes back. Transport is JSON-RPC 2.0 over HTTP, with Server-Sent Events for streaming and push notifications for long jobs. That input-required loop is the part most homegrown handoffs get wrong, and it’s the reason a standard was worth having.
ACP: absorbed, not abandoned
Here’s where people get catfished by the acronym. There are two different things called ACP, and only one of them is in this conversation.
The one in most comparisons is IBM Research’s Agent Communication Protocol, launched in March 2025 for its BeeAI platform. It took a REST-first stance where A2A leaned on JSON-RPC. Peers were described in an Agent Manifest, called directly over HTTP, and answered synchronously for fast tasks or over async SSE streams for slow ones. Its real contribution was reliability for long-running enterprise work: task persistence, async resumption, webhook-based progress.
In August 2025, IBM and Google stopped competing. ACP joined A2A under the Linux Foundation’s LF AI & Data, ACP development wound down, and its persistence and async ideas were folded into A2A. So ACP didn’t fail — it lost the brand and won the argument. Its best features are table stakes in A2A now.
(The other ACP is Zed’s Agent Client Protocol, also from 2025, which governs how a coding agent talks to your editor. Different layer, different problem, not merged into anything. If a comparison lumps the two together, it hasn’t done the reading.)
Who owns the plumbing now
Both survivors left their original owners’ hands within eighteen months. Google transferred A2A to the Linux Foundation in June 2025. Anthropic donated MCP in December 2025, as a founding project of the newly formed Agentic AI Foundation — a directed fund under the same Linux Foundation, launched on December 9 alongside Block’s goose and OpenAI’s AGENTS.md.
The point isn’t the org chart. It’s that neither protocol is a single vendor’s leverage anymore. If you’re betting a roadmap on MCP and A2A, you’re betting on standards with neutral governance and an RFC process, not on Anthropic and Google staying friendly. For anyone who’s had a proprietary integration deprecated out from under them, that’s the whole ballgame.
How they fit together in production
In a real system you run both, and they don’t overlap. A2A is how your agents talk to each other. MCP is how each agent talks to its tools.
Concretely: a support agent gets a refund it can’t approve, uses A2A to hand it to a billing agent, and the billing agent uses MCP to actually hit the payments API and the database. A2A crosses the boundary between agents. MCP crosses the boundary between an agent and the world. One request can ride both on its way to done.
The trap is thinking the protocol existing means you need the architecture. You mostly don’t. Most tasks want one capable agent with good MCP tools, not a swarm of specialists paging each other over A2A. Every hop you add is another failure mode, another place to lose context, another thing to debug at 2 a.m. We’ve watched teams walk this back, Prime Video Gives Up On Distributed Services to be 90% Faster and Why Microservices Aren’t Always the Right Answer are the agent version of a lesson distributed systems already taught. Reach for A2A when you have genuinely independent agents, owned by different teams, that need to collaborate across a boundary. Not before.
What to know as a Lead Engineer
Strip the acronyms and this is a story engineering has already lived. We spent a decade learning that splitting a monolith into services buys you nothing until the boundaries are real, and that service discovery and typed contracts are what make the split survivable. Agents are running the same playbook a decade faster. MCP is the typed contract to your tools. A2A is service discovery and task handoff for agents. ACP was a parallel proposal that got merged once the winner was obvious. That’s not hype collapsing — that’s a field converging, which is what healthy standardization looks like.
So the protocols aren’t the hard part. They’re plumbing, and good plumbing is supposed to be boring. The hard part is the judgment underneath: when a task actually needs a second agent instead of a second tool, where to draw the boundary, what happens when a peer returns garbage or nothing at all. That decision doesn’t come from a spec. It comes from you, which is exactly the part of the job that isn’t getting automated away.
Learn MCP and A2A. Ignore anyone still framing them as rivals. And before you wire up a second agent, make sure the task wouldn’t have been better served by a second tool.
Are you running MCP and A2A together in your stack yet, or is one capable agent with good tools still doing the job?