AI EngineerVideoSource Linked

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

ACP lets editors, terminals, and custom apps control compatible agent harnesses through one protocol, including remote sessions, tool updates, and permission requests.

AI Engineer · Sep 9, 2026

Open Source Open Markdown Open JSON

Source Summary

ACP uses **JSON-RPC** to connect client software with agent harnesses. Sessions carry prompts, streamed responses, tool-call updates, and permission requests; transports cover local standard I/O plus **HTTP and WebSocket** for remote agents.

Practical Implication

If you build an agent harness or its interface, consider putting ACP at that boundary. One implementation can then serve editors, terminals, mobile apps, or bespoke orchestration clients while MCP remains the agent-to-tool layer.

Agent-Ready Context

ACP uses **JSON-RPC** to connect client software with agent harnesses. Sessions carry prompts, streamed responses, tool-call updates, and permission requests; transports cover local standard I/O plus **HTTP and WebSocket** for remote agents.

If you build an agent harness or its interface, consider putting ACP at that boundary. One implementation can then serve editors, terminals, mobile apps, or bespoke orchestration clients while MCP remains the agent-to-tool layer.

Interoperability depends on adoption across both harnesses and clients. ACP also permits custom methods, so implementations may still diverge before commonly used extensions become part of the standard.

Connected Context · Feed7 Judgment

ACP defines a portability boundary between agent harnesses and their clients, distinct from both managed or embedded runtimes and MCP’s agent-to-tool boundary. It could let one harness serve several interfaces while preserving streamed state and permission requests. That narrows the integration problem to a shared session protocol, but adoption on both sides and unconstrained custom methods leave practical interoperability unresolved.

The Agent Behind the Curtain: Building the Oz Cloud Agent Platform — Safia Abdalla, WarpWarp’s separation of runtime, harness, artifacts, and orchestration reinforces ACP’s premise that a normalized boundary is needed to swap tools and interfaces without fragmenting workflows.github/copilot-sdkThe Copilot SDK supplies an embeddable agent runtime with permissions and tool use; ACP could standardize how clients communicate with such a harness rather than replacing its runtime responsibilities.Introducing the Agents APIThe managed Agents API confirms demand for persistent sessions, orchestration, and tool use, while ACP addresses a different concern: a client-facing protocol that could reduce dependence on any one harness interface.Use any Chat SDK adapter with eveBoth aim to let one agent operate through multiple clients, but eve normalizes messaging adapters whereas ACP standardizes the broader client-to-harness session, streaming, tool-update, and permission boundary.

Context Map

toolscoding#agent-sdks#cloud-agents#tool-use

Uncertainty

Interoperability depends on adoption across both harnesses and clients. ACP also permits custom methods, so implementations may still diverge before commonly used extensions become part of the standard.