Agent Communication Protocol (ACP) Explained: What It Is and Why It Matters
Practical look at AI agent orchestration protocols in H2 2026 – and why the term ACP now means something different than it did a year ago
Look up “Agent Communication Protocol” today and the definition still depends on which page loaded first. One source describes an IBM Research standard. Another describes something that no longer exists independently. A third means an entirely different protocol that has nothing to do with agent-to-agent coordination at all. The confusion is a leftover from 2025, but the situation on the ground in mid-2026 is actually more settled than the search results suggest – and more settled than most explainers dated even a few months ago.
That matters for a practical reason: teams building what’s now commonly called AI agent orchestration – multiple agents passing context and delegating work in sequence – keep hitting the same coordination problem. One agent calls another through code wired up in an afternoon, holds together for the first few runs, then fails silently when an agent times out mid-task or hands the next one a malformed output. ACP is routinely proposed as the fix, based on how the term was used a year ago. Here’s where the protocol landscape actually stands now, and what to standardize on instead.
Table of contents
Where things actually stand as of mid-2026
The short version: the multi-protocol confusion of 2025 has consolidated into a two-layer stack under a single governance umbrella. Anthropic donated MCP to the newly formed Agentic AI Foundation (AAIF), a Linux Foundation-directed fund co-founded with Block and OpenAI, on December 9, 2025. Google’s Agent2Agent (A2A) protocol reached its 1.0 stable specification in January 2026 and, by its one-year mark that April, had more than 150 supporting organizations and production deployments across financial services, insurance, and supply chain.
The practical result for anyone architecting a pipeline right now splits cleanly into two layers: MCP handles AI agent integration – how an agent reaches your tools and data – while A2A handles AI agent orchestration – how agents coordinate with each other. Both sit under neutral foundation governance rather than a single vendor’s roadmap. That’s the current default, not a prediction – and it’s a meaningfully different, calmer picture than the “protocol wars” framing that was still accurate in early 2025.
How ACP fits into that picture (briefly, because it mostly doesn’t anymore)
IBM Research launched ACP in March 2025 to power BeeAI, an open-source platform for orchestrating agents across frameworks, with structured message types for negotiating a handoff instead of passing free text back and forth. Five months later, on August 29, 2025, LF AI & Data announced that ACP was merging into A2A. The ACP team stopped independent development and began contributing its technology directly to A2A instead.
This isn’t a contested claim between competing sources – IBM’s own documentation on ACP carries a formal notice that the protocol has merged with A2A and directs anyone still building on it to migrate. Almost a year on, if a vendor pitches ACP integration as a current architectural choice rather than a piece of protocol history, that’s worth a direct question about which protocol they actually mean.
A separate, unrelated project adds to the confusion: AGNTCY, open-sourced by Cisco’s Outshift incubator in March 2025 and donated to the Linux Foundation that July, provides discovery, identity, messaging, and observability infrastructure for multi-agent systems. It’s explicitly positioned as complementary to A2A and MCP, not a replacement or a rebrand of ACP – worth knowing about if a project needs cross-vendor agent identity or observability, but a different layer of the stack entirely.
There’s a third, entirely unrelated protocol sharing the same three letters. Agent Client Protocol, created by Zed Industries and open-sourced in August 2025, standardizes how code editors talk to coding agents like Claude Code or Gemini CLI – the same relationship Language Server Protocol standardized for language tooling a decade earlier. It solves an editor-to-agent problem, not an agent-to-agent one. If a vendor mentions ACP in a multi-agent context, confirm which of the three protocols they mean before assuming any of them are related.
The coordination problem these protocols are trying to solve
Without a shared protocol, coordination between agents defaults to whatever the engineering team wires up first: a webhook here, a shared database row there, retry logic added after the first production incident. It works until agent two doesn’t respond in time, or agent three receives output in a shape agent one never sends during testing.
What a coordination protocol actually standardizes is narrower than the marketing around it suggests: a consistent message format for handoffs, a way to signal that a step completed (or didn’t), and a defined path for propagating failure so it doesn’t disappear silently three steps downstream. Some versions add structured negotiation on top – an agent proposing a plan, another accepting, rejecting, or countering it – which matters more in pipelines where agents genuinely need to negotiate scope, not just pass a result along.
None of this is exotic engineering. It’s the same discipline distributed systems have needed for handoffs between services for years, applied to a context where the thing on the other end of the handoff is a model call instead of a deterministic function.
MCP, A2A, and the ACP name: what each layer actually standardizes
These acronyms get used almost interchangeably in vendor material, which is part of why teams over-adopt or under-adopt them. They standardize different layers of the same stack – and one row in this table is a historical reference, not a current option:
| Protocol | What It Standardizes | Use It When | Status As Of Mid-2026 |
|---|---|---|---|
| MCP Model Context Protocol | How an agent connects to tools, data sources, and APIs | Any agent needs to read or act on your systems, regardless of how many agents are involved | Governed by the Agentic AI Foundation (AAIF) since December 2025; broadest ecosystem of the three |
| A2A Agent2Agent Protocol | How agents from different vendors or teams discover each other and delegate tasks | Agents built on different platforms or by different organizations need to hand off work as peers | Reached v1.0 in January 2026; Linux Foundation-governed, 150+ backing organizations, absorbed IBM's ACP |
| ACP Agent Communication Protocol, IBM/BeeAILegacy | Originally: structured peer messaging and negotiation between agents | Historical reference only – don't design new architecture around it | Merged into A2A; IBM's own documentation now redirects adopters to A2A |
| AGNTCY | Agent discovery, identity, messaging, and observability infrastructure | You need cross-vendor agent identity or observability, on top of MCP and A2A, not instead of them | Linux Foundation-governed since July 2025, complementary to A2A and MCP |
The practical default for most teams building now: MCP for every agent’s connection to your data and tools, and A2A once agents built by different vendors or teams need to coordinate as peers. This isn’t a hedge – it’s the combination the market has actually converged on as of mid-2026. Treat any current mention of “ACP” as a signal to ask which protocol is actually meant – IBM’s original standard, A2A itself, AGNTCY, or the unrelated editor protocol from Zed.
Where the coordination discipline shows up in production, not just in the protocol name
Consider a three-agent engineering workflow: one agent handling code review, one generating documentation, one maintaining test coverage. It only stays useful if the documentation agent knows the review agent finished, and the test agent knows what changed and why. Without a defined contract for that handoff, one agent’s malformed output breaks the next step silently, and the failure surfaces as “the agent produced something wrong” instead of a traceable cause.
Consider the other end of the spectrum: a single agent built quickly for a narrow, well-defined task – a booking form, a lookup, a routing decision. No multi-agent negotiation required. It’s a useful reminder that not every agentic build needs coordination protocol overhead – the architecture should match the workflow’s actual complexity, not the ambition of the pitch.
Consider a billing workflow that sits closer to the first case: multiple steps where one agent’s output becomes another’s input, checkpoints where a human needs to approve before money moves, and a failure mode (a billing action taken on bad data) that’s expensive enough to justify defined handoff contracts rather than ad hoc wiring.
What makes scenarios like these workable isn’t a specific protocol brand. It’s typed handoffs, explicit failure handling, and human checkpoints at the steps where a mistake would actually cost something – the same discipline A2A, MCP, and well-designed custom coordination all try to enforce.
When you don’t need a coordination protocol at all
A single agent, or a short deterministic sequence where the same team owns both ends of every handoff, usually doesn’t need a formal protocol layer. A documented internal message schema and a retry policy cover most of the risk. Adopting MCP or A2A tooling before the pipeline has more than one or two agents adds integration surface without solving a problem that exists yet.
The signal that it’s time to look at a coordination protocol is a workflow where three or more agents pass context in sequence, where failures need to be traceable to a specific step, or where more than one team owns different agents in the same pipeline. Below that threshold, the protocol conversation is premature.
Where this fits in a broader build
Choosing a coordination protocol only matters once the underlying question is answered: does this use case actually need multiple agents, and if so, how many. That’s an architecture decision, not a protocol decision, and it’s usually cheaper to answer it on real data before committing engineering time to any specific standard.
If that’s the open question, it’s the one our Agentic AI Implementation work starts with – an architecture recommendation on your actual workflow before any protocol gets chosen. For pipelines that also need to connect agents to your existing systems and data, our MCP Server Development work covers that layer separately.
FAQ
What is AI agent orchestration, and how does ACP fit in?
AI agent orchestration is the layer that coordinates multiple agents working on different parts of a workflow – passing context, triggering each other, and handling failures without a human stitching the steps together manually. ACP was an early attempt at standardizing that layer. Its capabilities now live inside A2A, which is why current orchestration architecture is built on A2A rather than on ACP directly.
Is ACP the same as MCP?
No. MCP (Model Context Protocol) standardizes how an agent connects to tools and data sources. ACP, in its original IBM form, addressed peer-to-peer messaging between agents. They sat at different layers and were meant to be used together, not as alternatives.
Does ACP still exist as a separate protocol today?
No. Its original IBM Research implementation merged into the Agent2Agent (A2A) protocol on August 29, 2025. IBM’s own documentation now directs anyone building on ACP to migrate to A2A instead.
What’s the difference between Agent Communication Protocol and Agent Client Protocol?
They share an abbreviation and nothing else. Agent Client Protocol, from Zed Industries, standardizes communication between code editors and coding agents. Agent Communication Protocol, IBM’s now-merged standard, addressed coordination between autonomous agents in a pipeline.
What is AGNTCY, and is it the same as ACP?
No. AGNTCY is a separate, Cisco-originated infrastructure project covering agent discovery, identity, messaging, and observability. It’s designed to complement A2A and MCP, not replace or rebrand either.
Do I need a coordination protocol for a two-agent pipeline?
Usually not. A documented message contract between the two agents, with explicit failure handling, covers most two-agent workflows without adding a protocol dependency.
What should a team actually standardize on today?
MCP for tool and data access, now governed by the Agentic AI Foundation, since almost every agent needs it regardless of pipeline size. A2A, at v1.0 since January 2026, once agents from different vendors or teams need to coordinate as peers. Treat any ACP-branded pitch as a cue to ask which of the (at least three) protocols with that name is actually meant – the useful one, IBM’s original standard, is the one that no longer exists independently.
Share this article:
