There are now four serious proposals for how AI agents should communicate. They arrived within eight months of each other. They overlap in ways that are confusing if you're reading the specs, and diverge in ways that matter enormously if you're actually building.
If you're making architecture decisions right now, you need to understand what each protocol actually solves—not the marketing framing, but the technical problem it addresses.
Here's the honest breakdown.
The Quick Map
| Protocol | Author | Layer | Core Problem Solved | |----------|--------|-------|---------------------| | MCP | Anthropic | Tool use | How agents access external data and tools | | A2A | Google DeepMind | Agent-to-agent | How agents communicate and delegate tasks | | ACP | IBM / Linux Foundation | Agent-to-agent | Open, vendor-neutral agent messaging | | ANP | Hugging Face / Partners | Agent-to-agent | Decentralized agent discovery and communication |
The first thing to notice: MCP and A2A/ACP/ANP are solving different problems entirely. MCP is about how an agent uses tools. The others are about how agents talk to each other. Conflating them is common and causes bad architectural decisions.
MCP: The Tool Access Layer
The Model Context Protocol (Anthropic, released 2025) solves a specific, well-defined problem: how does an LLM-powered agent reliably access external resources—APIs, databases, files, services—without brittle bespoke integrations?
Before MCP, every tool integration was custom. You wrote glue code. It broke when APIs changed. Different models handled tool calls differently. The ecosystem was fragmented.
MCP standardizes this. It defines a protocol for tool servers that any MCP-compatible client can call. You write an MCP server for your database, and any agent that speaks MCP can use it. The protocol specifies how tools are described, how requests are formed, how results come back, and how errors are handled.
What it doesn't solve: Agent-to-agent communication. MCP assumes a single agent orchestrating tool calls. It says nothing about how one agent delegates a subtask to another agent, passes context between agents, or coordinates parallel agent workflows.
Adoption: High. Claude, Cursor, many open-source frameworks. Growing MCP server ecosystem. This is the closest thing to an actual standard in the current landscape.
When to implement it: If you're building any agent that needs to access external tools, APIs, or data sources. This is table stakes.
A2A: Google's Bet on Agent Networks
The Agent-to-Agent protocol (Google DeepMind, April 2026) addresses the coordination problem that MCP leaves open: how do agents in a network communicate, delegate tasks, and return results to each other?
A2A introduces the concept of agent cards—standardized capability declarations that let agents discover what other agents can do. It specifies how a calling agent issues a task to a receiving agent, how the receiving agent accepts or declines, how results and streaming updates come back, and how authentication works in multi-agent contexts.
The architecture model is hierarchical: orchestrator agents delegate to specialist agents. The protocol is built around HTTP and JSON, which means it's familiar to most engineering teams.
What it doesn't solve: Decentralization. A2A assumes you're building a controlled agent network. It doesn't have a strong answer for agent discovery across organizational boundaries or open ecosystems. It's also Google's protocol—which raises governance questions for organizations worried about vendor alignment.
Adoption: Early. Google released this in April 2026. Several large enterprise software vendors announced support quickly. Real production deployments are limited.
When to implement it: If you're building multi-agent systems within a controlled organizational context and want a well-specified protocol with likely enterprise tooling support. Evaluate lock-in risk carefully.
ACP: The Open Standard Attempt
The Agent Communication Protocol (IBM, Linux Foundation) is the attempt to create an open, vendor-neutral standard for agent communication that no single company owns.
Architecturally, ACP is similar to A2A in scope—it addresses how agents communicate and delegate—but it prioritizes openness and governance over tight Google integration. The Linux Foundation involvement means the spec is maintained through an open process rather than by a single vendor's roadmap.
The protocol is RESTful, using standard HTTP semantics. It specifies message formats for agent requests and responses, supports both synchronous and streaming interactions, and includes provisions for authentication and error handling.
What it doesn't solve: Adoption. ACP is well-designed but currently has less real-world traction than MCP or even A2A. "Open standard" doesn't mean deployed at scale.
When to implement it: If your organization has strong vendor-neutrality requirements and you have the runway to bet on a standard that will take time to achieve critical mass. Or if you're contributing to the open ecosystem and want to be part of shaping what "open agent infrastructure" looks like.
ANP: Decentralized Agent Discovery
The Agent Network Protocol (Hugging Face, co-authored with multiple partners) addresses a problem the others barely touch: how do agents find each other across organizational and institutional boundaries?
ANP is built on decentralized identifiers (DIDs) and verifiable credentials—concepts from the web3/identity space. The core idea is that agents should be able to publish their capabilities and discover other agents without relying on a central registry controlled by any particular vendor.
This is a different architectural bet than A2A or ACP. Those protocols assume a closed or semi-closed agent network. ANP assumes an open agent ecosystem where your agents might interact with agents from other organizations, other platforms, or even autonomous agents on public infrastructure.
What it doesn't solve: Everything downstream of discovery. Once you've found an agent, ANP defers to MCP/A2A/ACP for the actual communication. It's a discovery and identity layer, not a complete communication stack.
Adoption: Early and ecosystem-dependent. Requires broader infrastructure investment than the others. Most relevant if you're building toward truly open, decentralized agent networks—which most enterprise teams are not, currently.
When to implement it: If you're building platforms or infrastructure for multi-organization agent coordination, or if decentralized identity is a core architectural requirement.
How to Decide What to Implement
The framing of "which protocol wins" is the wrong question. These protocols aren't in direct competition the way programming languages or databases compete. They solve different problems at different layers.
The more useful question is: what coordination problems does your architecture actually have?
If your agents need to use external tools: Implement MCP. This is not really a decision at this point—it's table stakes for any serious agent system.
If you're building controlled multi-agent workflows: A2A or ACP, depending on your vendor neutrality requirements. A2A if you're comfortable with Google's ecosystem trajectory and want likely enterprise tool support. ACP if you have strong neutrality requirements and time to wait for adoption.
If you're building open, cross-organizational agent infrastructure: Look seriously at ANP for the discovery layer, with MCP/A2A/ACP for communication.
In practice: Most production agent systems currently use MCP for tool access and either custom internal protocols or nothing for agent-to-agent coordination. The multi-agent coordination protocols are still in their early adoption phase—which means you have time to design for them without yet committing to a specific implementation.
The Governance Dimension That Gets Underweighted
Protocol discussions typically stay technical. But there's a governance dimension to protocol selection that matters as much as the architecture.
When you implement a protocol, you're making a decision about who controls the spec. Anthropic controls MCP. Google controls A2A. The Linux Foundation controls ACP through an open governance process. Hugging Face and partners control ANP.
This matters for three reasons:
1. Breaking changes. If the controlling entity changes the spec, you have to follow or fork. With open governance (ACP, ANP), you have a voice in that process. With vendor-controlled protocols (MCP, A2A), you have a support contract or a GitHub issue.
2. Compliance. If your organization operates under EU AI Act, GDPR, or sector-specific regulations, the governance of the protocols you implement may affect your compliance posture. A protocol owned by a US cloud provider may create issues for EU data residency requirements.
3. Competitive dynamics. If you're building a product on top of agents, your protocol choices affect your supply chain. Building deep integrations on A2A means you're building on Google infrastructure. That's fine until it isn't.
None of this should be a dealbreaker—but it should be a deliberate decision, not an afterthought.
What to Watch in the Next 90 Days
The protocol landscape is still moving. Specifically:
- MCP v2 spec development is ongoing. The tool-use model is evolving to support more complex agent patterns.
- A2A adoption by enterprise software vendors will be the clearest signal of whether it becomes the de facto standard for enterprise multi-agent systems. Watch SAP, ServiceNow, Workday.
- ACP governance — who joins the Linux Foundation working group will determine whether this has real traction or becomes a well-designed spec nobody implements.
- Regulatory interest — EU AI Act enforcement authorities have flagged agent communication protocols as an area of scrutiny. How liability travels through agent networks is an open governance question, and the protocols you use may affect your compliance posture as regulators develop clearer guidance.
The organizations that will make the best protocol decisions over the next year are the ones that treat this as a structured intelligence problem—not a question of "which blog post to trust."
Resomnium builds governance infrastructure for multi-agent systems. For how protocol mismatches cause coordination failures in practice, see Why Multi-Agent Systems Fail. Making protocol decisions for your own architecture? Get in touch.