Agent Client Protocol (ACP): The LSP for AI Coding Agents Explained

2025-09-10 in Artificial Intelligence tagged LLM / AI Agent / Agent Client Protocol (ACP) / Model Context Protocol (MCP) by Marc Nuri | Last updated: 2026-04-23

Versión en Español

Introduction

The Agent Client Protocol (ACP) is an open JSON-RPC standard for connecting code editors to AI coding agents. The analogy people reach for is Language Server Protocol (LSP), and it is a useful one: ACP aims to break the old 1:1 coupling where each editor needed a bespoke integration for each agent.

Zed introduced ACP in August 2025, and JetBrains joined shortly after. That quickly turned ACP from a Zed-specific integration mechanism into a broader interoperability layer for agentic coding workflows.

Which Agent Client Protocol?

Over the last two years, three different protocols have used the ACP acronym, and search results still mix them together:

Agent Client Protocol: the editor-to-agent protocol this post covers.
Agent Communication Protocol: an agent-to-agent interoperability protocol associated with IBM Research / BeeAI.
Agentic Commerce Protocol: a commerce protocol from OpenAI and Stripe for AI-driven checkout flows.

In this post, ACP always means Agent Client Protocol.

What is the Agent Client Protocol?

The Agent Client Protocol is an open JSON-RPC standard that decouples code editors from the AI coding agents they drive. From the official specification:

The Agent Client Protocol (ACP) standardizes communication between code editors (interactive programs for viewing and editing source code) and coding agents (programs that use generative AI to autonomously modify code).

In plain English: ACP is how your editor drives the agent behind the AI panel. The editor renders the chat, the diffs, and the permission prompts; the agent runs the inference loop, calls tools, and edits files. ACP is the protocol they speak across a subprocess boundary.

ACP as an LSP for AI Agents

Zed framed ACP from day one with an explicit LSP analogy:

Just as the Language Server Protocol unbundled language intelligence from monolithic IDEs, the goal with the Agent Client Protocol is to enable you to switch between multiple agents without switching your editor.

The same decoupling story plays out. LSP let a single editor benefit from language servers written by anyone; ACP lets a single editor benefit from agents written by anyone. One standard, N editors, M agents — instead of N × M bespoke integrations. This is why ACP is often described as the LSP for AI coding agents.

Why ACP matters

Editor–agent portability: switch between Claude Code, Gemini CLI, Codex, or Goose without switching editors.
Less vendor lock-in: adopting a new agent no longer forces an editor migration, and vice versa.
Shared UX surface: chat, diffs, and permission prompts live in the editor instead of being reimplemented per agent.
Open and multi-vendor: Zed, JetBrains, and Google ship against the spec directly; Anthropic's Claude Code and OpenAI's Codex plug in via adapters.
Natural fit with MCP: ACP handles the editor-to-agent layer, while MCP handles the agent-to-tool layer.

How the Agent Client Protocol works

ACP is easiest to understand today as JSON-RPC 2.0 over stdio for local subprocess integration.

The editor launches the agent as a subprocess and exchanges protocol messages with it. That gives the editor a structured way to drive the agent while still keeping the editor in charge of UX, permissions, and workspace mediation.

Remote transports are described in the spec and on the roadmap, but local stdio remains the clearest mental model today. Sessions are bootstrapped via session/new, which can declare the mcpServers the agent should connect to — so ACP and MCP wire up in a single handshake.

Agent Client Protocol architecture: code editor as ACP client talking to AI coding agent as ACP agent over JSON-RPC stdio, with the agent connecting to MCP servers

An ACP deployment has three moving parts:

ACP client — the code editor. Owns the UI and initiates the connection. Zed, JetBrains, Neovim, and Emacs are all clients today.
ACP agent — the AI coding tool. Runs the LLM loop, makes tool calls, and is itself typically an MCP client.
MCP servers — the tools and data sources the agent calls out to. ACP does not replace them.

Work is organized into sessions (a conversation with shared context) and turns (one prompt-to-response cycle within a session).

Important

The direction is subtly reversed from MCP. In MCP the AI application is the "host/client" and tools are "servers." In ACP the editor is the client and the AI agent is the subprocess the editor spawns. Worth flagging because the terminology repeats but the roles flip.

Agent Client Protocol vs MCP: Complementary, not competing

ACP and MCP solve different problems at different layers:

	MCP	ACP
Between	Agent ↔ tools	Editor ↔ agent
Problem it solves	How does the agent call tools?	How does the editor drive the agent?
Client role	AI application / host	Code editor / IDE
Server or subprocess role	Tool provider	AI coding agent
Transport	stdio / HTTP-based transports	stdio today, with remote transport work ongoing

They are complementary, not competing.

A good shorthand is this:

MCP gives the agent tools.
ACP gives the agent an editor.

The ACP ecosystem

The ACP ecosystem has moved fast, but the safest way to describe it is in layers.

On the client side:

Zed is the reference editor implementation.
JetBrains IDEs added ACP support in late 2025.
Community integrations exist for editors such as Neovim, Emacs, and VS Code.

On the agent side:

Gemini CLI supports ACP natively via the --acp flag.
Claude Code participates through the claude-agent-acp adapter.
Codex participates through the codex-acp adapter.
The ACP Registry now provides a curated installation surface for a growing set of agents.

That mix of native implementations plus adapters is exactly what you would expect from an early but rapidly maturing protocol ecosystem.

Conclusion

ACP is doing for agent integrations what LSP did for language tooling: turning bespoke editor integrations into a shared contract.

The pattern is already familiar, one open standard, maintained in the open, with clients and agents shipping independently. The ACP Registry that launched in January 2026 further reduces the friction of discovering and wiring up new agents, and remote transports are on the roadmap to push ACP beyond the local subprocess model.

If you're deciding where to invest as an editor extension author or agent builder, ACP is the surface to build on. For the layer below — how the agent itself talks to tools — see the companion post on the Model Context Protocol.

Recent Posts

Categories

Archives