Integrating an AI coding agent into every editor through custom plugins creates duplicated work: each editor must understand each agent’s interface. The Agent Client Protocol (ACP) solves this interoperability problem by defining a common communication contract between coding agents and the applications that host them, such as IDEs and code editors.
The two sides of ACP
ACP separates responsibilities between two participants:
- Client: The editor or IDE. It owns the user interface, workspace, user interaction, and decisions about access to local resources.
- Agent: The AI-powered coding process. It interprets prompts, plans work, invokes tools, and produces code changes.
An agent can implement ACP once and connect to multiple compatible clients. An editor can support multiple agents without building a separate integration for each one. This resembles the Language Server Protocol (LSP), which standardised editor-to-language-server communication, but ACP focuses on agent workflows rather than language features.
Communication model
ACP uses JSON-RPC 2.0. A method is a request that expects a result or error; a notification is a one-way event with no response. In a common local setup, the client launches the agent as a subprocess and communicates over standard input and output (stdio).
A typical session follows this sequence:
- Initialize: Client and agent exchange protocol version and capability information.
- Authenticate: Authentication happens if the agent requires it.
- Create or resume: The client starts a session or continues an existing one.
- Prompt: The client sends the user’s request using
session/prompt. - Update: The agent sends
session/updatenotifications with message content, progress, tool activity, or state changes. - Complete or cancel: The agent reports the turn result, or the client sends
session/cancelto interrupt work.
This model lets an editor display progress while the agent is working instead of waiting for one large response.
Capabilities and permissions
An agent may need to run a command or access a resource. ACP keeps the client in the control path: the agent can request permission, and the client decides how to obtain user approval. During initialization, both sides advertise capabilities so optional features are used only when supported.
Compatibility should not mean unrestricted machine access. Clients still need clear permission prompts and safeguards around filesystem and terminal operations.
ACP vs. MCP
The protocols address different boundaries:
- ACP connects an agent to its interactive host, usually an editor.
- MCP (Model Context Protocol) connects an AI application or agent to external tools and context providers, such as databases, APIs, or filesystems.
They can work together: an ACP-compatible coding agent can use MCP servers for tools while ACP carries conversation and progress updates between the agent and editor.
When to use ACP
ACP is useful when building a coding agent for multiple editors, or an editor that lets users choose among compatible agents. It reduces one-off integration code and makes the agent easier to replace. It does not define how an agent reasons or guarantee equivalent results; it standardises the interaction boundary.
The key idea: ACP makes the editor-agent connection a protocol instead of a vendor-specific plugin, while leaving the client responsible for user experience and permissions.
References: ACP protocol overview · ACP specification · JetBrains: ACP