ACP: The Universal Remote Control for AI Agents — Alex Hancock, Block

An agent harness may offer useful capabilities while leaving you only one application that can control it. Alex Hancock, a software engineer at Block, encounters this problem through his work on Goose, an open-source harness that began inside Block and was donated to the Linux Foundation. He also maintains the Rust SDK for the Model Context Protocol, or MCP. His opening joke about not implementing MCP tasks—blaming his own laziness—sets a practical tone: standards need people to implement them before they help users.

The problem is the bespoke interface between an application and its harness. When each harness expects its own way of receiving instructions and returning updates, client software must accommodate those differences. In the worst case Hancock describes, exactly one client can drive a particular harness. His web analogy makes the cost familiar: imagine needing a different browser for every website. The choice of underlying service would also dictate the interface you use.

MCP supplies a useful precedent on the other side of the agent. It gives agents a shared way to call tools, read resources, and act in external systems. Hancock locates its greatest strength in adoption: many servers become useful to many agents because they share the protocol. The missing counterpart is a shared way for client software to assign work to an agent and receive updates about that work.

The Agent Client Protocol, or ACP, emerged from the Zed and JetBrains teams. Their immediate need was straightforward: build one high-quality agent client inside an editor, then use that implementation with different harnesses. Sending tasks, receiving results, and showing which files an agent edits should not require a separate client implementation for every harness. 3:12

Goose's team saw room to use the same interface beyond editors. ACP has relatively few editor-specific features, so the application controlling an agent could take another form. The architectural decision is to keep the client-to-harness conversation general enough that a terminal, desktop application, or other client can express work and display progress without becoming an editor.

An ACP interaction starts with a connection between a client and a harness, with capabilities associated with that connection. The client can then create sessions and send user messages within them. Those messages may originate from a person typing into an application or from client software acting on its own. Sessions give the subsequent replies and updates a place in the interaction.

The return path carries several kinds of information:

• Content: The agent can respond with text, images, or audio.
• Tool activity: A tool-call notification identifies the tool and supplies metadata about the call, allowing the client to show what the agent is doing as work proceeds.
• Permission requests: The harness can send a request that the client presents to the user as a decision about whether a tool call should proceed.

This gives the client more to render than a final answer. It can make ongoing work visible and bring a user into a decision when permission is needed.

ACP uses JSON-RPC messages and permits custom methods with an underscore prefix. That extension convention lets projects add behavior beyond the shared protocol. Hancock's proposed path to standardization begins with actual use: if different client and harness projects develop similar extensions, those recurring needs can become candidates for the protocol itself.

The tradeoff is between a common implementation and room to experiment. A custom method creates space for a project-specific feature; moving a useful pattern into the shared protocol makes it available through a common interface. Extensions therefore supply evidence for future design decisions, while the base protocol supplies the interoperability that clients can already build around.

The first demonstration follows one small task through two interfaces. In Zed, Hancock asks Goose to explain a project containing a single HTML file. Zed sends the request through Goose's ACP interface. Goose returns text and tool-call information describing what it read and did, then identifies the single-file project and explains it. The client displays both the activity and the resulting explanation. 6:12

Next, a terminal-based client from Poolside AI receives the same request in the same project. It connects to the same agent, displays text and a tool call, and streams a summary. The observable change is the application presenting the interaction: an editor gives way to a terminal, while Goose continues to handle the work through one harness-side ACP implementation.

Both clients communicate locally over standard I/O. The demonstration makes the separation concrete: the client sends the task and renders the updates; Goose performs the agent work and emits those updates through its common interface. Changing clients preserves that division of responsibility, so the terminal does not need to become a second implementation of Goose's agent loop.

Local standard I/O connects applications on one machine, but cloud-hosted harnesses need a network path. When Goose's team joined the ACP work, the protocol lacked remote support. They specified an HTTP transport with a WebSocket upgrade. At the time of the recording, this transport was just landing; the design kept the messages and protocol semantics the same while changing how they traveled. 7:13

Where does each protocol sit, and which component must move with which? The topology below answers that question. Goose's model of the stack has four parts: a client, a harness implementing the tool-calling loop, the tools, and the model. ACP joins the client to the harness. MCP commonly joins the harness to tools. Model endpoints supply another network connection. The harness sits at the junction of these relationships; the tools and model are separate participants rather than steps downstream of the client interface.

Once each connection can cross a network, placement becomes a choice for each component. All four could run on the same machine. The harness could run elsewhere while the client stays local. Alternatively, only the tools or only the model could be remote. The transport work matters because a common message format alone does not provide these deployment choices: the connections also need a way to reach another machine.

A final demonstration uses a client Hancock built the previous night to ask Goose to write a poem. This client reaches the same process over the network, although both still run on his machine. It demonstrates the network transport rather than a cloud deployment. A container or cloud-hosted harness is the proposed next placement; the attraction is that the messages and client library remain the same when switching between local and remote communication.

The closing invitation is to build clients or add ACP support to harnesses. Hancock describes an emerging range of editors, desktop applications, mobile applications, and terminal clients. His suggested uses extend that variety:

• Personal clients: An interface tailored to how one person wants to orchestrate agents.
• Business clients: Applications organized around a particular domain or company's needs.
• White-label clients: A customized interface that works with multiple harnesses through the common protocol.

The intended incentive follows from being able to switch. If a client fails to meet a user's needs, interoperability gives that user another place to go while retaining access to compatible harnesses. Client developers then have a reason to compete on interaction quality. Hancock expects this market to improve the experience of using AI; that remains a forecast dependent on adoption and useful alternatives, rather than an outcome established by the demonstrations.