Your Coding Agent Should Not Own Your Editor

Sat, 18 Jul 2026 10:00:00 -0500

Every coding agent wants to become the place where you work. It starts life as a command-line tool. Then it grows a chat interface, a diff viewer, a permission system, a terminal, a model picker, and eventually an editor integration. Meanwhile, every editor has to build a separate adapter for every agent its users might want. Ten editors, ten agents, and suddenly you’re staring at a hundred bespoke pairings nobody wants to maintain.

We’ve seen before, it’s called a shared boundary.

That’s what the Agent Client Protocol (ACP) is. An agent implements ACP once. An editor implements ACP once. Now you can run the agent inside the editor without either product having to swallow the other whole. It sounds like plumbing because it is plumbing. Plumbing is also the thing that makes ecosystems possible.

ACP in One Sentence

ACP is an open protocol for communication between an AI coding agent and the application presenting that agent to you.

Let’s be specific:

The client is usually the editor or IDE. It owns the interface, your local environment, and the interaction with you.
The agent is the coding-agent process. It owns the model loop, the conversation state, and the tool-use logic.

That word agent carries a lot of baggage, so it’s worth nailing down. In everyday AI talk it can mean the raw model, a harness like Claude Code or Opencode that wraps a model, or a subagent that a larger agent spawns to handle a subtask. ACP means the narrow one: the coding-agent process, the harness itself. You’re almost never talking to the model directly in this picture. You talk to the harness, and it drives the model on the other side. An ACP agent also isn’t a subagent. Subagents are an internal detail of whatever the harness does behind its own loop, invisible to the protocol. ACP draws its boundary one level up, between the editor and the whole coding-agent process, not between an agent and its helpers.

In the common local setup, the editor launches the agent as a subprocess and they trade newline-delimited JSON-RPC messages over stdin and stdout.

flowchart LR
    U[Developer] <--> C[ACP client<br/>Editor or IDE]
    C <-->|JSON-RPC over stdio| A[ACP agent<br/>Coding-agent process]
    A <--> M[Model provider]
    A <--> T[MCP servers and tools]
    C <--> W[Workspace, buffers, terminals]

The whole design is in that picture: the editor and the agent stay separate programs. The agent doesn’t rebuild a serious code-review UI. The editor doesn’t reimplement the reasoning loop. Each side keeps the part it already understands.

The LSP Analogy Only Gets You Halfway

The usual pitch borrows from the Language Server Protocol, and the economics do rhyme. Before LSP, editors built language support one language at a time. After, one language server worked across many editors. ACP applies the same trick to agents: agents stop maintaining an integration per editor, editors stop maintaining one per agent, and you can swap agents without changing where you review code.

But don’t take the analogy too literally. A language server answers bounded questions. Where is this symbol defined? What completions apply here? A coding agent is a long-running, stateful thing. It streams text, announces plans, calls tools, asks permission, edits files, starts processes, and sometimes needs to be interrupted mid-turn. So ACP has to standardize more than request-and-answer. It standardizes enough of the experience of supervising an agent for the client to render it well.

What Happens in a Session

A connection opens with initialize, where both sides negotiate a version and advertise capabilities. This is deliberately not all-or-nothing. Both programs are expected to cope with optional features being absent.

Then the client opens a conversation with session/new and gets a session ID back. One connection can carry several independent sessions. The client sends your message with session/prompt, and while the agent works it streams session/update notifications: assistant chunks, thoughts and progress, a plan and edits to that plan, tool calls and their status, mode changes. If a tool call needs a sign-off, the agent sends session/request_permission and the editor shows you the choice. Cancel a turn and the client fires session/cancel.

That bidirectional flow is the whole difference between ACP and a thin chat API. The agent isn’t just handing back text. It’s exposing a structured account of what it’s doing so the editor can turn that into something you can watch and steer.

The Editor Stops Being a Chat Window

An agent in a plain terminal sees the files on disk. An editor knows more than disk. It has unsaved buffers, syntax highlighting, diagnostics, symbol navigation, a diff UI, and a model of what you’re reviewing right now. ACP’s filesystem methods let the agent ask the client to read or write text including editor state that hasn’t hit disk yet. Its terminal methods let the agent request a command, get a handle, read bounded output, wait for exit, or kill it, while the editor keeps ownership of the process and shows output in its own native terminal.

That split is a lot healthier than every agent inventing its own janky approximation of an IDE. The agent brings intent and execution. The editor brings visibility and control.

ACP and MCP Are Not the Same Thing

People mix these up because both use JSON-RPC and both show up in agent tooling. They sit on different boundaries.

MCP answers: what can the agent use? Databases, issue trackers, browsers, internal APIs.
ACP answers: where and how do you work with the agent?

They’re complementary. During session/new, the ACP client can hand MCP server config to the agent, which then connects to those servers itself. Tools arrive through MCP. Agent work arrives through ACP. Clean.

The Interface Is Becoming Its Own Layer

Strip away the JSON-RPC and the method names and the idea is simple: the coding agent and the interface you use to supervise it are different products. Improve the editor without waiting on every agent vendor. Stay in the environment where your code, terminal, and review workflow already live.

We should want coding agents to get better. We should also want the things we use to control them to get better. Those two will move faster if they’re allowed to move apart. That’s the actual promise of ACP. Not one universal agent, but a boundary that stops any single agent from owning the entire way we work.

Sources & References

Agent Client Protocol introduction and architecture — overview, subprocess model, sessions, permissions, and the relationship to LSP and MCP.
ACP v1 overview, session setup, and prompt turn — methods, streaming updates, cancellation, and MCP handoff.
ACP filesystem and terminal methods — unsaved editor state, tracked writes, and process control.
The ACP Registry is Live — distribution for compatible agents and clients.

I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @logan@llbbl.blog.

Acp on LLBBL Blog