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

AI harnesses lack a standardized way for client software to control them, and the Agent Client Protocol (ACP) offers an open standard solution analogous to h...

By Sean Weldon

ACP: The Universal Remote Control for AI Agents

Abstract

Agentic AI systems increasingly rely on harnesses to orchestrate models, tools, and conversational state, yet the client software that drives these harnesses has remained fragmented and vendor-specific. This synthesis examines the Agent Client Protocol (ACP), an open standard proposed by editor vendors Zed and JetBrains, as a solution to this fragmentation, drawing on demonstrations presented by Alex Hancock of Block involving the Goose agent harness. The analysis covers ACP's JSON-RPC mechanics, session and permission semantics, extension conventions, and its newly specified remote transport. Findings indicate that a single harness implementation can be controlled interchangeably by an editor, a terminal client, and a custom network client without modification. The principal implication is a four-component agentic stack - client, harness, tools, model - whose elements can now be independently distributed across machines, suggesting a coming marketplace of interchangeable, competing client applications.

1. Introduction

The rapid growth of coding agents and general-purpose AI assistants has exposed a structural inefficiency in the agentic software stack. An agent harness is the runtime layer responsible for managing an agent's operational loop: assembling context, invoking a model, dispatching tool calls, and returning results to a user. Every harness requires a client - the user-facing surface through which a human issues instructions and observes the agent's progress. Historically, harness vendors have built bespoke, tightly coupled clients, and in the worst case only a single client application is capable of controlling a given harness.

This asymmetry has been described through analogy to the early web: requiring a distinct browser for every website would have been unworkable, yet this is effectively the situation many AI harnesses impose on client developers today. The central thesis examined here is that AI harnesses require a standardized control interface in the same way that tool invocation was standardized by the Model Context Protocol (MCP), and that ACP - characterized as "a universal remote control for AI" - supplies this missing layer.

This analysis proceeds as follows. Section 2 situates ACP relative to MCP and establishes the coordination problem it addresses. Section 3 examines ACP's origins, protocol mechanics, and demonstrated interoperability across three distinct client implementations against a single harness. Section 4 distills technical findings, including a newly specified remote transport. Section 5 discusses the implications of a decomposable, four-part agentic stack, and Section 6 concludes with practical takeaways.

2. Background and Related Work

MCP established a standard interface by which agents invoke external tools and take action in the world. Its importance is attributed not to any particular technical elegance but to adoption itself: "the most powerful thing about MCP is not anything about MCP itself, but it's that everyone uses MCP." This framing recasts agentic interoperability as fundamentally a coordination problem - value accrues from convergence on a shared interface rather than from the specific design choices within it.

MCP, however, addresses only one direction of communication: agent-to-tool. No equivalent standard existed for the inverse relationship - how a client instructs a harness and receives structured updates in return. This gap is the intellectual origin point for ACP, and it is the gap this synthesis treats as its central object of study.

3. Core Analysis

3.1 Origins and Design Philosophy

ACP did not originate from model providers or harness vendors but from editor companies. Zed and JetBrains jointly proposed the standard, motivated by a straightforward economic logic: an editor vendor would rather invest in one high-quality client implementation capable of controlling any compliant harness than maintain bespoke integrations per harness. The Goose project, an open-source harness, subsequently recognized broader applicability, noting that ACP is comparatively neutral and free of editor-specific assumptions, meaning it "can be spread to a wider range of client software" beyond its original design context.

Structurally, ACP communicates via JSON RPC messages. Extensibility is handled through a convention of underscore-prefixed custom methods, which allows harness and client teams to experiment with new functionality ahead of formal standardization - a pattern that mirrors how experimental features are often incubated in other protocol ecosystems before ratification.

3.2 Protocol Mechanics

ACP establishes a connection between a client and an agent harness, during which each side declares a set of supported capabilities. Within an established connection, sessions allow a client to send user messages to the agent. Agents respond with a range of content types - text, images, audio - or status updates reflecting the ongoing state of the interaction.

Two mechanisms are particularly consequential for practical usability. First, tool call notifications communicate what tool was invoked and associated metadata, giving the client visibility into the agent's actions as they occur rather than only after completion. Second, permission requests can be transmitted over the protocol, allowing a user to approve or deny a proposed action before it executes. Together these mechanisms give client applications a structured, real-time view into agent behavior without requiring bespoke, harness-specific integration work.

3.3 Demonstrated Interoperability

The practical claims of ACP were substantiated through a sequence of live demonstrations. First, the Zed editor was connected to the Goose agent harness via ACP over standard IO, and a project query was issued and answered within the editor interface. Second, a terminal-based client from Poolside AI was connected to the identical Goose harness and produced an equivalent interaction experience. Because both clients drove the same underlying harness implementation without modification to that harness, this pairing constitutes direct evidence of client-harness interoperability rather than a merely theoretical claim.

A third demonstration extended this further: a custom client was live-coded and connected to Goose remotely over a network, using the same protocol messages as the local demonstrations. This established that ACP's semantics are transport-agnostic in practice as well as in specification, a point developed further in Section 4.

4. Technical Insights

Several implementation-relevant findings emerge from this analysis:

5. Discussion

The decomposition of the agentic stack into four independently placeable components - client, harness, tools, model - carries implications beyond simple deployment flexibility. It suggests an architectural shift analogous to the client-server disaggregation seen in web infrastructure: once any component can be relocated or substituted without breaking the others, competitive pressure can concentrate on the component offering the most differentiated value, rather than being diluted across vertically integrated, single-vendor stacks.

This is expected to manifest as an ecosystem effect. As the number of ACP-compliant clients and agent servers grows - spanning editors, desktop applications, mobile applications, and terminal-based tools - opportunities emerge for personal clients, business-domain-specific clients, and white-label clients that function across multiple harnesses. Because users are not locked into a single client per harness, they can, in effect, "vote with their feet," a competitive dynamic anticipated to "drive up the user experience of using AI" through market pressure rather than centralized design mandates.

An open question, not resolved within the source material, concerns governance and long-term stewardship of the ACP specification as adoption broadens beyond its editor-vendor origins - particularly whether the underscore-extension mechanism will scale cleanly as more independent teams contribute experimental features.

6. Conclusion

This synthesis has examined ACP as a structural response to the fragmentation of AI agent client software, demonstrating through live cross-client tests that a single harness implementation can be driven interchangeably by an editor, a terminal application, and a custom remote client. Combined with a newly specified remote transport, ACP completes a set of standardized, remotely operable interfaces alongside MCP and model APIs, enabling a fully decomposable four-part agentic stack. The practical takeaway for engineering teams is that investment in harness-specific client integrations may be increasingly unnecessary; adopting ACP allows client effort to generalize across the growing ecosystem of compliant agent harnesses, and vice versa for harness developers seeking broader client reach.

Sources

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub