ACP: The Universal Remote Control for AI Agents
Disclaimer: This blog written by AI 🤖
Every AI agent today is effectively stranded on the machine it runs on. You can reach it through a terminal wrapper, a desktop app, or a vendor-specific SDK — but there is no industry-standard way for any client to control any agent over the network. Alex Hancock, a software engineer at Block and maintainer of both the Goose open-source agent harness and the Rust SDK for the Model Context Protocol, opens his AI Engineer talk by naming that gap directly: MCP solved the outward direction (agents reaching tools and data), but nothing equivalent exists for the inward direction (clients telling agents what to do and receiving progress back).
Hancock’s answer is the Agent Client Protocol (ACP), an open JSON-RPC standard originally drafted by the teams behind Zed and JetBrains. The Goose team adopted ACP, extended it with remote transport support, and is now pushing it as a broadly applicable layer across the agentic stack. The core idea is simple: a single /acp endpoint supporting both Streamable HTTP and WebSocket, deliberately aligned with MCP’s own Streamable HTTP transport so the two protocols share a consistent networking approach. When you pair ACP’s remote transport with MCP’s tool connectivity, the agent workload becomes location-independent — free to run on a laptop, in a container, or on a cloud VM while any compliant client reaches in through open standards.
The practical demonstration is compelling. Hancock shows the same Goose process driven by four different clients simultaneously: a terminal interface, an open-source client called Toad, the Goose desktop app, and the Zed editor. All four send the same prompt; Zed streams back file opens and text edits into new tabs in real time. Before the remote transport work, ACP only worked locally — a dealbreaker for cloud-hosted agents. The new HTTP transport with WebSocket upgrade keeps message semantics identical while enabling network connections, so a client on any machine can control an agent running elsewhere with no change to the harness implementation.
For harness engineers, ACP closes the last interoperability gap in a two-protocol stack. MCP standardizes how agents reach outward; ACP standardizes how clients reach inward. Together they eliminate vendor lock-in on both where your agent lives and who can talk to it — the universal remote control Hancock describes is not a metaphor but a concrete open standard gaining adoption across editors, harnesses, and cloud runtimes.