A year ago, anyone designing a multi-agent system had to pick a side. Google had A2A. IBM had ACP. Anthropic had MCP. Three protocols, none of them obviously wrong, none of them obviously compatible. That race is over.
ACP officially merged into A2A under the Linux Foundation. The three-horse race is now functionally two protocols with complementary purposes. If you missed that quiet September 2025 announcement, it changes how you should be thinking about your agent architecture.
What each layer does
The clearest way to describe the stack is by direction of communication.
They are layers, not alternatives. MCP handles the bottom layer: agent-to-tool connections. A2A handles the middle: agent-to-agent coordination across boundaries. MCP is how a single agent reaches out to a database, a Slack workspace, a GitHub repo. A2A is how one agent hands a task to another agent - possibly built by a different team, running on a different vendor's infrastructure.
A2A defines three foundational things: a way for agents to advertise what they can do (Agent Cards), a structure for the work they exchange (Tasks), and a transport for sending that work over the wire (HTTP, SSE, JSON-RPC 2.0).
Nothing exotic. If your team already runs REST APIs and SSE streams, the transport is familiar. The new thing is the Agent Card - a capability advertisement document that lives at /.well-known/agent-card.json and tells other agents what this one can do and how to reach it.
The Agent Card is to A2A what an OpenAPI spec is to a REST API: the document another system reads before it calls you.
Why the ACP merger matters
IBM Research launched the Agent Communication Protocol in March 2025 to power its BeeAI Platform. Later that month, BeeAI - and with it, ACP - was donated to the Linux Foundation.
When A2A came on the scene a month later, IBM's teams saw immediate alignment and began exploring how to bring the efforts together. ACP is now officially merged with A2A under the Linux Foundation.
This matters for a practical reason: ACP's main design advantage was simplicity. ACP emphasized pure REST APIs that any developer could implement without specialized SDKs, and lightweight messaging patterns for multi-agent workflows. IBM's teams brought that design pressure into the A2A steering committee rather than forking the ecosystem. The A2A Technical Steering Committee now includes IBM alongside representatives from Google, Microsoft, AWS, Cisco, Salesforce, ServiceNow, and SAP.
The practical takeaway: if you were waiting to see whether A2A would fragment, stop waiting. For any operator designing inter-agent integration today, there is essentially no alternative to A2A as of 2026.
Where the standard stands right now
The protocol is now governed by the Linux Foundation's Agentic AI Foundation and has reached version 1.2, with signed agent cards using cryptographic signatures for domain verification. That last part is significant. Signing Agent Cards ties capability advertisement to a verified domain, which closes the obvious spoofing attack: a rogue agent claiming to be your billing service.
A2A has reached 150 organisations in production, not pilot, routing real tasks between agents built on different platforms.
Microsoft, AWS, Salesforce, SAP, and ServiceNow are running A2A in production environments. Those are the platforms your enterprise agents will eventually need to interoperate with.
The question your architecture actually needs to answer
Most teams currently building with agents are in the MCP-only tier, and that is fine. MCP is the right layer for the problem most teams have right now: giving a single agent access to tools and context. A teammate like Beagle sits at this layer - reading Slack threads, surfacing context, connecting to the data a person needs.
A2A becomes load-bearing when you cross two thresholds. First, when the task requires genuine specialization - not just a different tool, but a different agent with different capabilities and possibly different trust boundaries. Second, when those agents are not all under the same roof. Standalone agents excel at specific tasks, but their limitations become apparent when organizations need coordinated action across domains, systems, or areas of expertise.
The sequence that makes sense for most engineering teams:
- Build on MCP first. Get your agent-to-tool layer right. That work does not get thrown away.
- Design agent capabilities as if they will eventually publish an Agent Card, even if they do not yet.
- Add A2A when you have two agents that genuinely need to delegate to each other across a trust or platform boundary.
A2A is designed to complement rather than compete with MCP. That framing is not marketing spin - it reflects how the two protocols were scoped from the beginning. MCP answers the question "what can this agent access?" A2A answers the question "which agent should handle this next, and how does it get the task?"
The consolidation around two layers is genuinely good news for teams with real work to ship. Fewer decisions to revisit, a clear upgrade path, and a governance structure that does not depend on any single vendor staying invested. The two-layer stack is not going to be renegotiated.