ACP: The Universal Remote Control for AI Agents

Discover how the Agent Client Protocol (ACP) is decoupling AI interfaces from agent logic to create a standardized ecosystem for AI tools.

Imagine if you had to download a completely different web browser for every single website you wanted to visit. That sounds like a nightmare, right? Yet, that is exactly how the world of AI agents currently works.

⚡ TL;DR: While MCP helps agents talk to tools, ACP (Agent Client Protocol) lets any user interface talk to any agent harness. This decouples the UI from the AI logic, allowing for a 'universal remote' experience for AI agents.

The Simple Version

Right now, most AI agents are locked into their own specific apps. If you use a specific agent harness, you're stuck using the interface that came with it.

ACP (Agent Client Protocol) changes this by creating a common language. It allows a high-quality client (like a code editor) to drive any agent harness, regardless of who built it.

🎯 Think of it this way: MCP is like the plug that lets an agent connect to a power outlet (a tool). ACP is like the universal remote that lets you control any brand of TV (the agent) from one single device.

How It Actually Works

The Gap in the Agentic Stack

We already have MCP (Model Context Protocol), which is a great standard for agents reaching outward to use tools. However, we lacked a standard for the opposite direction: how a user's software tells an agent what to do.

Without a standard, every agent harness uses a 'bespoke' interface. This means developers have to rebuild the user experience from scratch for every new agent they create.

🎯 Think of it this way: It's the difference between having a custom-made key for every single door in a building versus having one master key that opens everything.

Introducing ACP

ACP was developed by teams at Zed and JetBrains to allow a single, high-quality editor to drive any agent. It focuses on the communication between the Client (the UI) and the Harness (the logic).

It handles the essential 'conversational' plumbing: managing sessions, sending user messages, notifying the user of tool calls, and requesting permissions.

Technical Deep Dive

At its core, ACP runs on JSON RPC. This provides a lightweight, stateless way for the client and harness to exchange requests and responses.

One of the most powerful features of ACP is its extensibility. By using underscore-prefixed custom methods, developers can experiment with new patterns without breaking the standard. Once a pattern proves useful, it can be moved onto the official standards track.

This architecture results in a four-piece stack that is completely decoupled:

Client: The UI (e.g., Zed, a terminal, or a web app).
Harness: The agent logic (e.g., Goose).
Tools: The capabilities provided via MCP.
Model: The LLM powering the intelligence.

Because these are connected via remote transports like HTTP and WebSockets, each piece can be hosted anywhere. You could have a local client talking to a remote harness that uses a cloud-based model to trigger local tools.

Why This Matters

When you decouple the interface from the logic, you create a competitive market for User Experience. Instead of every AI company trying to build a mediocre chat box, we get specialized companies competing to build the world's best AI client.

This accelerates innovation. A developer can build a brilliant new agent harness and instantly give it access to every high-end ACP client already in existence.

Ultimately, this moves us away from 'fragmented silos' and toward a true ecosystem where AI tools are interoperable and plug-and-play.

Key Takeaways

MCP is for Agent $ ightarrow$ Tool communication.
ACP is for Client $ ightarrow$ Agent communication.
JSON RPC serves as the communication backbone for ACP.
Decoupling allows the client, harness, tools, and model to be placed independently.
Extensibility via underscore methods allows the protocol to evolve based on real-world usage.
Standardization prevents the 'different browser for every website' problem in AI.