Agent Client Protocol: The Editor to Agent Standard Behind Devin Desktop

The most consequential thing about Agent Client Protocol is boring by design. It is a way for a code editor to talk to a coding agent without either side knowing the specifics of the other. That sounds like plumbing, and it is, but plumbing is what turned a scatter of incompatible language tooling into the Language Server Protocol ecosystem every editor now shares. ACP is aiming for the same outcome one layer up, at the agent, and the fact that Cognition shipped Devin Desktop against it is a signal the industry is starting to agree.

Aspect	Agent Client Protocol
First published	Zed Industries, August 2025
Transport	JSON-RPC 2.0 over stdio, line delimited
Topology	editor launches agent as a subprocess
Who owns the UX	the editor: file tree, terminal, diffs, prompts
What it standardizes	editor to agent messages
Ships against the spec	Zed, JetBrains, Google
Plugs in via adapter	Claude Code, Codex
Notable adopter	Devin Desktop (formerly Windsurf), June 2, 2026

The old coupling was the problem

Before a standard existed, every editor that wanted an agent had to build a bespoke integration for each agent, and every agent that wanted to reach developers had to build a bespoke integration for each editor. That is an N times M problem, and it produced exactly what you would expect: a handful of tightly coupled products where the agent and the editor shipped as one thing, and no easy way to swap either half. If you liked one editor's ergonomics but another vendor's agent, you were stuck. The tooling comparisons that dominate this space, including the per worker model choices in multi agent automation, were partly comparisons of which bundle you were willing to marry.

ACP collapses the N times M problem into N plus M. An editor implements the client side of the protocol once and can drive any conformant agent. An agent implements the server side once and runs inside any conformant editor. This is precisely the move LSP made for language intelligence, and the history there is instructive: once the interface was standard, the market for language servers and the market for editors could evolve independently, and both got better faster.

How ACP actually works

The mechanics are deliberately simple. ACP is JSON-RPC 2.0 exchanged over stdio, which means line delimited JSON messages passed on stdin and stdout. The editor spawns the agent as a local subprocess and the two exchange the three standard JSON-RPC message types: requests, responses, and notifications. There is no network service to stand up, no port to manage, no auth handshake to a remote endpoint for the base case. The agent runs as a child process of the editor, and the editor talks to it the way it would talk to a language server.

The important design decision is who stays in charge. In ACP the editor owns the user experience: the file tree, the integrated terminal, the diff views, the prompts, and crucially the permission mediation. The agent proposes actions and the editor decides how to surface them, how to ask the user for approval, and how to apply them to the workspace. That keeps the trust boundary where it belongs. The agent is a subprocess making structured requests, not a black box with unmediated access to your machine, and the editor can enforce policy on every file write and every command before it runs.

ACP is not MCP, and the difference matters

The most common confusion is between ACP and the Model Context Protocol, and the cleanest way to hold them apart is by the question each answers. MCP answers "what tools and data can the agent reach," giving an agent access to databases, APIs, file systems, and browser automation. ACP answers "where does the agent live in the developer's editor," giving the agent access to the editor's file tree, terminal, diff views, and user prompts.

They sit at different layers and they compose. ACP connects the editor to the agent; MCP connects that agent to its tools. A fully wired setup uses both: the editor drives the agent over ACP, and the agent reaches out to its tools over MCP. Treating them as competitors is a category error, like asking whether HTTP competes with SQL. One is how the front of the stack talks to the agent, the other is how the agent talks to the back of the stack. A team designing an agentic coding workflow should expect to speak both protocols, each doing the job it was scoped for.

Why the Devin Desktop move is a signal

Cognition retiring the Windsurf brand and relaunching as Devin Desktop with ACP support is more than a rename. It is a vendor that owned a tightly coupled editor and agent choosing to open the seam between them. When Zed, JetBrains, and Google ship against the spec directly, and Claude Code and Codex plug in through adapters, the protocol has crossed the threshold from one company's idea to a shared interface with multiple independent implementations on both sides. That is the point at which a standard starts to matter, because the cost of betting on it drops.

For teams choosing tools, the practical consequence is optionality. The decision of which editor to standardize on and which agent to run stops being a single locked in bundle and becomes two decisions you can make and revise independently. If a better agent ships next quarter, a conformant editor can adopt it without a migration. The long horizon repository work that stresses these tools, the kind measured in the long horizon repo migration comparison, becomes easier to reassign to whichever agent is currently strongest, because the editor integration is no longer the thing holding you in place.

What to watch before you commit

A young protocol carries young protocol risk. The base case of a local subprocess over stdio is clean, but the interesting questions are at the edges: how permission prompts are modeled, how streaming and cancellation behave under long running agent turns, how the protocol handles agents that need to run remotely rather than as a local child process, and how consistently the adapter based integrations match the native ones. Standards converge through exactly these details, and it is worth reading the spec and testing your specific agent and editor pair rather than assuming conformance means identical behavior. The earlier landscape read on Cursor and Codex tooling is a reminder that surface compatibility and real world ergonomics are not the same measurement.

When this applies to your stack

ACP matters to you if you are building an agentic coding tool, integrating agents into an internal developer platform, or making a multi year bet on which editor and agent your team standardizes on. The protocol lets you decouple those choices, keep the editor in control of permissions and workspace mediation, and swap agents as the frontier moves without rebuilding the integration each time. Pair it with MCP for the tool layer, keep the trust boundary in the editor, and treat the adapter based integrations as good but worth verifying against the native ones.

Designing an agentic engineering workflow that speaks ACP to the editor and MCP to the tools, keeps a real permission boundary on every file write and command, and stays swappable as the agent market churns is the AI integration and agent engineering work Contra Collective takes on when a team wants leverage over its tooling rather than lock in from it. The protocol is simple on purpose. The value is in the optionality it buys and the discipline of keeping the editor, not the agent, in charge of your machine.

FAQ

What is Agent Client Protocol in one sentence? It is an open standard, first published by Zed Industries in August 2025, that defines how a code editor talks to a coding agent over JSON-RPC 2.0 on stdio, so any conformant editor can drive any conformant agent.

How is ACP different from MCP? MCP connects an agent to its tools and data, answering what the agent can reach. ACP connects the editor to the agent, answering where the agent lives in the developer's workflow. They operate at different layers and are meant to be used together.

Do I need a server or network setup to use ACP? Not for the base case. The editor launches the agent as a local subprocess and exchanges line delimited JSON messages over stdin and stdout, so there is no port or remote endpoint to manage for local integration.

Which editors and agents support ACP? Zed, JetBrains, and Google ship against the spec directly, while Claude Code and Codex plug in through adapters. Devin Desktop, the relaunch of Windsurf from Cognition on June 2, 2026, is a notable adopter.

Why does a standard like this matter for my team? It decouples the choice of editor from the choice of agent, turning a locked in bundle into two independent and revisable decisions. As the agent frontier moves, a conformant editor can adopt a stronger agent without a full integration rebuild.

Protocol details, adopters, and release facts reflect published specifications and vendor announcements as of August 2026; a young standard evolves quickly, so read the current spec and test your specific editor and agent pairing before committing a production workflow.