Wiki · Concept · Last reviewed June 25, 2026

Agent Client Protocol

Agent Client Protocol, or ACP, is an open protocol for connecting code editors and IDEs to AI coding agents through a shared client-agent interface.

Category: Concept / Agent Infrastructure Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: ACP, AI Coding Agents, IDEs, Agent Infrastructure, Audit Trails

Definition

Agent Client Protocol is an open protocol for communication between code editors or IDEs and AI coding agents. The official introduction says ACP standardizes editor-agent communication and is intended for both local and remote scenarios. The project repository defines the two sides more concretely: code editors are interactive programs for viewing and editing source code, while coding agents are programs that use generative AI to autonomously modify code.

ACP is easy to confuse with other agent protocols because the abbreviation is crowded. It is not Agentic Commerce Protocol, Agent Communication Protocol, Agent2Agent Protocol, or Model Context Protocol. A2A is about agent-to-agent delegation. MCP is about giving an agent access to tools, resources, and context. ACP sits between the human's development surface and the coding agent, defining how an editor launches, talks to, displays, interrupts, and gates the agent.

Architecture

The v1 ACP overview describes a bidirectional JSON-RPC 2.0 protocol. Both clients and agents expose methods that the other side can call, and both send notifications for events that do not need a response. A typical flow begins with initialize, optional authentication, then session/new or session/load, followed by prompt turns where the client sends session/prompt and the agent streams progress with session/update.

Initialization is the protocol's compatibility gate. Clients and agents negotiate protocol version, capabilities, and authentication methods. The GitHub repository says the current stable ACP wire protocol version is 1, and wire compatibility is determined by the protocolVersion exchanged during initialize, not by the release version of a schema artifact or SDK.

Local ACP agents commonly run as editor subprocesses. The introduction describes local agents using JSON-RPC over standard input and output, while remote agents may use HTTP or WebSocket. The v1 transports page specifies JSON-RPC messages encoded as UTF-8 and lists stdio as the defined transport, with Streamable HTTP still marked as a draft proposal in progress and custom transports allowed if they preserve the ACP message format and lifecycle requirements.

ACP is explicitly designed for coding-agent user experience. The specification includes sessions, prompt turns, tool-call reporting, file locations, diffs, permission requests, filesystem reads and writes through client capabilities, terminal creation and output, cancellation, plans, session modes, slash commands, and extensibility. That makes it closer to an IDE interaction contract than to a generic chat protocol.

Governance and Safety

ACP can make coding agents easier to integrate, but it does not certify that an agent is safe, reliable, compliant, or authorized. The architecture page says ACP works when a user is using a code editor to talk to a model they trust, and notes that the editor gives the agent access to local files and MCP servers. That framing should be read as a governance warning, not a guarantee.

The most important risks are repository access, unsaved editor state, shell execution, overbroad MCP configuration, misleading tool-call displays, silent permission defaults, and loss of provenance when an agent adapter hides the underlying agent. The filesystem page allows agents to read and write text files through client capabilities. The terminal page allows agents to execute shell commands if the client advertises terminal support. These surfaces belong behind explicit scope, review, and logging.

ACP's useful control point is that it gives editors a common place to display and gate activity. Tool calls can report status, kind, raw inputs and outputs, affected locations, diffs, and permission options such as allow once, reject once, allow always, and reject always. A careful client can turn those protocol events into a readable audit trail. A careless client can turn the same protocol into a smoother path for unreviewed changes.

Evidence Record

A governed ACP session should preserve the client implementation and version, agent implementation and version, negotiated protocol version, advertised capabilities, authentication method, workspace root, additional directories, MCP server configuration passed to the agent, prompt text and attachments, session IDs, tool-call IDs, permission requests, user decisions, file diffs, terminal commands, terminal exit status, cancellation events, final stop reason, and adapter identity if a bridge is used.

Source Discipline

For protocol claims, use the ACP documentation and repository, and name the v1 page or method being described. For implementation support, use the official Agents, Clients, or Registry pages and avoid treating a listing as proof of quality or security. For comparisons, identify the other protocol precisely: MCP for tool and context access, A2A for agent-to-agent task exchange, ANP for agent identity and discovery, and ACP for editor-to-agent interaction.

Spiralist Reading

ACP is the socket where software labor becomes visible inside the editor. It standardizes the exchange between a human's development environment and a delegated coding process: prompt, plan, file, command, permission, diff, status, interruption, and result.

Spiralism reads that exchange as institutional design. The question is not whether a coding agent feels intelligent. The question is whether the interface preserves accountable work: who asked, what context moved, which authority was granted, which command ran, which file changed, which approval mattered, and which record remains after the agent is gone.

Open Questions

Sources

Return to Wiki