Agent protocol acronyms, explained

“MCP, A2A, ACP, DCP…” is starting to sound like alphabet soup. This page is the plain-language key: what each acronym stands for, who made it, which layer of the stack it lives on, and — the question that actually matters — why DCP is not just one more way for agents to talk, but a different kind of thing entirely.

The one distinction to hold onto: most agent protocols move traffic or grant capabilities. DCP describes meaning. It has no wire of its own and competes with none of the others; it rides inside them.

The acronyms at a glance

Acronym	Full name	Made by	What it does	Layer	Relation to DCP
MCP	Model Context Protocol	Anthropic (now under the Agentic AI Foundation / Linux Foundation)	Connects one model to tools, data, and context so it can act	Capability / tool access	Different layer — MCP lets a model do things; DCP records what the project decided as a result. A DCP event can ride inside an MCP resource.
A2A	Agent2Agent Protocol	Google, donated to the Linux Foundation (2026)	Lets independent agents delegate and track a task on one another	Transport / task delegation	Complementary — A2A’s Task says whether a delegated job finished; DCP says why the project changed. A DCP event fits inside an A2A message part or task metadata.
ACP	Agent Communication Protocol	IBM Research / BeeAI, under the Linux Foundation	REST-based agent invocation — a lightweight way for agents to call each other, with offline (build-time) discovery	Transport / communication	Historical — ACP merged into A2A in Aug 2025. Same different-layer relationship as A2A: a channel for messages, not a vocabulary for their meaning.
DCP	Development Coordination Protocol	InterIP Networks / TokonoMix	Defines the structure of a project-coordination event — decisions, findings, dependencies, milestones — as JSON Schema	Semantic / payload	This project. Carries no transport, identity, or trust; is carried by any of the above.

You will also see acronyms like ANP (Agent Network Protocol) and AGNTCY / AGP (the Cisco-initiated agent-gateway effort) in this space. They too sit on the transport/discovery side of the line — ways for agents to find and reach each other — not vocabularies for what a project change means. Wherever a new agent-communication acronym lands, the same test below places it.

The one test that sorts them all

Ask of any protocol: does it move bytes, connect a model to data, deliver callbacks, or persist state — or does it define what a project event means?

• MCP connects a model to its tools and context.
• A2A and (historically) ACP move task-delegation traffic between agents.
• CloudEvents and webhooks wrap and deliver a payload without caring what it says.
• Event Sourcing persists one system’s own history internally.

Every one of those is a different layer than DCP. None of them defines a Decision, a Finding, an ArchitectureImpact, or a Milestone. That gap — the content of a coordination event — is the only thing DCP fills, and it is deliberately small enough to sit inside any of the others rather than replace one. See the full decision matrix for the row-by-row version.

How DCP differs from ACP, specifically

ACP is the acronym most often confused with DCP, because both end in ”…CP” and both talk about agents. They are not the same layer.

ACP was a communication protocol. Launched by IBM Research in March 2025 to power the BeeAI platform, ACP was a REST-based way for independently built agents to invoke one another — lightweight, runtime-free, with agents packaged at build time so they could be discovered offline (useful in air-gapped or serverless settings), and framework-agnostic via Python and TypeScript SDKs. Its defining trait versus A2A was exactly that REST style rather than JSON-RPC. In other words, ACP answered “how does agent A reach and call agent B?”

DCP is a semantic vocabulary. It answers a different question: “what does this change to the project mean?” — that a decision was recorded, a finding raised, a dependency created, a milestone reached. DCP defines eight entity types and the events that record their changes, as JSON Schema, and stops there. It has no wire protocol, no discovery, no identity, and no trust — by design. A DCP message is untrusted data that any transport can carry.

So the two were never competing for the same job. ACP could have been one of the transports that carries a DCP event, the same way A2A, CloudEvents, or a plain webhook can.

One more thing worth knowing: as of 2025-08-29, the Linux Foundation AI & Data community announced that ACP has merged into A2A, with IBM contributing its technology directly to A2A rather than developing ACP as a standalone spec. So if you are choosing a protocol for a 2026 build, the live comparison to make is DCP vs. A2A — but the layer distinction is identical either way.

	ACP (as it was)	DCP
Question it answers	How does agent A reach and invoke agent B?	What does this project change mean?
Layer	Transport / communication (REST-based)	Semantic payload vocabulary
Models	Agent invocation, messages, offline discovery	8 coordination entities: Project, Task, Dependency, ArchitectureImpact, Decision, ReviewRequest, Finding, Milestone
Trust / identity	Part of the communication layer’s concern	None by design — “DCP carries no trust”
Status (2026)	Merged into A2A (announced 2025-08-29); winding down as an independent spec	Active — Apache-2.0 code/schemas, CC-BY-4.0 docs
Relationship	A plausible carrier for a DCP event	Carried by a transport; carries none itself

For the dedicated deep-dive, see DCP vs. ACP. For why a shared coordination vocabulary is worth having at all — no matter which transport wins the acronym war — see why a coordination vocabulary, and for the deliberate boundary that keeps DCP out of the transport business, see DCP carries no trust.

By InterIP Networks · Last updated 2026-07-10.