A2A vs MCP vs ACP: The Protocol War Is Over, But Teams Are Still Paying for It

A Protocol War That's Already Over

It's 2026, and development teams are still paying the price for a protocol war that was decided long ago.

Someone spent three weeks refactoring a multi-agent system—all because a colleague read an article claiming "ACP is the future" and bet the entire integration layer on that protocol. One line from the retrospective should serve as a warning to every technical decision-maker: "We didn't pick the wrong protocol. We picked a protocol that had already been deprecated—we just didn't know it at the time."

The cost of the refactor itself wasn't even the most expensive part. The real price was this: the team had already promised stakeholders "we're ACP-ready," only to discover that the standard had been merged into another standard two months before the project even kicked off.

The protocol war is over. The problem is, a lot of teams are still fighting it.

Three Protocols, One Already Out

MCP, A2A, and ACP all appeared within the same eighteen-month window, all carrying "protocol" in their names, all promising to solve agent interoperability. Many teams treated them as competitors—or worse, as interchangeable.

They're neither competitors nor interchangeable. And one of them is no longer an option.

MCP (Model Context Protocol) is the vertical integration layer. It governs how a single agent reaches down into the world: invoking tools, reading data, calling APIs. The agent stays in control; the things it touches are passive. An MCP server wrapping a database query doesn't think, doesn't negotiate, doesn't push back—it exposes capabilities and waits. According to public data, MCP has reached 97 million monthly downloads, a 970x increase in eighteen months.

A2A (Agent2Agent Protocol) is the horizontal coordination layer. It governs how one agent delegates work to another agent that has its own reasoning, its own toolset, and its own authority to act. The receiver can accept the task, ask clarifying questions, run for six minutes, or simply refuse. A2A released v1.0 in March 2026, had 150+ supporting organizations by April, and is deeply integrated across Google, Microsoft, and AWS platforms.

ACP (Agent Communication Protocol) was IBM's entry, released in March 2025 to power the BeeAI platform. In August 2025, IBM Research and Google announced that ACP would merge into A2A under the Linux Foundation's LF AI & Data. ACP development is winding down, with its assets and expertise contributed directly to A2A. Kate Blair, who led ACP, has joined the A2A technical steering committee. The original ACP repository has been archived, and its README states plainly: ACP is now part of A2A under Linux Foundation governance.

For developers, this consolidation draws a clear division of labor: MCP is the standard for model-to-tool communication, A2A is the standard for agent-to-agent communication, and ACP is a historical footnote with a migration guide.

The underlying transport for MCP, A2A, and ACP is all built on JSON-RPC 2.0, a fact that's often overlooked. JSON-RPC is a lightweight remote procedure call protocol that encodes requests and responses in JSON; requests carry three fields—method, params, and id—while responses return either result or error. Choosing it means the protocol itself only defines "what a message looks like" without binding to a specific transport channel—it can run over HTTP, WebSocket, or stdio. MCP initially relied on stdio for local communication, then expanded to HTTP+SSE; A2A is built directly on HTTP. Understanding this shared foundation helps clarify: the differences among the three protocols aren't in "how they transmit" but in "what semantics they carry"—tool invocation, task delegation, or agent negotiation. This is also why ACP's merger into A2A was engineering-feasible: the underlying message format was consistent, so migration mainly involved re-aligning the semantic layer and state model rather than rebuilding the transport pipeline from scratch.

The Real Cost of Picking the Wrong Protocol

A migration path from ACP to A2A does exist. BeeAI users can make agents A2A-compliant via the A2AServer adapter, and external A2A agents can integrate into BeeAI applications through A2AAgent.

But adapters can't undo architectural decisions built on ACP assumptions. If your system was built around ACP's proxy communication model, migrating to A2A's peer-to-peer task delegation isn't a find-and-replace operation—it's a re-architecture of the coordination layer.

The consolidation itself was the right decision. One standard for inter-agent communication is better than two competing ones. The Linux Foundation's framing was to bring ACP's assets and expertise into A2A, accelerating progress toward "a single, stronger standard for AI agent communication and collaboration." The cost falls on the teams that already shipped.

The Vertical and Horizontal Two-Layer Stack

The mental model that has held up in production is a two-layer stack: MCP handles the vertical, A2A handles the horizontal. They're not competitors—they're complements.

A June 2026 unified interoperability framework paper lays this out clearly: MCP and A2A are complementary rather than competing, and a unified approach can reduce integration complexity by roughly 60%–70% compared to ad-hoc solutions. Another 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 through capability-based Agent Cards.

The practical decision framework that holds up is:

Use MCP when an agent needs to reach down into the world. Fast, structured, request-response operations—database queries, file reads, API calls. The agent stays in control; the objects it touches stay passive.

Use A2A when independent agents need to delegate work across boundaries you don't fully control. The remote end is genuinely an autonomous agent with reasoning capability, not a passive tool. Tasks may run for minutes or even hours, and the receiver may ask clarifying questions or refuse.

Use both when the system has both vertical and horizontal needs. Most production systems do. A2A agents call MCP for context; MCP-hosted tools trigger A2A delegations. The two layers compose freely.

The Agent Card is A2A's "capability business card", typically exposed at the /.well-known/agent.json path. It contains the agent's name, description, supported skills, input/output modalities, authentication methods, and service endpoints. It solves the problem of "discovery": before delegating a task, the caller fetches the other party's Agent Card to determine whether that agent can handle the current task and what authentication is required. This contrasts with MCP's tools/list mechanism—MCP lists the capability inventory of passive tools, whereas A2A's Agent Card describes the service contract of an active agent. Since v0.3, Agent Cards can carry JWS signatures, and verifiers can use the public key to confirm the card hasn't been tampered with. But note: Agent Cards are self-declared—an agent says what it can do, and the protocol doesn't mandate third-party endorsement. That's the technical root of "compliance doesn't equal trust."

What "Enterprise-Ready" Actually Means

A2A v1.0's release was its milestone from "promising standard" to "production-grade open standard." The features that matter for enterprise deployment are specific:

Signed Agent Cards provide cryptographic identity verification. Since v0.3, Agent Cards can carry JWS cryptographic signatures, and receivers can verify that a card hasn't been tampered with and genuinely comes from the claimed provider.

Enterprise-grade multi-tenancy and modern security workflows. The v1.0 spec introduced multi-protocol support, multi-tenancy, and a clear migration path for early adopters.

Web-aligned architecture built for scale. The protocol supports familiar security and load-balancing patterns for high-scale reliability.

But enterprise-ready doesn't equal production-safe. The A2A spec itself is very careful about what it does and doesn't guarantee. The protocol solves "how to transmit," not "how to trust." Task status is self-reported by the executing party. A signed Agent Card proves identity, not quality of performance. Verification—acceptance testing, logging, human approval—must be built by the adopter.

Salesforce's release is the clearest signal that A2A has entered productized packaging. Agentforce's native third-party orchestration "extends Agentforce to any A2A-compatible ecosystem," letting the system orchestrate agents from AWS, Azure, and Google, or participate as a sub-agent in external architectures.

But the "A2A-compatible" label certifies less than the marketing implies. The counterparty's identity is entirely self-declared—Agent Card signatures are optional, not mandatory. There's no formal discovery registry; the registry spec was never released, and maintainers redirected that need to adjacent specs. The protocol is designed for opaque execution, which means compliance certifies the conversation, not the agent's behavior or conduct.

JWS (JSON Web Signature) is the cryptographic standard behind Agent Card signatures, part of the JOSE (JSON Object Signing and Encryption) family and related to JWT. It works like this: the issuer signs the card content's canonicalized JSON with a private key, producing a three-part string (header, payload, signature); the verifier uses the issuer's public key to validate. JWS guarantees integrity and authenticity of origin—the card wasn't modified and was genuinely issued by the holder of the private key. But it doesn't guarantee the content is true: a malicious agent can honestly sign a card claiming "I'm extremely capable and absolutely reliable." Moreover, JWS verification presupposes that the verifier has obtained the public key in a trustworthy way, which pushes the problem back to key distribution and trust anchors—the protocol layer once again leaves the hard problem to the adopter. This is why the article repeatedly stresses: signatures solve identity, not performance.

Quantifying Protocol Choice with Data

The comparative literature has moved past qualitative assessments; the numbers are specific enough to plan around.

Reduced integration complexity. The unified TLAS framework estimates that using MCP and A2A together in a layered approach can reduce integration complexity by 60%–70% compared to ad-hoc solutions.

Adoption speed. MCP SDK monthly downloads have reached 97 million, with 42,753 servers in the registry. A2A reached 150+ supporting organizations within its first year and is embedded in Azure AI Foundry, Amazon Bedrock AgentCore, and Google Cloud.

Production deployment. A survey of 100 senior software engineers found that 41% of software organizations report MCP in production. Gartner predicts 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 Taking Shape

The broader landscape has consolidated into a layered stack. Understanding where each protocol sits is the key to avoiding the same mistake.

Identity and trust layer. Signed Agent Cards give A2A verifiable identity. Web Bot Auth points the web in the same direction. Payment authorization carries cryptographic accountability. What doesn't yet exist is a unified way for an agent to carry "who it is, who it represents, and what it can do" across all layers at once. That's still the next round of standards competition.

Inter-agent coordination layer. A2A is the standard. ACP's merger cemented this.

Tool access layer. MCP is the standard. The registry expands through bottom-up momentum, while the A2A registry remains an open RFC.

Human-computer interface layer. AG-UI and related efforts stream agent output into applications. This layer is still early, framework-led rather than foundation-governed.

Payment layer. AP2, Agentic Commerce Protocol, x402, and others are competing. The practitioner's advice is blunt: treat agent payments as a capability to pilot behind an abstraction layer, not a foundation to bet your life on.

The Trade-Offs You're Accepting

Choosing A2A and MCP means accepting that the stack is still evolving. ACP's merger proved the ecosystem can consolidate well. The payment layer is the next test of that capability.

You also have to accept that "compliance" is a procurement issue, not a technical guarantee. Because large enterprise suites now sell "orchestration across any A2A-compatible ecosystem" as a formal product, the verification burden falls on the buyer. The label provides a common language for connection, but not a guarantee of security or identity. Organizations must verify the agents they connect to internal systems, because the protocol remains agnostic to participants' underlying intent or reliability.

Meanwhile, MCP has a scaling problem the protocol hasn't fully solved. Every tool definition consumes tokens in the agent's context window. When MCP servers reach into the dozens, tool descriptions alone can consume most of the context window before the model has even read the user's message. MCP's progressive discovery proposal mitigates this, but it's a mitigation, not a solution.

The teams that got it right aren't picking sides in a war that's already over. They're carefully drawing boundaries: MCP as the tool access layer, A2A as the coordination layer, and building the verification layer that neither protocol provides.

So the question comes back to you: If you're building on a protocol today, can you clearly state what it guarantees and what it leaves to you? Or are you still treating "compliance" as a synonym for "security"?