Agent Client Protocol (ACP)
ACP decouples coding agents from the editor they are driven from. That separation is the practical reason agents can be moved off laptops and into centralized environments, where existing network policy, egress rules, and audit logging already apply.
What the Agent Client Protocol Actually Is
One wire format between any editor and any coding agent
The Agent Client Protocol standardizes communication between code editors and coding agents. In its own words, it covers "interactive programs for viewing and editing source code" on one side and "programs that use generative AI to autonomously modify code" on the other. It was created by Zed and released in August 2025 under the Apache 2.0 license, and is now maintained as an open standard with contributions from other editor and agent vendors.
Mechanically it is unglamorous, which is the point. ACP is a JSON-RPC 2.0 protocol with two message types, methods and notifications. The agent typically runs as a subprocess of the client, and the two exchange JSON-RPC messages over the subprocess's standard input and output. There is no daemon to operate, no port to expose, and no broker in the middle. The current stable protocol version is 1, negotiated through a protocolVersion field during initialization.
Transport
JSON-RPC 2.0 over the agent subprocess's stdin and stdout. No network listener is required for the editor-to-agent hop, which keeps the attack surface small and makes the connection trivially easy to run inside a container.
License and Governance
Apache 2.0, developed in the open at agentclientprotocol/agent-client-protocol. Unlike MCP, ACP has not been donated to a foundation, so governance still sits with its maintainers and contributors.
Scope
Sessions, prompt turns, streamed progress updates, and permission requests. ACP deliberately does not define how the agent talks to tools, models, or data sources. That is a different layer.
ACP and MCP Are Different Axes, Not Competitors
The single most common misreading of both protocols
ACP and the Model Context Protocol are frequently discussed as if one might replace the other. They connect different things. MCP is the agent-to-tool axis: it is how an agent reaches a database, a ticketing system, or an internal API. ACP is the editor-to-agent axis: it is how a human's editing environment drives the agent and renders what it is doing. A single session usually uses both at once, and an ACP session/new request can itself carry the MCP servers the agent should connect to.
| Dimension | ACP | MCP |
|---|---|---|
| Connects | Editor to agent | Agent to tools and data |
| Typical deployment | Agent as a child process of the editor | Local subprocess or remote HTTP service |
| Who benefits from adoption | Editor vendors and agent vendors avoid an N-by-M integration matrix | Tool owners publish once instead of per-agent |
| Governance | Maintained by its creators and contributors, Apache 2.0 | Donated to the Agentic AI Foundation under the Linux Foundation |
| Platform team's concern | Where the agent process runs, and what it can reach from there | Which tools are exposed, with which credentials, under what policy |
A useful analogy, with its limits
ACP is often compared to the Language Server Protocol, and the comparison holds for the part that matters: one protocol replaces a per-editor plugin for every vendor. It breaks down on state. A language server answers bounded, mostly stateless queries about a file. An agent runs a long, expensive, side-effecting turn that edits files, executes commands, and needs a human to approve some of those actions midway. That is why ACP has explicit session and permission machinery that LSP never needed.
How an ACP Session Works
Initialization, session setup, then prompt turns
The documented flow has three phases. The client sends initialize, and optionally authenticate, to negotiate the protocol version and capabilities. It then creates a session with session/new or resumes one with session/load. From there each turn begins with session/prompt, during which the agent streams session/update notifications for message chunks, tool calls, and plan changes. Either side can interrupt with session/cancel, and the turn ends when the agent returns a stop reason.
// Illustrative exchange using the documented ACP method names.
// Fields are abbreviated; see the schema for the full shapes.
// Client (editor) -> Agent: open a session in a workspace directory
{"jsonrpc":"2.0","id":1,"method":"session/new",
"params":{"cwd":"/workspace/payments-api","mcpServers":[]}}
// Agent -> Client
{"jsonrpc":"2.0","id":1,"result":{"sessionId":"sess_01"}}
// Client -> Agent: the user's prompt
{"jsonrpc":"2.0","id":2,"method":"session/prompt",
"params":{"sessionId":"sess_01",
"prompt":[{"type":"text","text":"Add a /healthz endpoint."}]}}
// Agent -> Client: streamed progress (a notification, so no id)
{"jsonrpc":"2.0","method":"session/update",
"params":{"sessionId":"sess_01",
"update":{"sessionUpdate":"agent_message_chunk",
"content":{"type":"text","text":"Reading the router..."}}}}
// Agent -> Client: ask before writing to disk
{"jsonrpc":"2.0","id":3,"method":"session/request_permission",
"params":{"sessionId":"sess_01","toolCall":{"title":"Edit src/router.ts"}}}
// Client -> Agent: the editor's answer, after asking the human
{"jsonrpc":"2.0","id":3,
"result":{"outcome":{"outcome":"selected","optionId":"allow_once"}}}
// Agent -> Client: turn complete
{"jsonrpc":"2.0","id":2,"result":{"stopReason":"end_turn"}}The detail worth dwelling on is session/request_permission. Approval is not a feature of the agent's own user interface; it is a protocol message the client must answer. That means the decision point is owned by whichever ACP client you deploy, and it is therefore a place where an organization can insert its own policy rather than inheriting whatever prompt an agent vendor happened to design.
Why Decoupling Makes Agents Portable
The infrastructure argument, which is the reason this protocol appears on this site
Before a standard existed, an agent was effectively welded to the editor it shipped inside. Moving that agent somewhere else meant waiting for the vendor to build a second integration. The practical consequence was that agents ran wherever the editor ran, which for most organizations meant a developer laptop: outside the VPC, outside the egress controls, and outside whatever logging the platform team had built.
ACP changes the shape of that problem. Because the agent is just a process speaking JSON-RPC on stdin and stdout, it can run anywhere a process can run, including inside a Cloud Development Environment workspace, while the human drives it from an editor elsewhere. Nothing about the protocol assumes the two are on the same machine. Once the agent process sits inside the workspace, the controls that already govern that workspace apply to it automatically, with no agent-specific tooling to build.
Controls you stop having to reinvent
- Egress rules already applied to the workspace also bound the agent
- Source code never leaves the environment for a laptop checkout
- Credentials stay in the workspace's secret store, not in a local config file
- Existing workspace audit logging captures what the agent did
- Resource limits and teardown are the same ones you already run
What it does not solve
- ACP says nothing about what the agent may reach once it is running
- It defines no policy language, no allow list, and no central admin surface
- Prompt injection through repository or tool content is unaffected
- Model routing and data residency remain the agent vendor's concern
- Portability is a capability, not a control; you still have to configure the environment
Treat ACP as a placement decision rather than a security feature. It gives you the freedom to choose where the agent process lives, and choosing an isolated workspace over a laptop is what actually buys the control. Pair it with sandboxed workspaces and considered network segmentation, because the protocol itself will not stop an agent from doing something you did not want.
Adoption and the ACP Registry
Solving distribution after solving integration
A protocol solves the integration problem but not the distribution problem. Even with ACP, an agent still had to be packaged as an extension for each editor, or configured by hand, which reintroduced the per-editor work the standard was meant to eliminate. The ACP Registry went live on January 28, 2026 to close that gap, with JetBrains pushing forward the registry specification. An agent is registered once and becomes available across compatible clients, so users get current versions without waiting on individual editor review cycles.
Agents in the registry
The registry announcement names Claude Code, Codex CLI, GitHub Copilot CLI, OpenCode, and Gemini CLI among the listed agents. The broader ACP ecosystem page also lists agents including Devin, Cline, OpenHands, and Cursor.
Clients supporting ACP
The ACP overview lists editors including Zed, JetBrains IDEs, Visual Studio Code, Emacs, Neovim, and Obsidian. Vendor lists move quickly, so confirm current support directly with the tool before planning around it.
Read a registry listing as a starting point, not an assurance
A registry entry means an agent speaks the protocol. It does not mean the agent implements every optional capability, that its behavior matches another listed agent, or that it has been reviewed for your environment. The same caution applies to registries in the MCP ecosystem. If an agent will run inside your infrastructure with access to real code, evaluate it on its own merits and govern which entries your clients are allowed to install.
Honest Limitations
Where a standard interface costs you something
Lowest common denominator
A shared protocol expresses what most agents can do. Vendor-specific features that do not map onto ACP's message types tend to be unavailable, degraded, or reachable only through an escape hatch. Teams that depend on a distinctive feature of one agent may find the native integration still gives them more.
Uneven implementations
Capability negotiation exists precisely because implementations differ. Two ACP agents in the same editor can present noticeably different experiences depending on which optional capabilities each supports. Portability is real but it is not uniformity.
A young standard
Protocol version 1 is stable, but the surrounding ecosystem is not yet old enough to have settled conventions, and governance still sits with the maintainers rather than a neutral foundation. That is a reasonable risk to take, but it should be a decision rather than an assumption.
Related Reading
The rest of the agent infrastructure stack
MCP Servers
The agent-to-tool axis: gateways, registries, and self-hosting.
AGENTS.md Explained
How repositories tell any coding agent how to build and test them.
IDE Integration
Connecting local editors to remote development environments.
AI Coding Assistants
The tool landscape and what the published evidence supports.
AI Agent Security
Threat models for agents with real credentials and real write access.
Sandbox Environments
Isolation models for code you did not write yourself.
Agent Orchestration
Running many agents in parallel without losing control of them.
Agentic AI
Why autonomy turns the environment into a security boundary.
Sources
Every citation used across this site, with publishers and dates.