Skip to content
Back to Blog

What Is the Agent Client Protocol (ACP)?

ACP lets any AI coding agent work in any editor. What it does, how it works, and why it matters for everyone writing code with AI.

ai-agents developer-tools protocols
What Is the Agent Client Protocol (ACP)? diagram
Click to expand

Your AI coding agent just locked you into an editor.

You picked Cursor because its AI is great. Or you stuck with VS Code because Copilot lives there. Maybe you went all-in on Windsurf. Whatever you chose, you made two decisions at once: which agent to use, and which editor to live in. Those two things shouldn’t be coupled. But right now, they are.

A new agent drops that’s better at your language or your framework? Too bad, it only works in a different editor. Your company standardizes on JetBrains? Say goodbye to that CLI agent you loved. This is the problem the Agent Client Protocol (ACP) was built to fix.

One protocol, every editor

ACP is an open standard that defines how code editors talk to AI agents. Think of it as a shared language. Instead of every agent building a custom plugin for every editor, both sides speak ACP. The agent implements it once. The editor implements it once. They just work together.

The math is simple. Without ACP, connecting 4 editors to 4 agents requires up to 16 custom integrations. Most of those don’t exist, which is why your favorite agent probably only works in one or two editors. With ACP, the same 4 editors and 4 agents need only 8 implementations total (4 + 4), and every combination works.

Zed started it. JetBrains joined. The protocol is open source under Apache license, and the list of supported editors and agents is growing fast.

How it actually works

Under the hood, ACP uses JSON-RPC (a simple message format) over stdio (the same pipe your terminal uses). No exotic transport, no cloud relay. The agent runs as a local process, and the editor talks to it through structured messages.

A session looks like this:

  • The editor starts the agent and they exchange capabilities (what the agent can do, what the editor supports)
  • The user sends a prompt through the editor’s agent panel
  • The agent works: reading files, running terminal commands, generating code changes
  • Results stream back to the editor as they happen
  • When the task is done, the session can end or wait for the next prompt
ACP session flow between editor and agent
Click to expand

The protocol defines specific operations the agent can use. It can read and write files (including files you haven’t saved yet). It can create terminal sessions, run commands, and read their output. It can show diffs before applying changes. And it can ask for permission before doing anything destructive. All of this is in the spec.

What you actually get

When you install an ACP agent in Zed or JetBrains, you’re not getting a dumbed-down version. The Claude Code ACP adapter, for example, wraps the same Claude Agent SDK that powers the CLI. You get tool calls, file operations, terminal access, diffs, permission requests, and multi-turn conversations. The brain is identical. The only thing that changes is the interface around it.

You can even log in with your existing Claude subscription. No separate API key needed.

What it can’t do (yet)

ACP handles the agentic workflow: “here’s a task, go figure it out, show me what you did.” What it doesn’t handle is inline completions. The ghost text that appears as you type, the tab-to-accept suggestions, the autocomplete. That’s a completely different interaction model (continuous, low-latency predictions based on cursor position), and ACP wasn’t designed for it.

So in Zed today, you get two separate AI systems: the editor’s native AI for inline completions, and ACP agents for the heavy-lifting agentic work. In Cursor, those are unified into one experience. That’s the trade-off of a protocol-based approach vs. a tightly-integrated one.

Why this actually matters

Two scenarios where ACP changes things:

Agent freedom of choice. Your team uses JetBrains IDEs. Tomorrow, a new agent drops that’s significantly better at Terraform or Python or security review. With ACP, any developer on the team installs it from the registry in seconds and starts using it alongside their existing agent. No migration, no IT ticket, no vendor negotiation. The best agent wins because it’s the best, not because it has an exclusive deal with your editor.

Build once, reach everyone. Say you build a custom coding agent that knows your company’s internal libraries, naming conventions, deployment patterns, and Terraform modules. Without ACP, you’d need to build a VS Code extension, a JetBrains plugin, a Neovim integration. With ACP, you implement the protocol once and your agent works in every ACP-compatible editor. When you update the agent, everyone gets the update automatically.

This second scenario is the one that compounds. Your best engineer’s knowledge, packaged as an agent, accessible to every developer on the team in real-time, inside their editor. That’s not a productivity hack. That’s compressing months of onboarding into day one.

The protocol landscape

ACP doesn’t exist in isolation. There are three complementary protocols shaping how AI agents fit into development workflows:

  • ACP (Agent Client Protocol) connects editors to agents. The “where” of agent integration.
  • MCP (Model Context Protocol) connects agents to tools and data sources. The “what” an agent can access.
  • A2A (Agent-to-Agent) connects agents to other agents. The “who” agents can collaborate with.

They’re layers, not competitors. An ACP agent running in your editor can use MCP to access your database, and A2A to coordinate with another agent. Each protocol handles one clean boundary.

Honest trade-offs

What’s working:

  • Open standard, Apache licensed, community-driven
  • Growing editor support (Zed native, JetBrains, Neovim, Emacs)
  • Growing agent support (Claude Code, Codex CLI, Gemini CLI, Goose, Kiro)
  • Familiar tech (JSON-RPC, stdio) with no exotic dependencies

What’s not there yet:

  • No inline completions or ghost text (by design, but still a gap)
  • Remote agent support is still being developed
  • VS Code doesn’t support ACP (Copilot has its own ecosystem)
  • Young protocol, still evolving, breaking changes possible

The LSP moment

Nobody gets excited about JSON-RPC. But everyone benefits from language intelligence working in every editor. LSP (Language Server Protocol) made that happen for code intelligence. ACP is making the same bet for AI agents.

The day you can pick your editor and your agent independently, without compromise, is the day both get better.

Common questions

Is ACP the same as MCP?

No. ACP connects editors to agents. MCP connects agents to tools and data sources. They're complementary layers that work together.

What is the difference between ACP and LSP?

LSP standardized code intelligence (completions, diagnostics). ACP standardizes AI agent workflows (multi-step tasks, file edits). Same architectural idea, different domain.

Does ACP require a cloud connection?

No. ACP uses JSON-RPC over stdio. The agent runs locally on your machine. No cloud relay, no external server.

Can I build my own ACP agent?

Yes. The protocol is open source under Apache license. Implement the spec once, and your agent works in every compatible editor.