I spent three weeks refactoring a multi-agent system because a teammate read that ACP was the future and built the integration layer around it. The post-mortem had a line I still think about: "We didn't pick the wrong protocol. We picked a protocol that had already been deprecated and didn't notice."
The rework wasn't the expensive part. The expensive part was that we'd told stakeholders we were ACP-ready, and when the merger landed, we had to explain that the standard we'd bet on had folded into another standard two months before we started building.
The protocol war is over. Most teams are still fighting it.
The Three Names and the One That's Already Gone
The confusion is understandable. MCP, A2A, and ACP arrived in the same eighteen-month window, all carried the word "protocol," and all promised to solve agent interoperability. Most teams still treat them as competing standards or, worse, as interchangeable.
They are neither. And one of them is no longer a choice.
Model Context Protocol (MCP) is the vertical integration layer. It standardizes how a single agent reaches down into the world: calling tools, reading data, invoking APIs. The agent stays in charge, and the things it touches are passive. An MCP server that wraps a database query does not think, negotiate, or push back. It exposes capabilities and waits. By March 2026, MCP had reached 97 million monthly downloads, a 970x increase in eighteen months.
Agent2Agent Protocol (A2A) is the horizontal coordination layer. It standardizes how one agent delegates work to another agent that has its own reasoning, its own tools, and its own authority to act. The receiving agent can accept the task, ask a clarifying question, run for six minutes, or refuse. A2A reached v1.0 in March 2026, and by April the project counted more than 150 supporting organizations, with deep integration across Google, Microsoft, and AWS platforms.
Agent Communication Protocol (ACP) was IBM's entry, launched in March 2025 to power the BeeAI platform. In August 2025, IBM Research and Google announced that ACP would join forces with A2A under the Linux Foundation's LF AI & Data umbrella. ACP development is now winding down. Its assets and expertise are being contributed directly to A2A. Kate Blair, who led ACP at IBM Research, joined the A2A Technical Steering Committee. The original ACP repository is archived, and its own README states that ACP is now part of A2A under Linux Foundation governance.
For developers, this consolidation produces a clear division of labor. MCP is the standard for model-to-tool communication. A2A is the standard for agent-to-agent communication. ACP is a historical footnote with a migration guide.
What the Protocol War Actually Cost
The rework I described wasn't unique. The pattern shows up across teams that built on ACP before the merger was announced.
The ACP-to-A2A migration path exists. BeeAI users can make agents A2A-compliant using the A2AServer adapter, and external A2A agents can be integrated into BeeAI applications using A2AAgent. But the adapter doesn't undo the architectural decisions made on top of ACP's assumptions. If your system was built around ACP's brokered communication model, moving to A2A's peer-to-peer task delegation is not a find-and-replace operation. It's a re-architecture of the coordination layer.
The consolidation itself was the right move. A single standard for agent-to-agent communication is better than two competing ones. The Linux Foundation's framing is that bringing ACP's assets and expertise into A2A accelerates progress toward "a single, more powerful standard for how AI agents communicate and collaborate". The cost was borne by the teams that had already shipped.
The Vertical and Horizontal Stack
The mental model that has held up in production is a two-layer stack. MCP handles the vertical. A2A handles the horizontal. They are not competing. They are complementary.
The unified interoperability framework paper from June 2026 maps this explicitly: MCP and A2A are complementary rather than competing, and a unified approach reduces integration complexity by an estimated 60–70% compared to ad-hoc solutions. A survey of agent interoperability protocols reached the same conclusion: MCP provides a JSON-RPC client-server interface for secure tool invocation, while A2A enables peer-to-peer task delegation using capability-based Agent Cards.
The practical decision framework that has held up:
Use MCP when an agent needs to reach down into the world. Fast, structured, request-response operations. A database query, a file read, an API call. The agent stays in charge; the thing it touches stays passive.
Use A2A when independent agents need to delegate work across a boundary you don't fully control. When the remote endpoint is genuinely an autonomous agent capable of reasoning, not just a passive tool. When the task might run for minutes or hours, and the receiving agent might ask clarifying questions or refuse.
Use both when your system has both vertical and horizontal needs, which most production systems do. An A2A agent calls MCP to fetch context. An MCP-hosted tool triggers an A2A delegation. The layers compose.
What Enterprise Readiness Actually Means
A2A's v1.0 release in March 2026 was the milestone that moved it from "promising standard" to "production-ready open standard". The features that matter for enterprise deployment are concrete:
Signed Agent Cards for cryptographic identity verification. From v0.3, Agent Cards can carry JWS cryptographic signatures, allowing the receiving party to verify that the card hasn't been tampered with and genuinely originates from the claimed provider.
Enterprise-grade multi-tenancy and modernized security flows. The v1.0 specification introduced multi-protocol support, multi-tenancy, and a defined migration path for early adopters.
Web-aligned architecture for scale. The protocol supports familiar security and load-balancing patterns for high-scale reliability.
But enterprise readiness is not the same as production safety. The A2A specification itself is careful about what it does and does not guarantee. The protocol solves "how to transmit," not "how to trust." Task state is self-reported by the executing party. A signed Agent Card proves identity, not履约质量. The verification step—acceptance testing, logging, human approval—must be built by the adopter.
Salesforce's Winter '27 Release, generally available in October 2026, is the clearest signal that A2A has crossed into product packaging. Agentforce's native Third-Party Orchestration "extends Agentforce across any A2A-compliant ecosystem," allowing the system to orchestrate agents from AWS, Azure, and Google or participate as a subagent in external architectures.
But the label "A2A-compliant" certifies less than the marketing implies. Counterparty identity is entirely self-asserted—Agent Card signatures are optional, not mandatory. There is no formal registry for discovery; the registry specification never shipped, and maintainers redirected the need to adjacent specifications. The protocol is designed for opaque execution, meaning compliance certifies the conversation, not the conduct or behavior of the agent itself.
What the Research Quantifies
The comparison literature has moved past qualitative assessments. The numbers are specific enough to plan against.
Integration complexity reduction. The unified TLAS framework estimates that a layered approach using both MCP and A2A reduces integration complexity by 60–70% compared to ad-hoc solutions.
Adoption velocity. MCP reached 97 million monthly SDK downloads and a registry of 42,753 servers by October 2026. A2A reached 150+ supporting organizations within its first year and is embedded in Azure AI Foundry, Amazon Bedrock AgentCore, and Google Cloud.
Production deployment. 41% of software organizations report MCP in production, according to a July 2026 survey of 100 senior software engineers. Gartner projects that by the end of 2026, 40% of enterprise applications will include task-specific AI agents, and 75% of API gateway vendors will have MCP features.
The Protocol Stack That's Taking Shape
The broader landscape has consolidated into a layered stack, and understanding where each protocol sits is what prevents the rework I described.
Identity and trust. Signed Agent Cards give A2A verifiable identities. Web Bot Auth points the same direction for the web. Payment mandates carry cryptographic accountability. What does not yet exist is a unified way for an agent to carry who it is, who it acts for, and what it may do across all layers at once. That remains the defining standards fight of 2027.
Agent-to-agent coordination. A2A is the standard. The ACP merger consolidated the field.
Tool access. MCP is the standard. The registry is scaling on bottom-up momentum, while the A2A registry remains an open RFC.
Human interface. AG-UI and companion efforts for streaming agent output into applications. This layer is early and framework-led rather than foundation-governed.
Payments. AP2, Agentic Commerce Protocol, x402, and others are competing. The guidance from practitioners is candid: treat agent payments as a capability to pilot behind an abstraction, not a foundation to marry.
The Trade-Off You're Accepting
Choosing A2A and MCP means accepting that the stack is still evolving. The ACP merger showed this ecosystem can consolidate well. The payments layer is where that muscle gets tested next.
You're also accepting that "compliant" is a procurement question, not a technical guarantee. Because a major enterprise suite now sells orchestration across any A2A-compliant ecosystem as a generally available product, the burden of verification falls on the buyer. The label provides a common language for connection. It does not provide a guarantee of safety or identity. Organizations must validate the agents they connect to their internal systems, as the protocol remains agnostic to the underlying intent or reliability of the participants.
And you're accepting that MCP has a scaling problem the protocol hasn't fully solved. Every tool definition consumes tokens in the agent's context window. At dozens of MCP servers, tool descriptions alone can consume the majority of the context window before the model reads the user's message. The MCP specification's progressive discovery recommendation addresses this, but it's a mitigation, not a solution.
The teams that are getting this right aren't choosing sides in a war that's already ended. They're drawing the boundary carefully, treating MCP as the tool-access layer and A2A as the coordination layer, and building the verification layer that neither protocol provides.
So here's my question: If you're building on a protocol today, can you articulate what it guarantees and what it leaves to you—or are you still treating "compliant" as a synonym for "safe"?
I'd love to hear where you've landed. A two-layer stack, a migration off ACP you'd rather not talk about, or a protocol decision you're still defending—and what finally made you look at the governance instead of the spec?
Top comments (0)