What Is ACP? The Agent Client Protocol — LSP, but for AI Coding Agents

A while back I wrote about the layers of building with AI — chat, agent, and harness — and I've written plenty about MCP, the protocol that lets an agent reach out to tools. There's a quieter cousin to MCP that I think deserves the same attention, because it answers a question MCP doesn't: how does my editor talk to the agent in the first place?

That protocol is ACP — the Agent Client Protocol — and the cleanest way to understand it is by analogy to something every developer already relies on: the Language Server Protocol.

A quick heads-up: "ACP" is overloaded. There's also an Agent Communication Protocol (IBM Research / BeeAI) for agent-to-agent orchestration. This post is about the Agent Client Protocol — editor ↔ agent. Different protocol, same three letters.

The LSP analogy (and why it's the whole point)

Remember what life was like before LSP? Every editor had to build its own C# support, its own TypeScript support, its own Python support. N editors × M languages = a combinatorial mess, and most combinations simply didn't exist. The Language Server Protocol broke that: a language's intelligence moved into a standalone server, editors became generic clients, and suddenly any LSP-speaking editor got any LSP-backed language for free.

ACP does exactly this for coding agents. Right now we're back in the pre-LSP swamp, just with a different axis: every agent-plus-editor combination needs custom integration work, so each agent only works inside the handful of editors someone bothered to wire it into. As the protocol's own framing puts it, the goal is "to enable you to switch between multiple agents without switching your editor."

So:

• LSP decoupled language intelligence from the editor.
• ACP decouples the agent from the editor.

Same move, one layer up. That's the entire idea, and once it clicks, everything else is detail.

The three pieces

ACP describes a small, clear cast:

• The client — your code editor / IDE. It owns the UI and starts the conversation. Clients today include Zed (the reference implementation, from the team that created ACP), JetBrains IDEs, Neovim, Emacs, and VS Code.
• The agent — the AI tool that actually runs the LLM loop and decides what to do. Think Gemini CLI, Claude Code, Codex.
• MCP servers — the tools and data the agent reaches for underneath. This is where ACP and MCP meet rather than compete.

And that's the relationship worth tattooing on your brain:

MCP gives the agent tools. ACP gives the agent an editor.

	MCP	ACP
Between	agent ↔ tools	editor ↔ agent
Problem it solves	how the agent invokes tools	how the editor drives the agent
Who is the "client"	the AI application	the code editor

They stack. Your editor speaks ACP to the agent; the agent speaks MCP to its tools. One vertical line from your keystrokes down to a database query.

How it actually works

ACP is refreshingly boring under the hood, in the good way — it's the same proven machinery as LSP.

For a local agent, the editor launches it as a subprocess and they talk JSON-RPC 2.0 over stdio. No ports, no daemons — the editor spawns the agent and pipes messages in and out. (Remote agents over HTTP/WebSocket are on the roadmap but still a work in progress.)

Work is organized into sessions (a conversation with shared context) and turns (one prompt-to-response cycle). You start a session, and — here's the neat part — the same session/new call can declare which MCP servers the agent should connect to, wiring both protocols in a single handshake:

// editor -> agent : start a session and pre-wire its MCP tools
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "session/new",
  "params": {
    "cwd": "/home/joche/src/my-app",
    "mcpServers": [
      { "name": "filesystem", "command": "mcp-fs", "args": ["--root", "."] }
    ]
  }
}

Then a turn is just a prompt into that session:

// editor -> agent : a prompt turn
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "session/prompt",
  "params": {
    "sessionId": "sess_01",
    "prompt": [{ "type": "text", "text": "Add retbackoff to the HTTP client." }]
  }
}

From there the agent streams back what it's doing — its reasoning, tool calls, proposed file edits as diffs, permission requests before it touches anything, even terminal output — and the editor renders all of it in its native UI. To keep things familiar, ACP deliberately reuses MCP's JSON content representations where it can, adds a few coding-specific types (diffs being the obvious one), and defaults to Markdown for any user-readable text.

If you read my chat, agent, harness post, you'll recognize what ACP is really standardizing: it's the harness boundary, expressed as a protocol. Permission gating, file edits, terminal access, streaming progress — those are exactly the harness responsibilities, now spoken over a wire so any editor can be the harness for any agent.

Where it stands today

It's early, but moving fast, and the support pattern is the classic "native plus adapters" you'd expect from a young protocol:

• Editors: Zed (reference), JetBrains, Neovim, Emacs, VS Code.
• Agents: Gemini CLI speaks it natively (a --acp flag), while Claude Code and Codex connect through adapters. There's an ACP Registry for discovering agents.

That mix is exactly how LSP started, too — a reference implementation, a couple of native speakers, and adapters bridging the rest until the ecosystem catches up.

Why I care about it

Two reasons. First, the obvious one: freedom from lock-in. I don't want my choice of editor to dictate my choice of agent, any more than I'd accept an editor that only understood one programming language. ACP is the standard that makes "bring your own agent" real.

Second, and more interesting to me as someone who keeps writing about agent infrastructure: ACP is the missing top half of the stack. We had MCP standardizing the agent's reach downward into tools. We had no standard for the agent's connection upward into the place developers actually live — the editor. ACP fills that gap, and with both protocols in place you can finally draw one clean, vendor-neutral line: editor → (ACP) → agent → (MCP) → tools.

That's a stack I'd happily build on. If you've wired an agent into your editor over ACP — or you have opinions on where it should go next — tell me. I'm always listening on the links on the about page.