# ACP: The Universal Remote Control for AI Agents — Alex Hancock, Block
Alex Hancock, Block
[Talk page](https://ai.engineer/talks/YkNulwcc5jk-acp-universal-remote-control-ai-agents) · [Video](https://www.youtube.com/watch?v=YkNulwcc5jk)
## ACP: The Universal Remote Control for AI Agents
Alex Hancock explains how the Agent Client Protocol lets different applications drive the same harness, and how remote transports could make clients, harnesses, tools, and models independently placeable.
ACP: The Universal Remote Control for AI Agents
### A good harness can still trap you in one application
[0:12](https://www.youtube.com/watch?v=YkNulwcc5jk&t=12s)
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.
A good harness can still trap you in one application
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.
### One editor implementation, many harnesses
[3:12](https://www.youtube.com/watch?v=YkNulwcc5jk&t=192s)
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](https://www.youtube.com/watch?v=YkNulwcc5jk&t=192s)
One editor implementation, many harnesses
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.
### Sessions carry work, progress, and permission requests
[4:12](https://www.youtube.com/watch?v=YkNulwcc5jk&t=252s)
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.
Sessions carry work, progress, and permission requests
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 same HTML project, through Zed and a terminal
[6:12](https://www.youtube.com/watch?v=YkNulwcc5jk&t=372s)
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](https://www.youtube.com/watch?v=YkNulwcc5jk&t=372s)
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.
### Remote transport makes four components movable
[7:13](https://www.youtube.com/watch?v=YkNulwcc5jk&t=433s)
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](https://www.youtube.com/watch?v=YkNulwcc5jk&t=433s)
Remote transport makes four components movable
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.
Three connections around the harness
Remote transports let the client, harness, tools, and model occupy different machines while preserving their roles.
- Client — User-facing application or headless software that sends work and receives updates.
- Harness — Runs the tool-calling loop; Goose supplies the ACP interface in the demonstrations.
- Tools — External actions and data, commonly reached through MCP.
- Model — May be local or accessed through a remote model endpoint.
- Client → Harness (ACP: sessions and user messages)
- Harness → Client (ACP: content, tool updates, permission requests)
- Harness → Tools (MCP, including remote tool calling)
- Harness → Model (Model endpoint)
### Let clients compete on the experience
[9:13](https://www.youtube.com/watch?v=YkNulwcc5jk&t=553s)
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.
Let clients compete on the experience
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.
## Key takeaways
- ACP supplies the client-to-harness interface for assigning work and receiving updates; MCP supplies connectivity from agents to external tools and data.
- Sessions can carry user messages, multimodal replies, tool-call notifications, and permission requests, giving clients information to display during work.
- Zed and Poolside AI's terminal client drive the same Goose agent through one harness-side ACP implementation, demonstrating a change of interface without replacing the agent.
- Remote ACP, remote MCP, and model endpoints make the placement of clients, harnesses, tools, and models independently configurable.
- Underscore-prefixed custom methods allow experimentation; repeated patterns across projects can inform additions to the shared protocol.
## Resources
- [Durable, resumable HTTP transport proposal](https://github.com/alexhancock/agent-client-protocol/blob/8b917fd5c7f0d6b0116cb8689322e93c0df44725/docs/rfds/durable-resumable-http-transport.mdx) — A subsequent proposal linked by Hancock for reconnecting and resuming ACP connections to cloud-hosted agents. It extends the remote-transport topic beyond the recording's same-machine network demonstration.
## Related talks
- [Building an ACP-Compatible Agent Live — Bennet Fenner, Zed](https://ai.engineer/talks/HsxQICTLF84-building-acp-compatible-agent-live) — A practical next recording for moving from ACP's client–harness separation to building a compatible agent.
- [Scaling Agents on Kubernetes with acpx and ACP](https://ai.engineer/talks/VaS2h-dY1-4-scaling-agents-on-kubernetes-acpx-acp) — Continues the deployment question raised by making the harness remotely reachable.
## Slides
### About the speaker
Alex Hancock works on Goose, an open-source harness that began at Block, and on MCP’s Rust SDK.
[0:33](https://www.youtube.com/watch?v=YkNulwcc5jk&t=33s) [A black slide lists Block, Goose, and MCP and ACP under the heading “me.”](https://assets.ai.engineer/sites/aiecode2025/sha256/f4f2208eca4ca81e81bfc013a7efe1475f2a16fbc8f1d7c3152a5eb5036af2b6.webp)
me
block since way back
goose
MCP & ACP
Interface text:
Chrome File Edit View History Bookmarks Profiles Tab Window Help
Wed Jul 1 3:46 PM
remote - the universal remote
index.html
Ask Gemini
File /Users/alexhancock/Talks/2026-07-01%20-%20AI%20Engineer%20SF/AIE/index.html
Work
### Harness interfaces
Harness interfaces are often bespoke, sometimes leaving only one client to control a harness. Hancock compares this to needing a different browser for each website; the diagram shows a disconnected client and harness.
[1:21](https://www.youtube.com/watch?v=YkNulwcc5jk&t=81s) [A slide compares bespoke client-to-harness interfaces to needing one browser per website, beside a disconnected browser and harness diagram.](https://assets.ai.engineer/sites/aiecode2025/sha256/17ba40f5783bf7f89a8b7f6a9c3f286bcf93d214157760bd713a11d1b4a6cdeb.webp)
harness interfaces
bespoke
often 1-to-1 client to harness
web: one browser per website
we can do better!
Interface text:
Chrome File Edit View History Bookmarks Profiles Tab Window Help
remote - the universal remote
index.html
Ask Gemini
File /Users/alexhancock/Talks/2026-07-01%20-%20AI%20Engineer%20SF/AIE/index.html
Work
Wed Jul 1 3:47 PM
### Standards create ecosystems and markets
Hancock argues that MCP lets agents call tools and access data, while client software still needs a standard for assigning tasks and receiving updates. A hub-and-spoke diagram illustrates an ecosystem around a shared standard.
[2:19](https://www.youtube.com/watch?v=YkNulwcc5jk&t=139s) [A slide says MCP lets agents do things and asks how to tell an agent what to do, beside a hub-and-spoke diagram.](https://assets.ai.engineer/sites/aiecode2025/sha256/9eeaecc2fe19dd366cd07bf3d291bbbe85e2cfa908a143068a1a5199ab286f38.webp)
standards create ecosystems & markets
mcp: agent does things
???: tell agent what to do
Interface text:
Chrome File Edit View History Bookmarks Profiles Tab Window Help
Wed Jul 1 3:48 PM
remote - the universal remote
index.html
Ask Gemini
File /Users/alexhancock/Talks/2026-07-01%20-%20AI%20Engineer%20SF/AIE/index.html
Work
### The standard we need
Zed and JetBrains proposed ACP so a client can control multiple agent harnesses. The diagram links three windows to a central agent; Hancock sees potential for clients beyond editors.
[3:14](https://www.youtube.com/watch?v=YkNulwcc5jk&t=194s) [A slide introduces ACP and lists editor companies, control of multiple agents, and broader utility; a diagram connects three client windows to an agent.](https://assets.ai.engineer/sites/aiecode2025/sha256/021f2a098d74c2324aa1c0f7696728bcef88324317587e589c282b40ca3f7da1.webp)
the standard we need
ACP: agent client protocol
– editor companies
– control multiple agents
– broader utility
Interface text:
Chrome File Edit View History Bookmarks Profiles Tab Window Help
Wed Jul 1 3:49 PM
remote · the universal remote
index.html
Ask Gemini
File /Users/alexhancock/Talks/2026-07-01%20-%20AI%20Engineer%20SF/AIE/index.html
Work
### ACP
ACP connects a client to an agent, establishes a session, and sends user messages for the agent to answer. It uses JSON-RPC and supports custom methods.
[4:27](https://www.youtube.com/watch?v=YkNulwcc5jk&t=267s) [A slide lists ACP sessions, user messages, agent responses, JSON-RPC, and extensibility, alongside a client-agent sequence diagram.](https://assets.ai.engineer/sites/aiecode2025/sha256/44871bb957e42ae399cdd8ecae3bd730d094e0e9493dfe7cb8e051eac5356bdb.webp)
acp
create sessions
send user messages
(text/image/audio)
agent responds
JSON-RPC
extensible
Diagram:
PROTOCOL
A SESSION
acp
client
agent
initialize
capabilities handshake
session/new
open a session
session/prompt
user message
processing...
JSON-RPC
stdio / http / ws
Interface text:
Chrome File Edit View History Bookmarks Profiles Tab Window Help
remote · the universal remote
index.html
Ask Gemini
File /Users/alexhancock/Talks/2026-07-01%20-%20AI%20Engineer%20SF/AIE/index.html
Work
Wed Jul 1 3:50 PM
### Zed project summary
In Zed, Goose reads the project’s HTML file and returns a summary alongside the source. The demo uses Goose’s ACP interface to send text and tool-call information back to Zed.
[6:36](https://www.youtube.com/watch?v=YkNulwcc5jk&t=396s) [Zed shows an agent's summary of a sailing history website beside its HTML source.](https://assets.ai.engineer/sites/aiecode2025/sha256/93fd1a064d5989ece251653f66a27f533f2f1a720446ef66cfac84d1b9149ee5.webp)
Project information request
reading index html file
This is a single-page website celebrating the sailing history of Rhode Island — a polished, self-contained marketing/educational landing page.
Overview
• Structure: A single index.html file (~1K lines) with everything inline — no build tools, frameworks, or dependencies beyond a Google Fonts import (Playfair Display + Source Sans Pro).
• Theme: Nautical/maritime aesthetic with a navy-and-gold color palette, ocean gradients, and emoji-based iconography.
Content sections
1. Hero — Animated compass and drifting waves, headline “The Sailing Heritage of Rhode Island.”
2. Intro (“Where America Learned to Sail”) — History narrative plus stat cards (400+ miles of coastline, 1663 Royal Charter, 53 years hosting the Cup, 100+ yacht clubs).
3. Timeline — 9 milestones from the pre-1600s Narragansett navigators through the Gaspee Affair (1772), America’s Cup era, the 1983 loss to Australia II, and today.
4. Landmarks — 6 cards: [illegible]
index.html
Sailing History of Rhode Island