TL;DR
MCP connects an agent to its tools, A2A connects agents to each other, and ACP connects a coding agent to the editor a developer works in. Three layers of one stack, not three competing options. Most published comparisons get one thing wrong that changes the answer: the ACP they describe, IBM's Agent Communication Protocol, stopped active development in August 2025 and folded into A2A. The ACP still shipping in 2026 is a different protocol that happens to share the acronym, Zed's Agent Client Protocol, and it covers a boundary neither MCP nor A2A touches.
This post separates the two ACPs, puts each live protocol on the layer it actually occupies, and gives the short answer on which ones you need.
Picking protocols for a multi-agent build? We design the orchestration boundary first and let it decide the protocol, since the wrong starting question adds a standard you will have to rip out later.
Key Takeaways
- MCP is agent to tools, A2A is agent to agent, ACP is agent to editor. Each covers a boundary the other two do not.
- Two protocols share the ACP acronym. IBM's Agent Communication Protocol merged into A2A in August 2025. Zed's Agent Client Protocol launched the same month and now lists 11 editors and more than 50 agents.
- Any comparison presenting ACP as a lighter alternative to A2A for smaller teams is describing the merged IBM spec as a live choice. Check the publication date before acting on protocol advice.
- All three speak JSON-RPC 2.0, and ACP deliberately reuses MCP's JSON shapes where it can. Implementing one gets you most of the plumbing for the others.
- Most teams need MCP and nothing else. A2A earns its place when a second independently built agent enters the system. ACP matters only if you ship a coding agent that should run inside editors you do not own.
Two different protocols are called ACP
IBM Research launched the Agent Communication Protocol in March 2025 to power BeeAI, its open-source agent platform, and donated both to the Linux Foundation the same month. In August 2025, Kate Blair of IBM Research and Todd Segal of Google jointly announced the merge into A2A. The ACP team wound down active development to contribute directly to the A2A spec, and BeeAI itself now runs on A2A with an A2AServer adapter to bring existing agents across.
Zed's Agent Client Protocol launched on 27 August 2025, alongside Google's Gemini CLI. It is Apache-licensed and solves an unrelated problem: without a standard, every agent-and-editor pair needs its own bespoke integration, the same fragmentation LSP fixed for language tooling. Claude Code support landed on 3 September 2025, JetBrains formalized a collaboration on 6 October 2025, and in January 2026 JetBrains shipped an ACP Agent Registry inside IDEs on version 2025.3 and later. Zed now lists 11 editors, including VS Code, Emacs, Neovim and Obsidian, and more than 50 agents.
The practical consequence is worth stating plainly. If an article published this year tells you ACP is a lightweight HTTP-native option for teams that find A2A too heavy, it is describing the IBM protocol as a live choice roughly a year after its team stopped developing it. That framing is easy to find in current comparisons, which is a good reason to check the date on any protocol advice before you build against it.
What each protocol actually connects
MCP points down. An MCP host, an AI application like Claude Code or VS Code, creates one client per server, and each server exposes tools, resources and prompts. The agent discovers what is available at connection time instead of a developer wiring it in advance. We covered what MCP adds over a plain API and how to build a server past hello world separately.
A2A points across. Work is a Task with a lifecycle, submitted through working to completed, failed or canceled, handed from an A2A Client to a Remote Agent that publishes an Agent Card describing its skills and accepted auth schemes. Neither side needs to know how the other is built. The full A2A and MCP comparison goes deeper on the handoff itself.
ACP points up, at the human. An editor spawns the agent as a child process and speaks JSON-RPC over stdio, the same mechanism LSP uses, which is why ACP runs anywhere LSP already runs. The editor calls initialize to negotiate capabilities, opens a session with session/new, then sends each turn through session/prompt while the agent streams progress until it returns a stop reason. The design goal is that the developer never leaves their editor and the agent comes to them. That session/new call is also where the two protocols meet, since it carries the agent's MCP server list, which the ACP and MCP comparison covers in detail.
Side by side
| MCP | A2A | ACP (Agent Client Protocol) | |
|---|---|---|---|
| Connects | An agent to tools and data | An agent to another independent agent | A coding agent to a code editor |
| Direction | Down, inside one agent's reach | Across, to a peer it does not control | Up, to the human's editor |
| Created by | Anthropic | Zed | |
| Wire format | JSON-RPC 2.0 over stdio or Streamable HTTP | JSON-RPC 2.0 over HTTP, plus SSE for streaming | JSON-RPC 2.0 over stdio, HTTP or WebSocket when remote |
| Unit of work | A tool call | A Task with a lifecycle | A prompt turn inside a session |
| You need it when | Your agent calls anything external | A second, independently built agent enters | You ship an agent that should run in editors you do not own |
Which ones do you actually need?
For most teams the honest answer is MCP and nothing else. One agent calling its own tools is fully an MCP problem no matter how many tools it has, and the 2026-07-28 spec now covers long-running work through a Tasks extension that returns a durable handle, which removes one of the older reasons people reached past it.
A2A becomes real when a second, genuinely independent agent enters the picture, one you do not control the internals of, often built by another team or running on a vendor's infrastructure. That is a boundary question, not a step-count question. Plenty of multi-step agentic workflows never cross it.
ACP is narrower than either, and the narrowness is the point. It matters if you are shipping a coding agent and want it usable inside editors you do not own, or if you are building editor tooling and want to accept agents you did not write. If you are building a support bot, a research agent or an internal workflow, ACP is not part of your stack. The three protocols only look like a decision when a comparison table puts them in the same column.
Frequently asked questions
Is ACP dead?
One of them is. IBM's Agent Communication Protocol wound down active development in August 2025 and merged into A2A under the Linux Foundation, so no new work targets it. Zed's Agent Client Protocol, which shares the acronym, is actively developed and shipping across JetBrains IDEs, VS Code, Zed and others.
Which ACP do people mean when they say ACP?
It depends on the context and the date. Writing about multi-agent orchestration, enterprise agent platforms or BeeAI almost always means IBM's protocol, which is now historical. Writing about coding agents, editors or IDE integrations means Zed's. Comparisons written since late 2025 frequently conflate the two.
What is the difference between ACP and A2A?
For IBM's ACP the question is now historical: its assets and design went into A2A, so A2A is the answer to what ACP was trying to solve. For Zed's ACP the two do not overlap at all. ACP connects an agent to the editor a person is sitting in, A2A connects an agent to another agent, and a single coding agent can reasonably speak both.
Can one agent use all three protocols at once?
Yes, and a coding agent running inside an editor is the clean example. It speaks ACP upward to the editor, MCP downward to its tools, and A2A across if it delegates to a separate agent. Because all three ride JSON-RPC 2.0 and ACP reuses MCP's JSON representations where it can, the combined implementation cost is lower than three separate standards suggests.
Is MCP enough on its own?
For most systems, yes. MCP covers everything inside one agent's boundary, which is where the majority of production agent work still happens. Add A2A when you cross into an agent you did not build, and add ACP when your agent needs to live inside somebody else's editor. Adding either before you have that problem is complexity with nothing on the other end of it.