Published: 2026-09-09

ACP is MCP's missing half: a standard for telling a harness what to do

Chapters / key moments (click to jump — plays here on the page)

The gap is stated cleanly: we have a good standard for the agent going out and doing things, and no standard for telling the agent what to do. MCP solved the first — and its power, as the speaker puts it, is not anything about MCP itself but that everyone uses it. The second half is still bespoke: many harnesses have exactly one client application that can drive them. The analogy is the one that lands — it would be like needing a different browser for every website. ACP, which came out of the editor world, is the proposed answer, and the interesting consequence is architectural rather than cosmetic.

Source video

"ACP: The Universal Remote Control for AI Agents" by AI Engineer — Watch on YouTube →

Gotchas & Caveats

The speaker maintains both MCP's Rust SDK and the open-source harness used in the demos, and works on ACP. He is candid about this and about the project's origins, but it is advocacy for a standard he is building.
Adoption is the whole argument and it is not yet established. His own point about MCP applies in reverse: a protocol's value is that everyone uses it, and ACP is not there yet.
The remote transport was described as just landing at the time of the talk, so treat it as new rather than proven.
The custom-method escape hatch is pragmatic and is also how protocols fragment; the promotion-to-standard path is stated as an intention, not a process.

Key Takeaways

What ACP covers. Clients establish a connection with a harness, negotiate capabilities, and open sessions. Within a session the client sends user messages; the agent replies with text, images or audio, tool-call notifications describing what was called and with what metadata, and permission requests so the client can show a "should I do this?" prompt. It is JSON-RPC and deliberately simple.
Where it came from. The editor companies — the Zed and JetBrains teams — proposed it, wanting to write one high-quality client implementation and drive any harness with it. It has stayed largely editor-neutral, which is why it generalises.
Extensibility with a purpose. Custom methods are namespaced with a leading underscore. The reasoning is good: if enough projects adopt it, you can see what everyone independently built the same way and promote those onto a standards track — the protocol shaped by usage rather than by committee.
Remote transport is the part that just landed. ACP had no remote story, so an HTTP transport with a WebSocket upgrade was specified. Same messages, same semantics, new transport.
The four movable pieces. Client, harness, tools (usually MCP) and model. With remote transports for all of them, any piece can live anywhere — all on one machine, or the harness remote and the client local, or only the model remote. That flexibility is the actual payoff, and it only exists once both halves of the protocol story have transports.
Demonstrated, not just described: two different clients — an editor and a terminal app — driving the same agent over stdio and getting the same streamed text, tool calls and summaries; then the same thing over the network, with the speaker noting he wrote the remote client the previous night.

What you can actually set up from this

Extracted from the video's own transcript — the specifics the original summary left out.

Reproducible steps

What ACP is
The Agent Client Protocol lets any client control any agent harness the way MCP lets any agent reach any tool. It came from the Zed and JetBrains teams, who wanted one editor implementation to drive many harnesses, and it is deliberately light on editor-specific features.
How a connection works
A client connects to a harness with a set of capabilities, opens sessions, and sends user messages. The agent replies with text, images or audio and with updates, including tool-call notifications (what was called and its metadata) and permission requests the client can show to the user.
Protocol design
Messages are JSON-RPC. It is extensible: custom methods start with an underscore, so harness and client projects can add their own and the community can see which become standard.
Local and remote
His demo ran over standard I/O: the Goose harness driven from the Zed editor, then the same agent driven from a terminal client from Poolside AI. A new HTTP transport with a WebSocket upgrade was just landing, so a client can reach an agent running in a container or the cloud with the same messages and libraries.
The four movable parts
He frames the agentic stack as client, harness, tools (often MCP) and model; with remote transports for each (ACP, MCP and model APIs), any of the four can run on a different machine.

Gotchas

The speaker works on Goose and is an MCP maintainer; the remote transport was described as just landing, not yet widely supported.
Several clients and harnesses (editors, desktop, mobile, terminal) already speak ACP; the video points to the ACP site for the current list.
Berd, covered in our other summary, talks to Claude Code, Codex and others through ACP adapters.