ACP Protocol Explained: A New Open-Source Protocol Standardizing Communication Between IDEs and Coding Agents

Why Do We Need the ACP Protocol?

Right now, every major tech company is releasing its own CLI coding agent—Claude Code, Gemini CLI, OpenAI Codex, and more. While these tools are powerful, their integration with code editors is riddled with hacky, ad-hoc solutions. Anthropic has to build adapters for Cursor, Google has to build adapters for VS Code, and every new "agent × editor" combination requires significant custom work.

This is exactly the problem that ACP (Agent-Client Protocol) aims to solve. Created jointly by Zed Industries (the team behind the open-source editor Zed) and the Google Gemini team, its goal is to standardize the communication protocol between code editors and coding agents—much like MCP standardized communication between AI agents and tools.

It's worth noting that the Zed editor itself was built by the original creators of Atom and Tree-sitter. This next-generation editor is built entirely in Rust, known for its extreme performance and low latency. Zed was designed from the ground up with collaborative editing and AI integration as core features, rather than bolted-on plugins—making it a natural pioneer for driving ACP adoption. Its Rust tech stack provides significant performance advantages when handling high-frequency UI updates (such as real-time diff rendering).

The ACP Protocol in Practice

In the ACP-enabled Zed editor, you can directly choose between different coding agents (currently supporting Gemini CLI and Claude Code), with an experience nearly indistinguishable from a native IDE programming assistant.

For example, after selecting Gemini CLI and typing "create a Python file implementing the A* search algorithm," the entire interaction feels as smooth as using a built-in AI in Cursor—you won't see any CLI interface; everything happens within the IDE.

More importantly, ACP supports real-time diff preview. Code modifications generated by the agent are displayed directly in the editor as a diff view, allowing you to review each change and decide whether to accept it. This isn't a proprietary feature of any specific editor—it's a standard capability at the protocol level.

Seamlessly Switching Between Coding Agents

One of the most exciting features of the ACP protocol is agent agnosticism. Suppose you used Gemini CLI to generate a file, and now you want to use Claude Code to add comments to it—simply switch to Claude Code, create a new conversation thread in the same IDE, and continue working. Claude Code can equally read files, propose modifications, and display diffs through the ACP protocol, with a completely consistent workflow.

This means developers are no longer locked into a specific agent-editor combination. Choosing a coding agent no longer means having to accept the limited editor interfaces it supports.

Technical Architecture of the ACP Protocol

Protocol Essence: Standardized Communication via JSON-RPC

At its core, ACP is a JSON-RPC protocol that enables any code editor to communicate with any coding agent in a standardized way. It uses a transport-agnostic design, typically communicating with subprocesses via standard input/output (stdio).

JSON-RPC is a lightweight remote procedure call protocol that uses JSON as its data format, allowing clients to send requests to servers and receive responses, while supporting batch requests and notifications (one-way messages that don't require responses). Compared to REST APIs, JSON-RPC is better suited for scenarios requiring frequent bidirectional communication—protocol overhead is minimal, and it natively supports asynchronous calling patterns. This characteristic is particularly critical for scenarios where editors and agents need to synchronize code changes in real-time and continuously relay user actions. ACP's choice of JSON-RPC over WebSocket or gRPC also reflects its prioritization of lightweight design and ease of implementation.

The specific flow works as follows:

1. Editor launches the agent: Running as a subprocess
2. Exchange structured requests and responses: In JSON-RPC format
3. Agent proposes actions: Including navigate, edit, run, tool calls, etc.
4. Editor executes actions: After obtaining user permission, applies changes to the UI

Connecting Custom Agents to ACP

Beyond the out-of-the-box Gemini CLI and Claude Code, ACP also supports connecting any custom agent. You simply need to create a JSON configuration file specifying the agent server information, startup command, and entry file (such as index.js) to connect your own agent to any ACP-enabled editor.

ACP vs. MCP: Complementary, Not Competing

Many people's first reaction is to ask: what's the difference between ACP and MCP? The answer is—they solve problems at completely different layers and are naturally complementary.

To understand this, you first need to understand MCP's positioning. MCP (Model Context Protocol) is an open standard released by Anthropic in late 2024, designed to solve integration issues between AI models and external tools/data sources. Before MCP, every AI application needed to write custom integration code for each tool, creating an "M×N" integration matrix. MCP defines a unified tool-calling interface that allows AI agents to access file systems, databases, APIs, and other resources in a standardized way—it solves the problem of "what can an agent do." ACP, on the other hand, solves the problem of "how does an agent communicate with an editor"—the two operate at completely different levels of abstraction.

Dimension	ACP	MCP
Communication parties	Editor ↔ Coding Agent	Agent ↔ Tools/Context
Controls	UI components (diffs, navigation, edits)	Tool calls, data source access
Core value	Standardized IDE integration experience	Standardized tool ecosystem access

In simple terms: MCP lets agents call various tools; ACP lets agents control the editor interface. An ACP-enabled editor can perfectly well allow ACP agents to use MCP servers under the editor's permission controls—there is no conflict whatsoever between the two.

Current Limitations and Future Outlook

Issues to Watch

Security and Authentication: This is currently ACP's biggest shortcoming. MCP is still refining its security and authentication mechanisms, and ACP's specifications in this area are virtually nonexistent. As the protocol gains adoption, this will be a priority issue to address. Notably, the pitfalls the MCP community encountered regarding security—such as early tool injection attacks and permission abuse issues—serve as important cautionary lessons for ACP.

Ecosystem Coverage: Currently, ACP is only available in the Zed editor, which is written entirely in Rust. Whether mainstream editors like VS Code and JetBrains will adopt this protocol remains unknown. The protocol's success largely depends on the breadth of ecosystem participants.

Specification Maturity: ACP is still in its early specification stage. APIs will continue to change, and versioning mechanisms will be introduced later.

Why ACP Is Worth Watching

Despite the many uncertainties, ACP addresses a real and pressing pain point. As the number of coding agents grows explosively, the "N agents × M editors" integration matrix will become unmaintainable. ACP provides an elegant decoupling solution: agent developers only need to implement the ACP protocol once, and editor developers only need to support the ACP protocol once, enabling plug-and-play for any combination.

This follows the same success logic as MCP—standardization creates network effects. MCP went from release to widespread adoption by mainstream AI tools in just a few months, precisely because it compressed "M×N integration effort" down to "M+N." If ACP can replicate this path and gain support from enough editors and agent vendors, it has the full potential to become the next foundational protocol in the coding AI space.

For developers, it's at least worth spending time understanding ACP's design philosophy and technical details. Even if ACP itself doesn't ultimately prevail, a standardized communication protocol between editors and agents will inevitably arrive in some form.