ACP: The Agent Protocol That Merged Into A2A, and Why That's Good News

Most essays about protocols are about winners. This one is about a protocol that folded, and I'm writing it anyway, because the way ACP ended tells you more about how to bet on agent standards than any launch announcement ever will.

This is the third essay in a series on agent communication. The first covered MCP, the agent-to-tool layer, the second covered A2A, the agent-to-agent layer, and the field guide compares all three. ACP was A2A's direct competitor. Same problem, different philosophy, and for a while in 2025 you genuinely had to pick.

What ACP was

The Agent Communication Protocol came out of IBM's BeeAI work, and its pitch was refreshingly plain: agent-to-agent communication should just be REST. No special SDK required. Any agent exposes ordinary HTTP endpoints, and anything that can speak HTTP, which is everything, can call it. You could drive an ACP agent with curl. For a lot of engineers that was the whole seduction. Nothing new to learn, just endpoints.

Discovery worked through an Agent Manifest, a description of the agent's capabilities that peers could read to find the right collaborator, much like A2A's Agent Card. Communication was flexible about time: call an agent synchronously when you needed a fast answer, or go async and stream results over server-sent events when the task ran long. Async was the default posture, which was the honest choice, because real agent work is rarely quick.

Put next to A2A, the differences were real but not philosophical chasms. A2A leaned on JSON-RPC and a richer task-lifecycle model. ACP leaned on plain REST conventions and a lower barrier to entry. Both had discovery documents, both handled sync and streaming, both wanted to be the lingua franca between agents built on different frameworks. Two standards, one job.

The merge, and why it was the right call

In 2025 the story resolved cleanly: Google contributed A2A to the Linux Foundation, IBM brought ACP into the same effort, and ACP as a separate track wound down. The ecosystem consolidated on A2A, with ACP's REST-first instincts absorbed into the surviving standard rather than thrown away.

I want to be clear that this outcome was good, and not just for the winner. A fragmented agent ecosystem, where every framework speaks its own dialect, recreates exactly the integration hell that MCP had just eliminated at the tool layer. The entire value of an interoperability protocol is that there's one of it. The moment serious vendors lined up behind A2A under neutral governance, continuing ACP would have served IBM's ego at the ecosystem's expense. They folded it instead. That's maturity you don't often see in standards fights, which historically run for a decade out of pure stubbornness.

What this teaches you about betting on standards

If you built on ACP, you weren't wrong. That's the lesson people miss. The teams that adopted it early got their agents talking over clean HTTP interfaces with explicit manifests, and when the merge came, migrating to A2A was a port, not a rewrite, because the concepts mapped almost one to one. The teams that got burned were the ones who used the standards war as an excuse to build a proprietary agent-messaging layer, and who now own a dialect nobody else will ever speak.

So here's the rule I give boards and CTOs when a young standard is still contested. Don't bet on which spec wins. Bet on the shape both specs share. When every contender has capability discovery, task delegation, and streamed results, those concepts are the actual standard, and the winning wire format is an implementation detail you can swap. Keep your agents behind thin adapters, and consolidation becomes a chore instead of a crisis. It's the same instinct as any good architecture bet: read the thesis, not just the code.

The consolidation also simplified the pitch for everyone. The stack now has two layers with clear jobs: MCP for an agent's tools, A2A for an agent's peers. One protocol war, settled early, with the losing side's best ideas kept. If only every infrastructure decision resolved this well.

The bottom line

ACP mattered because it pushed the simplest possible answer, agents as plain REST services, hard enough that the surviving standard had to absorb it. Its afterlife inside A2A is a better legacy than limping along as a fragment. And the episode is a compact case study in how to adopt standards during consolidation: commit to the concepts and stay loose on the wire format, with a thin adapter between your agents and whatever the industry finally agrees on. The full comparison shows how the settled map looks now.

Wrestling with a build-on-emerging-standard decision of your own? I've helped a lot of companies place those bets without getting locked in. Let's talk →