DCP vs. ACP
ACP (the IBM/BeeAI Agent Communication Protocol) is not really a separate live target to compare DCP against anymore. On 2025-08-29 the Linux Foundation announced that ACP merged into A2A, with its team winding down independent development. DCP’s relationship to ACP was always the same complementary, different-layer relationship it has with A2A — a communication protocol versus a coordination-payload vocabulary.
Current status (2026)
Section titled “Current status (2026)”As of this writing, ACP has converged into A2A. IBM Research’s ACP, originally built to power the BeeAI platform, is confirmed by the Linux Foundation AI & Data community to have joined forces with A2A as of 2025-08-29. The ACP team is contributing its technology and expertise directly to A2A rather than continuing ACP as a standalone spec, and BeeAI itself now runs on an A2A-compatible adapter. If you are evaluating protocols for a 2026 project, the substantive comparison to make is DCP vs. A2A — that page covers the live, actively governed target. This page exists mainly to close the loop for anyone still holding ACP-era documentation.
What ACP was
Section titled “What ACP was”ACP was an agent-to-agent communication protocol — a way for independently built agents to invoke each other, distinct from a vocabulary for what they’re talking about. Per IBM’s own description, it was launched by IBM Research in March 2025 to power the BeeAI platform and was REST-based rather than JSON-RPC: a lightweight, runtime-free way to call an agent, with agents packaged at build time so they could be discovered offline (useful in air-gapped or serverless settings), and it stayed framework-agnostic via Python and TypeScript SDKs. That REST style was ACP’s defining difference from A2A. In short, ACP answered “how does agent A reach and call agent B?”
What matters for this comparison, independent of transport details: nothing in ACP defined project-coordination entities like decisions, findings, or architecture impact. It was a channel for agents to exchange messages, not a shared vocabulary for what a change to a project means — which is the entire job DCP does.
Side-by-side (layer level)
Section titled “Side-by-side (layer level)”| DCP | ACP | |
|---|---|---|
| Purpose / layer | Semantic payload vocabulary for project-coordination events | REST-based agent-to-agent communication/invocation protocol (IBM Research / BeeAI origin) |
| What it models | 8 closed entity types: Project, Task, Dependency, ArchitectureImpact, Decision, ReviewRequest, Finding, Milestone | Agent invocation, messaging, and offline (build-time) discovery — not project-coordination entities |
| Current status (2026) | Active — Apache-2.0 code/schemas, CC-BY-4.0 docs, 70 passing tests as of 2026-07-03 | Merged into A2A under the Linux Foundation, announced 2025-08-29; independent development winding down |
| Trust/identity | None by design — “DCP carries no trust”; a DCP message is untrusted data | Part of the communication layer’s own concern |
| Relationship to DCP | — | Historically complementary, same as A2A: a communication layer versus a coordination-content layer |
The one line worth remembering
Section titled “The one line worth remembering”ACP was about how agents communicate; DCP is about what a project change means — and ACP has since converged into A2A. That framing held before the merger and holds after it: a transport or messaging layer and a coordination-payload vocabulary were never competing for the same job, whether the transport in question is called ACP, A2A, or something else entirely. DCP has no opinion on how agents exchange bytes — see DCP carries no trust for why that boundary is deliberate — and any protocol that moves messages between agents is a plausible carrier for a DCP event.
Where to go instead
Section titled “Where to go instead”If you arrived here evaluating ACP for a new build, redirect to DCP vs. A2A, which covers the actively maintained successor in full, including its Task lifecycle, its entity list, and exactly where a DCP event would sit inside an A2A message. If you are new to the whole family of agent-protocol acronyms, the plain-language key is agent protocol acronyms, explained. For the broader argument on why a dedicated coordination vocabulary is worth having at all — independent of which transport carries it — see why a coordination vocabulary. The full set of protocol comparisons, including CloudEvents, MCP, and webhooks, is on the comparison hub.
By InterIP Networks · Last updated 2026-07-10.
