On this page
Part 4 of the seven-part series Building an Agentic NOC. Each part builds on the ones before it; the full list is at the end.
You have now built both protocols, so this is a good moment to step back from code and look at how MCP, A2A, and ACP actually emerged, because the history is not trivia. It explains why the ecosystem settled where it did, why building on these two protocols in particular is the safe bet rather than a coin flip, and why a third protocol you will still see referenced is no longer something you build against. Every date and event below is cited to a primary source, because a timeline is exactly the kind of thing a careful reader checks.
Two problems, and the order they were solved in
Recall the two axes from the first post. An agent needs to reach tools, the vertical problem, and agents need to reach each other, the horizontal problem. What is striking about the last two years is that the industry solved these in that order, and each was solved by a different company, and the two solutions turned out to compose rather than compete. That is not how standards usually go, and it is worth understanding why it went well this time.
November 2024: MCP, and how fast it won
Anthropic introduced the Model Context Protocol in November 2024, with the first specification revision dated 2024-11-05. It was open from the start, with a specification, SDKs, and a set of prebuilt servers for common systems like Google Drive, Slack, GitHub, Git, and Postgres. The bet was that if you standardised the vertical connection, the messy M times N problem of every model integrating with every tool would collapse into M plus N.
The bet paid off unusually quickly. Within a year the community had built a large ecosystem of servers, SDKs existed for every major language, and, tellingly, competitors adopted it: OpenAI and Google DeepMind both took up MCP, and Microsoft partnered with Anthropic on an official C# SDK. When your direct competitors adopt your protocol inside a year, the standard has won. The specification kept moving too, with the 2025-03-26 revision introducing the Streamable HTTP transport that replaced the original HTTP plus SSE design, the 2025-06-18 revision adding structured tool output and elicitation, and a further revision dated 2025-11-25. MCP did not just launch, it became the default vertical connector and then hardened.
April 2025: A2A, and a very large tent
MCP said nothing about agents talking to each other, and by early 2025 that gap was obvious. Google announced the Agent2Agent protocol on 9 April 2025 at Google Cloud Next, released under the Apache 2.0 license, to standardise the horizontal connection: discovery and delegation between agents built by different vendors on different frameworks.
What made A2A credible was not the specification alone, it was who stood behind it. The launch came with support from more than fifty technology partners, and the protocol's design centred on the Agent Card for discovery and JSON-RPC over HTTP with Server-Sent Events for transport. Rather than keep it under a single vendor, Google donated A2A to the Linux Foundation, which announced the Agent2Agent project on 23 June 2025 at Open Source Summit North America. The project was seeded with Google's transfer of the specification, SDKs, and tooling, and its founding participants read like a truce among rivals: Amazon Web Services, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow. Neutral governance is what turns a vendor protocol into an industry one, and A2A got there in under three months.
March to August 2025: ACP, and a convergence rather than a war
The interesting complication is that A2A was not the only attempt at the horizontal problem. IBM Research launched its own Agent Communication Protocol, ACP, in March 2025 to power the BeeAI platform, an open project exploring agent interoperability. ACP took a different design stance, REST-based and async-first where A2A leaned on JSON-RPC, and IBM donated both BeeAI and ACP to the Linux Foundation.
For a few months there were two credible horizontal protocols under the same foundation, which is the kind of situation that usually ends in a standards war and a decade of fragmentation. It did not. On 29 August 2025 the Linux Foundation announced that ACP was officially merging with A2A. The framing from the people involved matters here, and it is worth being precise: this was not an acquisition and not an abandonment, it was a convergence. ACP contributed its simplicity and its open-governance experience, A2A contributed a broader feature set and wider industry backing, governance was unified with ACP's Kate Blair joining the A2A Technical Steering Committee alongside the other founding members, and the BeeAI platform that had run on ACP moved to A2A. Two efforts became one, deliberately.
This is the part that changes what you build. If you were choosing a horizontal protocol in mid 2025 you genuinely had two options. After August 2025 you have one, A2A, and ACP's contributions live inside it. That is why this series names ACP for honesty and history but builds on A2A. Constructing a separate ACP layer today would mean targeting a specification that has already merged into the one you would target anyway.
Why this history is good news for a builder
Standards efforts usually produce fragmentation, and fragmentation is expensive: you hedge, you write adapters, you wait to see who wins. The agent protocol space did the opposite. It produced a clean division of labour, MCP owning the vertical axis and A2A owning the horizontal one, backed by the companies who would otherwise have shipped incompatible alternatives. The one duplicate effort on the horizontal side resolved by merging rather than fighting. For someone deciding what to build on, that is close to the best possible outcome, because the risk you normally carry, betting on the protocol that loses, has largely been retired.
The layering that falls out
Put the two survivors together and an architecture appears on its own, without anyone designing it top down. A2A sits on top, carrying delegation between agents. MCP sits underneath, carrying tool calls from an agent down to its own capabilities. A single agent is comfortably both at once: it answers A2A requests from whoever delegates to it, and it acts as an MCP client to the tools of its domain. The seam between the two layers is clean because the protocols never overlap, one is strictly agent to agent and the other is strictly agent to tools.
That two-layer stack is not our invention, it is what the ecosystem converged on, and it is exactly what we build next. From here the series stops teaching protocols in the abstract and builds the real thing: a read-only network operations centre where a supervisor speaks A2A to fabric, firewall, and cluster specialists, and each specialist speaks MCP to the live infrastructure of its domain. We build it step by step so you can reproduce it, then show what it does, then show how it is tested.
Sources: Anthropic, Introducing the Model Context Protocol (Nov 2024) and the MCP specification revisions 2024-11-05, 2025-03-26, 2025-06-18, and 2025-11-25; Google Developers Blog and the Linux Foundation press release on the A2A launch (9 April 2025) and donation (23 June 2025); LF AI and Data and IBM communications on the ACP and A2A merger (announced 29 August 2025).
Building an Agentic NOC, the full series:
- Part 1: The three protocols: MCP, A2A, and ACP
- Part 2: Build a minimal MCP server
- Part 3: Build a minimal A2A agent
- Part 4: How the protocols evolved and converged (you are here)
- Part 5: What we built, step by step
- Part 6: What it actually does
- Part 7: Testing, and earning trust
