Agent Client Protocol (ACP)
BetAn open standard for decoupling AI coding agents from editors, so any agent works with any IDE
Metrics
What is it
Agent Client Protocol (ACP) is an open standard for communication between code editors/IDEs and AI coding agents, inspired directly by the Language Server Protocol (LSP). Originated by Zed Industries and now jointly maintained with JetBrains, it defines a JSON-RPC-based interface over stdio (local agents) or HTTP/WebSocket (remote agents) so that any ACP-compatible agent works with any ACP-compatible editor — without custom integrations on either side. The protocol reuses MCP types where possible and adds coding-specific primitives like diffs, terminal access, file system operations, and slash commands. SDKs are available in TypeScript, Python, Kotlin, and Rust.
My Opinion
ACP shifts the competitive axis in AI tooling from “which LLM?” to “which agent system?” — and that’s genuinely good news for developers.
The LSP Pattern, Applied to Agents
The cleanest way to understand ACP is to look at how LSP changed the editor landscape. Before LSP, every language server had to be written separately for every editor: a TypeScript server for VS Code, a TypeScript server for Vim, a TypeScript server for Emacs. The combinatorial overhead was enormous. LSP broke that matrix — you write the server once, and any editor that speaks the protocol can use it. ACP does exactly the same thing for coding agents. Today, if you want to use GitHub Copilot in IntelliJ and also in VS Code, you’re relying on Copilot having implemented both integrations. With ACP, a company can standardise on a Copilot licence and developers can consume it from whichever IDE they prefer — IntelliJ, VS Code, Zed, Neovim — without waiting for the agent vendor to build each integration. That’s not a small quality-of-life improvement; it’s a structural change in who controls the developer tooling stack.
The Political Strategy Behind It
This is also a story about coalition building against a dominant incumbent. VS Code controls a huge share of the developer market, and both Zed and JetBrains are fighting for relevance against it. The Gemini CLI team, building an agent that needs distribution, had the same problem from the opposite direction. By rallying around ACP, these parties created a common standard that benefits them collectively far more than it benefits Microsoft. It’s a textbook example of the “open up the layer below your competitor’s moat” strategy — the same move that made Linux and Android successful. JetBrains joined as co-maintainer in early 2026, with Sergey Ignatov becoming Lead Maintainer alongside Zed’s Ben Brandt. The growing list of agents that have shipped ACP support — Gemini CLI, Cline, OpenHands, OpenCode, Codex CLI, and more — shows the coalition has real momentum.
The Obsidian Moment
What sold me personally wasn’t the IDEs — it was plugging it into Obsidian. ACP’s client list already includes an Obsidian plugin, and connecting an agent to my knowledge base through a standardised protocol rather than a proprietary integration felt like exactly the right direction. It’s early, and the integration is rough around the edges, but the concept is right: your notes, your agent, your editor — none of them should be locked to each other. That composability is the long-term promise of ACP.
If you search for “ACP protocol”, you’ll find two completely different things using the same acronym. IBM’s BeeAI team coined “Agent Communication Protocol” (also ACP) as a REST-based standard for agent-to-agent communication across organizations — think manufacturing agent talking to logistics agent. When Google launched A2A (Agent2Agent) with 50+ enterprise partners in April 2025, it targeted exactly the same space with more momentum and a broader coalition. IBM’s ACP lost ground, and IBM eventually agreed to deprecate it and fold its work into A2A under the Linux Foundation. IBM’s own docs now carry a deprecation notice pointing users toward A2A migration paths.
Zed’s Agent Client Protocol came after all of this and solves an entirely different problem: editor-to-agent communication, not agent-to-agent. They’re complementary layers of the same stack — A2A handles agents talking to each other, ACP handles an IDE talking to an agent. The fact that MCP-over-ACP is already in the RFD pipeline shows the ecosystem is actively figuring out how all three protocols fit together.
The Caveats
The ecosystem is still early. GitHub Copilot’s ACP support landed in public preview only in early 2026. JetBrains Junie is listed as “coming soon.” VS Code has no native support yet — you need a community extension. Remote agent support is explicitly a work in progress. And the protocol is evolving fast enough that early integrations may need updating. The fundamentals are right, but don’t expect a frictionless setup experience just yet.
Conclusion
ACP is the right protocol at the right time, built by the right coalition. It solves a real structural problem — the N×M integration matrix between agents and editors — using the same architecture that made LSP a success. The competitive dynamics driving adoption are healthy: multiple independent parties have strong incentives to make it work, and no single vendor controls it. Adopt it if you’re building agents or editor integrations; the sooner you’re protocol-native, the less migration work you’ll face as adoption accelerates.
