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.





