ACP was a real project, was folded into A2A in mid-2025, and every "ACP vs A2A" post older than August 2025 is stale — this short essay closes that door.
ACP (Agent Communication Protocol, IBM/AGNTCY) was contributed to the Linux Foundation in July 2025 and merged into A2A the same month. Every "should we use ACP or A2A" post older than that is stale. Search results have not caught up. This essay is short by design: what ACP was, why the merge made sense, and where its ideas ended up inside A2A v1.0.
What ACP was.
ACP — the Agent Communication Protocol — was an open specification incubated by IBM Research and shipped through the AGNTCY working group in 2024 and early 2025. Its distinguishing property was that it was REST-native from the start: an ACP agent was a set of HTTP endpoints, requests and responses were plain JSON, streaming used chunked transfer encoding rather than JSON-RPC over SSE, and the shape of an interaction looked closer to "call this API" than to "invoke this method." The design was self-consciously the anti-A2A of the moment — where the pre-1.0 A2A draft had leaned heavily on JSON-RPC and long-polling semantics, ACP argued that agent-to-agent traffic would ride on the same shape as agent-to-tool traffic and the shape should be plain HTTP.
The message model was intentionally simple: a Run resource, a sequence of Message objects on the run, and human-readable structured output — Markdown was a first-class output type, on the argument that Markdown was already how models talked and pretending otherwise was overhead. Discovery worked through what ACP called an Agent Manifest — a JSON document served under the agent's own URL that listed available runs and their expected inputs, close in spirit to what would become A2A's Agent Card. The identity and auth story was thin (bearer tokens, no formal profile); the transport story was thin (HTTP only, no gRPC binding); and the appeal was that a competent web engineer could stand up an ACP agent in an afternoon without touching JSON-RPC.
The merger.
In July 2025 the Linux Foundation announced it would host both A2A (contributed by Google) and ACP (contributed by IBM/AGNTCY) under the same umbrella, and within the same announcement window the two working groups declared they would merge — A2A would be the surviving name, ACP would sunset as an independent project, and ACP's contributors would join the combined working group. The stated reason, from the LF press release and confirmed on both projects' issue trackers, was that the interoperability the two protocols were supposed to enable was actively harmed by having two protocols in the market claiming the same ground, and that whichever one won the adoption race would leave a real body of production code stranded on the loser. Merging into one was cheaper than either side winning outright.
Two conditions made the merge tractable. First, the pre-1.0 A2A draft was still in flux — the state machine, the Message model, and the transport bindings were all open questions, which meant merging ACP's contributions in was a design conversation rather than a rewrite. Second, ACP's REST-native argument was popular enough with implementers that the A2A working group could not simply ignore it, and the honest way to resolve the disagreement was to bring the ACP contributors into the room. The result of that conversation is what shipped as A2A v1.0 in April 2026, roughly nine months after the merger.
Which ACP ideas survived.
Three ACP contributions made it into A2A v1.0 in recognisable form. The REST binding is the most direct — A2A v1.0's HTTP binding, distinct from the JSON-RPC and gRPC bindings, is essentially the ACP wire shape with the A2A object model on top; a developer who had shipped an ACP agent can port to the A2A REST binding in a day. The Agent Manifest folded into what is now the Agent Card — the same well-known-URL discovery pattern, extended to cover the negotiation surface A2A needed. And the Markdown-as-first-class-output argument shows up in A2A v1.0's default output modes, where text/markdown is one of the standard content types the base Agent Card advertises and the specification treats as a peer of application/json rather than a fallback.
What did not survive was the philosophical position that A2A's JSON-RPC binding should go away. v1.0 keeps JSON-RPC as the default binding, offers REST as an equal alternative, and lets peers choose either at deployment time. The interop problem essay's framing applies here — the multi-binding shape is more work to implement but avoids re-fighting the same argument every three years when a new team wants to standardise on the transport their stack already uses. If your web reading turns up an "ACP vs A2A" tutorial and the date is before August 2025, close the tab. If it is after, check whether the author noticed the merge — the ones that did are useful; the ones that did not are still describing a fork that no longer exists.