From MCP to ACP: A New Standard in AI Agent Interoperability

After a recent update to the Zed editor, I noticed it now includes native support for AI agents like Gemini CLI and Claude Code. What is surprising is not the integration itself, but the collaborative effort behind it. Zed Industries, together with Google, announced the Agent Client Protocol (ACP), an open standard designed to do for AI agents what the Model Context Protocol (MCP) did for tools: enable developers to focus on building the best possible agents without getting bogged down by integration complexities.

Inspired by the Language Server Protocol (LSP) and MCP (Model Context Protocol), the protocol was jointly designed, with Zed focusing on the editor (client) and Google on the agent. The initial announcement from Zed provides a deeper dive into their vision of unbundling AI agents from IDEs.

Why a Standard Protocol Matters #

Creating a new AI agent today often means building everything from the ground up. Most solutions are designed for a simple web chat interface, and integrating them into anything beyond that — such as developer tools or other specialized applications — requires significant, often bespoke, effort. This is a challenge I’ve encountered firsthand in my own projects.

ACP promises a revolution similar to what MCP brought to AI tools. I know the impact of such a standard well, as my own AI agents library adopted MCP early on (version 0.1.3, released January 14, 2025) to standardize tool use, as seen on GitHub. By creating a common language for agents and clients, it allows everyone to focus on their strengths:

• Agent creators can concentrate on improving their agents’ intelligence and capabilities instead of building and maintaining separate interfaces for each editor.
• Client developers can focus on providing the best user experience for integrating and managing AI agents within their applications.

This decoupling fosters innovation and prevents vendor lock-in, creating a more open and competitive ecosystem.

A Growing Movement #

The push for an open standard is gaining momentum on the client side. Shortly after the initial announcement, JetBrains revealed they are joining the movement, as detailed in their blog post. This is a significant development, as it brings a major player in the IDE space into the fold. JetBrains plans to contribute from both sides: as a client in their IDEs and as an agent provider with JetBrains Junie.

Anthropic Joins the Game? #

Further evidence of this trend comes from the agent side. Anthropic’s Claude Code, for example, has already received an unofficial ACP integration created by Zed Industries, freeing it from the command line and embedding it directly into the editor. You can read more about this effort on the Zed blog. With this momentum, it is likely that we will see community-driven ACP support for other platforms, like VS Code, in the near future.

Beyond the IDE #

The potential of ACP extends beyond just text editors. I see at least three other significant opportunities:

1. Agent-as-a-Product: Developers can focus on delivering a specialized AI agent as a standalone product, without needing to build an entire platform around it. This agent could then be easily integrated into any ACP-compliant system.
2. Unified Interfaces: ACP can power unified frameworks for connecting AI agents to various applications. Anyone who has tried to build a custom Slack integration for an AI agent knows how painful the process can be. A standard protocol would dramatically simplify this.
3. My own library: I plan on introducing ACP to my AI agents library, agentai, in future releases.

To explore this second point, I’ve been experimenting with my TypeScript skills to build an MVP of an ACP client in a Chromium-based application. Here is a small sneak peek:

ACP is MCP-Compatible #

A crucial feature of ACP is its built-in compatibility with the Model Context Protocol (MCP). From the outset, the creators understood the importance of the existing tool ecosystem. The protocol allows both the agent and the client to provide MCP servers. The ACP client can act as a proxy for any MCP servers it is connected to, and can also deliver its own set of tools by exposing itself as an MCP server, creating a powerful and extensible architecture. This is one of the key behaviors I am leveraging in my own MVP.

For more technical details, I recommend reading about MCP support in the official architecture design.

ACP vs. A2A: Complementary Protocols #

Does ACP compete with the Agent-to-Agent (A2A) protocol? Not exactly. The two protocols fill different needs. While A2A focuses on enabling cooperation between multiple agents, ACP focuses on the interface between an agent and the end-user’s application.

However, the two can coexist and complement each other. Nothing prevents a primary agent, connected to a user via ACP, from scheduling and delegating tasks to a team of specialized agents using an A2A protocol. This aligns perfectly with established patterns for multi-agent collaboration, as detailed by DeepLearning.AI.

Looking to the Future #

The announcement of the Agent Client Protocol is a genuinely important step for the future of AI-powered development. By creating an open standard for communication, it paves the way for a new ecosystem of interoperable agents and clients. I can’t wait to see the new possibilities this will unlock, and I already have a couple of ideas on how to leverage it in my own projects beyond the simple MVP I’ve started. More importantly, it allows the community to focus on innovation rather than integration, which will accelerate progress for everyone. The future of AI agents is collaborative, and thanks to ACP, it’s also more open.