Agent Client Protocol: One Standard for AI Coding Agents

If you have used Claude Code, Codex CLI, Gemini CLI, and a handful of editor-native agents over the last year, you have felt the same friction: every agent speaks its own dialect, ships its own UI, and locks you into one tool. Switching editors meant re-learning the agent. Building an editor meant re-integrating every agent by hand.

The Agent Client Protocol (ACP) fixes that. It is an open, JSON-RPC-based standard that lets any AI coding agent talk to any code editor. Think of it as the Language Server Protocol (LSP), but for agents — implement it once, and your agent works everywhere. This guide explains how ACP works, shows you real configuration, and walks through why it became one of the most important developer standards of 2026.

The problem ACP solves

Before ACP, the AI coding ecosystem looked like a tangle of point-to-point integrations. Each editor had to build a bespoke connector for each agent, and each agent had to ship plugins for each editor. With N editors and M agents, the industry was on the hook for N times M integrations — a combinatorial mess that slowed everyone down and trapped developers inside walled gardens.

This is the exact problem the Language Server Protocol solved for language tooling a decade ago. Instead of every editor implementing Python, Rust, and Go intelligence separately, LSP defined one protocol so a single language server could serve every compatible editor. ACP applies the same insight to autonomous coding agents: define the contract once, and the N times M problem collapses into N plus M.

How ACP works

ACP standardizes communication between two roles:

• The client — an interactive editor such as Zed, a JetBrains IDE, Neovim, Emacs, or even a notebook like marimo.
• The agent — a program that uses generative AI to autonomously read, reason about, and modify code, such as Claude Code or Gemini CLI.

The two communicate over JSON-RPC 2.0, typically across the agent subprocess's standard input and output streams. The editor launches the agent as a child process and they exchange structured messages. Because the transport is just stdio, there are no ports to manage, no servers to deploy, and no network configuration — the agent runs locally alongside your editor.

The message lifecycle

A typical ACP session follows a predictable flow:

1. Initialize — The client and agent perform a handshake, negotiating a protocolVersion and announcing their capabilities. The current stable protocol version is 1, and wire compatibility is determined by this negotiated value rather than by package version numbers.
2. Authenticate — If the agent requires credentials, the client supplies them.
3. Session creation — The client calls session/new to start a stateful conversation tied to a working directory.
4. Prompting — The client sends a user request with session/prompt. This carries the instruction plus relevant context.
5. Streaming updates — As the agent works, it streams session/update notifications back to the editor: reasoning text, tool calls, file diffs, and progress. The editor renders these in real time with syntax highlighting and "agent following," so you watch the work as it happens.
6. Permission requests — Before a sensitive action, the agent calls session/request_permission, and the editor prompts you to approve or deny. This keeps a human in the loop for risky operations.

File and terminal access

Crucially, the agent does not touch your filesystem directly. It asks the editor to do it through protocol methods like fs/read_text_file and fs/write_text_file. This is a deliberate design choice: the editor already has your unsaved buffers, your file watchers, and your undo history. Routing file operations through the client means the agent sees exactly what you see, and every change flows through the editor's normal review and undo machinery instead of mutating files behind your back.

Configuring an ACP agent

Because the protocol is uniform, wiring up a new agent is mostly a matter of telling your editor how to launch it. In Zed, custom external agents live under the agent_servers key in settings.json:

{
  "agent_servers": {
    "my-agent": {
      "type": "custom",
      "command": "node",
      "args": ["~/projects/agent/index.js", "--acp"],
      "env": {}
    }
  }
}

The fields are minimal: command is the executable, args are the launch arguments (here we pass an --acp flag so the program starts in protocol mode), and env lets you inject environment variables such as API keys. Once saved, the agent appears in the editor's agent panel and is ready to take prompts. JetBrains IDEs, Neovim, and Emacs follow the same pattern with their own configuration surfaces.

Building an ACP agent

If you are on the other side — building an agent rather than consuming one — official SDKs exist for the languages you are most likely already using:

• Rust via the agent-client-protocol crate
• TypeScript via the @agentclientprotocol/sdk npm package
• Python, Java, and Kotlin SDKs are available as well

The SDK handles the JSON-RPC plumbing — message framing, request and response correlation, and notification dispatch — so you implement the handlers that matter: respond to initialize, accept a session/prompt, emit session/update notifications as your model reasons, and request permission before destructive actions. The protocol's surface is small enough that a minimal agent fits in a few hundred lines, yet expressive enough to support full agentic workflows.

The ACP Registry: implement once, distribute everywhere

A protocol is only half the story — discovery and distribution are the other half. On January 28, 2026, the project launched the ACP Registry to close that gap.

Before the registry, even an ACP-compatible agent faced a distribution headache: developers had to publish it as a separate extension for each client, or ask users to install it manually. The registry centralizes this. An agent author follows the submission guide and opens a pull request to the registry repository, and from that single action the agent becomes available across every compatible client.

On the consumption side, Zed ships a built-in ACP Registry page for browsing and installing agents, and JetBrains IDEs added the same capability through an ongoing partnership. Browse, click install, and you always have the latest version. The registry already lists Claude Code, Codex CLI, GitHub Copilot CLI, OpenCode, Gemini CLI, and a growing roster of others. This is what finally delivered ACP's original promise of "implement once, work everywhere."

How ACP relates to MCP and A2A

Developers tracking the agent-standards space reasonably ask how ACP fits alongside the Model Context Protocol (MCP) and Agent-to-Agent (A2A) protocol. They are complementary, not competing:

• MCP connects an agent to tools and data — databases, APIs, file stores, and external services. It answers "what can the agent use?"
• A2A connects an agent to other agents for delegation and collaboration. It answers "how do agents talk to each other?"
• ACP connects an agent to the editor and the human driving it. It answers "how does the agent surface its work to me, and how do I steer it?"

A single coding agent can speak all three at once: ACP to render its reasoning in your editor, MCP to reach your database, and A2A to hand a subtask to a specialist agent. They occupy different layers of the same stack.

Why this matters for developers and teams in the MENA region

For developers across Tunisia, Saudi Arabia, and the wider MENA region, ACP carries a strategic payoff beyond convenience. Because the protocol decouples the agent from the editor, your choice of agent is no longer a long-term lock-in. If pricing changes, a model gets export-restricted, or a better agent appears, you swap the entry in settings.json and keep your editor, your muscle memory, and your workflow intact.

That portability matters in a year where frontier model access has grown unpredictable — gated by export controls, customer-by-customer approvals, and shifting pricing. An editor that speaks ACP can route to a hosted frontier agent today and to a self-hostable open-weight agent tomorrow, without re-tooling. For teams standardizing their engineering stack, betting on the open protocol rather than any single vendor is the resilient choice.

Getting started

To try ACP in under ten minutes:

1. Install an ACP-capable editor such as Zed or a recent JetBrains IDE.
2. Open the built-in ACP Registry and install an agent like Claude Code or Gemini CLI.
3. Open a project, invoke the agent panel, and send a prompt — watch the streaming updates and approve actions as they come.
4. When you want a custom agent, add an agent_servers entry pointing at your executable.

The bottom line

ACP is doing for AI coding agents what LSP did for language intelligence: turning a fragmented mess of point-to-point integrations into a clean, open standard that benefits everyone. Editors get access to every agent. Agents reach every editor. And developers get to choose their tools freely, swap them painlessly, and keep a human firmly in the loop. In a fast-moving 2026 agent landscape, that kind of portability is not a nice-to-have — it is how you avoid getting locked into the wrong bet.