ACP: The Universal Remote Control for AI Agents

Alex Hancock, Block11:01 · Sept 2026 · 6,707 views
Thumbnail for ACP: The Universal Remote Control for AI Agents Watch on YouTube
TL;DR
  1. 1

    ACP gives client software a standard way to send tasks to AI agent harnesses and receive updates.

  2. 2

    ACP uses JSON-RPC sessions for messages, tool-call notifications, permission requests, and extensible custom methods.

  3. 3

    Remote transports for ACP, MCP, and models let clients, harnesses, tools, and models run in different places.

Summary

Alex Hancock argues that AI agent harnesses need a shared client interface. MCP already gives agents a common way to call tools and read data, but software that drives the harness usually relies on a custom interface. That can force users to use one application for each harness. ACP, or Agent Client Protocol, came from Zed and JetBrains teams that wanted one editor client to control different harnesses. It uses JSON-RPC and supports sessions, user messages, agent responses, tool-call updates, and permission requests. Hancock demonstrates Zed and a terminal client from Poolside AI controlling the same Goose agent. He then shows a remote HTTP and WebSocket transport added to the protocol. Alongside remote MCP and model endpoints, this lets the client, harness, tools, and model move independently. Hancock expects competition among clients to improve their user experience.

Key ideas
01:23

Agent harnesses often expose custom client interfaces

Hancock says many AI harnesses have bespoke interfaces, and some can be controlled by only one client application. He compares this to needing a different browser or protocol for every website. That arrangement would prevent the open web from working as it does. His proposal starts with giving client software a common way to control different harnesses.

02:21

MCP created an ecosystem because many systems adopted it

MCP gives agents a standard way to call tools, take actions in other systems, and read resources. Hancock says its strongest property is that everyone uses it, rather than a particular design detail. That shared adoption has produced thousands or tens of thousands of servers that agents can connect to. ACP applies the same ecosystem idea to the direction from client software toward the agent harness.

03:02

ACP began with editors that wanted one client for many harnesses

The Zed and JetBrains teams proposed ACP so an editor such as Zed or IntelliJ could control any compatible harness through one client implementation. A client can send tasks, receive results, and see files being edited. Hancock says the protocol is relatively neutral and has few editor-specific features, so it can also support other kinds of client software.

04:22

ACP carries sessions, messages, updates, and permission requests

ACP establishes a connection with a set of capabilities, then creates sessions. Within a session, a client can send user messages and receive text, images, audio, or progress updates. The harness can report tool calls and their metadata. It can also send permission requests when the client needs to ask a user whether a tool call should proceed. The protocol uses JSON-RPC messages.

05:21

Custom methods let ACP develop from real usage

ACP allows extensions through methods with an underscore prefix. Different harness and client projects can try their own methods and see which patterns recur. Hancock expects common patterns to move onto the protocol's standards track after they have been shaped by usage across the ecosystem. This gives projects room to experiment before the protocol settles on a shared feature.

06:17

Different clients can drive the same Goose agent

Hancock demonstrates a simple project in Zed, where Goose reports text, tool-call information, and its findings about an HTML file. He then uses a terminal-based client from Poolside AI on the same project and gets the same experience from the same Goose implementation. Both clients connect locally over standard input and output, showing that the harness does not need a separate client-specific integration.

07:24

Remote transports separate the four parts of the agent stack

ACP originally had no remote support, so Hancock's team specified HTTP transport with a WebSocket upgrade. The protocol messages and semantics stay the same while the transport changes. He divides the stack into the client, the harness that runs the tool-calling loop, the tools, and the model. Remote ACP, MCP transports, and remote model endpoints allow these components to run on the same machine or in different locations.

09:26

More clients could increase competition around user experience

Hancock imagines editor, desktop, mobile, terminal, personal, and domain-specific clients that can work with many harnesses. A company could also create a customised client that works across harnesses. If many clients compete in this market, users can leave products that do not meet their needs. Hancock expects that pressure to improve the experience of using AI agents.

"And so, you can see it did the same thing. It showed me some text results back, it showed a tool call, and then it showed a summary."06:59
Who should watch
  • You maintain an agent harness and want editors, terminal tools, or other applications to drive it without a custom integration for each client.
  • You are building an agent client and want one protocol for sending tasks, receiving updates, and handling permissions across compatible harnesses.
  • Your deployment splits models, tools, harnesses, and user-facing applications across local machines, containers, or cloud services.