Reading about AI agents, I kept seeing the acronym ACP show up next to MCP. I had a rough sense of MCP, having reviewed it hands-on more than once (Korean only), but I only knew ACP by name and had no idea what it did. So I asked Claude first, then took that answer and opened the official docs one by one. The first answer was mostly right, but some things had already changed in the meantime.
Same acronym, two different protocols — Agent Client Protocol and Agent Communication Protocol
The first answer split in two right away. There really are two protocols that use the acronym “ACP.”
One is the Agent Client Protocol. It’s a standard for how a code editor and an AI coding agent talk to each other, first released by the team behind the Zed editor. The other is the Agent Communication Protocol, released in March 2025 by IBM Research’s BeeAI project. That one was a standard for how agents pass work to each other.
There’s one more easily confused name here: A2A, announced by Google in April 2025. A2A isn’t another name for ACP. It stands for the Agent2Agent Protocol and is a separately built protocol. It did, however, share a goal with IBM’s Agent Communication Protocol. Both were standards tackling “how should agents communicate and collaborate with each other,” each in its own way.
| Name | Who made it | What it connects | Now |
|---|---|---|---|
| Agent Client Protocol (ACP) | Zed | Editor ↔ agent | Actively used; what “ACP” usually means today |
| Agent Communication Protocol (ACP) | IBM | Agent ↔ agent | Development ended when it joined A2A |
| Agent2Agent Protocol (A2A) | Google → Linux Foundation | Agent ↔ agent | Absorbed IBM’s effort and became the standard for this space |
So even under the same “ACP” name, IBM’s was solving the same problem as A2A and merged into it, while Zed’s solves a different problem that has nothing to do with A2A from the start. When ACP is mentioned alongside MCP, it’s almost always Zed’s Agent Client Protocol.
The Agent Client Protocol is the LSP between editors and agents
The official Agent Client Protocol docs compare it to LSP (the Language Server Protocol). Before LSP, every editor had to build its own autocomplete and error display for each language. Once LSP standardized how the two talk, one language server could work in any editor.
AI coding agents had the same problem. Plugging agents like Claude Code, Gemini CLI, or Codex into editors like VS Code, JetBrains, or Zed meant building a separate integration for every agent-editor pair. Five agents and five editors means twenty-five integrations. ACP defines a single way for the two to talk, so any agent that supports ACP runs in any editor that supports ACP.
The mechanics are simple. The editor launches the agent as a child process and exchanges JSON-RPC messages over standard input and output. The editor sends context like the user’s message and open files, and the agent sends back answers, file edits (diffs), requests to run terminal commands, and permission checks like “may I edit this file?” The editor displays all of it in its own UI. The message format reuses MCP’s JSON representations wherever possible and defines new types only for editor-specific things like code edits. Connecting to remote agents over HTTP or WebSocket is, per the official docs, still a work in progress.
It started on August 27, 2025, when Zed released the protocol while opening its editor to external agents, with Google’s Gemini CLI as the first integration.
MCP, ACP, and A2A don’t compete — they sit at different layers
At first I wondered why we’d need another protocol when MCP already exists. Laid out side by side, the three turned out to connect entirely different things.
| Protocol | What it connects | Analogy |
|---|---|---|
| MCP | Agent ↔ tools and data (files, databases, external APIs) | A standard for giving an agent hands and feet |
| ACP (Agent Client Protocol) | User interface (editor) ↔ agent | A standard for plugging an agent into any workspace |
| A2A (Agent2Agent, Google) | Agent ↔ other agents | A standard for agents to hand work to each other |
So all three can be in use at once. Launch a coding agent in Zed over ACP, and that agent uses MCP to plug in tools like GitHub or a memory server, and can hand work off to another agent over A2A when needed. If MCP standardized the agent’s “lower side,” ACP standardizes its “upper side”: the screen where people meet the agent.
The first answer was as of its training data — the ACP agent registry and IBM’s ACP joining A2A
Claude’s first explanation was right up to this point. It did add, on its own, that “this is as of my training data and may have changed since,” and when I opened the official docs, a few things had indeed already changed.
IBM’s ACP wasn’t “in the middle of merging”; it had already merged. The first answer said it “has been moving toward merging with A2A,” but the LF AI & Data announcement shows that joining A2A under the Linux Foundation was already settled on August 29, 2025. According to the announcement, when A2A “came on the scene a month later,” the IBM team “immediately saw alignment in how our teams approached the challenge of enabling agents to communicate,” and the two joined forces to “build a single, more powerful standard for how AI agents communicate and collaborate.” The designs differed. IBM’s side emphasized simplicity, usable with plain HTTP requests (REST) and no SDK required, while A2A centered on JSON-RPC messages and an agent description document (the Agent Card). Still, there was little reason to grow two standards with overlapping goals separately. IBM wound down its own development, and Kate Blair of IBM, who led ACP, joined A2A’s Technical Steering Committee. That’s why “ACP” today effectively means only the Agent Client Protocol.
A registry for finding and installing agents appeared. In January 2026, JetBrains and Zed together opened the ACP Agent Registry. You browse the list inside the editor, click install, and the agent is connected. According to JetBrains’ help docs, agents not in the registry can be added manually through a config file, and it works without a JetBrains AI subscription. It isn’t supported in WSL, though.
Support has grown quite broad. By the official lists, there are 41 agents and close to 100 clients (editors and apps) supporting ACP. Agents like Gemini CLI, GitHub Copilot (public preview), Cursor, Cline, and OpenCode support ACP natively, while the Claude agent and OpenAI’s Codex CLI connect through adapters. On the editor side, Zed and JetBrains support it directly, while VS Code connects through extensions rather than a built-in feature. Editors like Neovim, Emacs, and Sublime Text, and even mobile apps, are on the list.
What changes in the ACP v2 draft — moving beyond conversation turns
On July 20, 2026, the ACP v2 draft came out. The major changes:
- It moves beyond a structure that only acts when the user speaks. v1 centered on conversation turns, one agent response per user message. In v2, the agent can work in the background and send progress updates at any time.
- File edits become structured. Instead of sending “text before and text after the change,” edits distinguish add, delete, modify, move, and copy, and can handle binary files.
- Permission requests must include a title and description. The change lets editors show users more clearly what the agent is about to do.
v1 isn’t being dropped. The announcement says “v1-only peers will remain common for some time” and recommends that implementers support both versions side by side.
How far has A2A come — spec 1.0 and over 150 organizations
A2A, which absorbed IBM’s ACP, has also moved a lot in the meantime. Based on the announcement the Linux Foundation released on April 9, 2026, A2A’s first anniversary:
- The first stable spec, 1.0, is out. It includes features like signing the Agent Card so its authenticity can be checked.
- Over 150 organizations support it. The GitHub repository has passed 22,000 stars.
- It has landed in major clouds. Microsoft’s Azure AI Foundry and Copilot Studio and AWS’s Amazon Bedrock AgentCore Runtime support it, and it has started seeing production use in real enterprise services.
- Official SDKs exist in five languages: Python, JavaScript, Java, Go, and .NET.
- Next on the list are an interoperability spec, registry consolidation, expanded testing and tooling, and security and deployment best practices. On the payments side, AP2 (the Agent Payments Protocol), an extension of A2A, has come out separately with more than 60 supporting organizations.
Looking briefly at A2A’s structure per the official spec 1.0: each agent publishes an Agent Card listing what it can do and how to reach it, and other agents read it and hand over work as “tasks.” A task moves through states like submitted, working, and completed, failed, or canceled. Messages can be exchanged over JSON-RPC, gRPC, or REST. The REST approach IBM’s side championed is now one of the options A2A supports.
Tools I use were already on the list — Hermes Agent and Obsidian ACP plugins
Skimming the lists, I spotted two familiar names.
One is
Hermes Agent,
which I run as an always-on agent. A single hermes acp command starts it in
ACP server mode, and it can be connected from VS Code (via the ACP Client
extension), Zed, and JetBrains. According to the docs, connecting this way
keeps the settings, memory, skills, and tools Hermes already had; only the
channel for the conversation moves to the editor. Approval requests for
things like editing files or running commands get a separate “Allow for
session” tier, and waiting for approval times out after 300 seconds by
default. I’d only ever used Hermes through Telegram or its dashboard, so a
way to call the same agent from inside an editor had already been open all
along.
The other is Obsidian. The client list had four Obsidian plugins (Agent Client, Agent Console, Copilot for Obsidian, and Obsidian Harness), plugins that bring external agents into Obsidian over ACP. As someone building an Obsidian plugin myself, it puts two approaches side by side, “build the agent inside Obsidian” versus “plug an existing agent in over ACP,” which makes them worth a closer look.
Lingering thoughts
What stuck with me more than ACP itself was the checking process. The AI’s first explanation was good enough to get the structure. Distinguishing the two protocols and pointing out that they sit at a different layer from MCP matched the docs exactly. But the merger it described as “moving toward” had finished more than a year earlier, and it knew nothing about the v2 draft, the registry, or the fact that Hermes, which I use, already supported it. The faster a standard moves, the more the AI’s explanation should serve only as a map, with dated facts checked directly in the official docs.