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

Source: [AI Engineer](https://www.youtube.com/watch?v=YkNulwcc5jk)  
Feed7 permalink: https://feed7.dev/p/acp-the-universal-remote-control-for-ai-agents-alex-hancock-block-1gvsj4j  
Published: 2026-09-09T16:00:03.000Z  
Trust: Source Linked (source_linked)

## Why Included

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

## 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 across 732 accumulated Signals:

ACP makes the client-to-harness boundary a candidate for standardization, complementing MCP’s agent-to-tool boundary. Against the prior embedded and cloud runtimes, it suggests interfaces need not be coupled to one harness: sessions, streaming, permissions, and remote transport can share a protocol. The portability claim remains conditional because adoption and custom methods can recreate fragmentation above the common core.

- [The Agent Behind the Curtain: Building the Oz Cloud Agent Platform — Safia Abdalla, Warp](https://feed7.dev/p/the-agent-behind-the-curtain-building-the-oz-cloud-agent-platform-safia-074nn9s) — ACP provides a concrete protocol for the normalization boundary that Warp’s harness-neutral platform treats as necessary for swapping runtimes and interfaces.
- [github/copilot-sdk](https://feed7.dev/p/copilot-sdk-0vwjjou) — The Copilot SDK exposes one agent runtime for embedding, while ACP proposes a standard client boundary that could reduce interface coupling to any single runtime SDK.
- [Expanding Managed Agents in Gemini API: background tasks, remote MCP and more](https://feed7.dev/p/expanding-managed-agents-gemini-api-1idue29) — Gemini’s remote MCP support illustrates the separate agent-to-tool layer; ACP addresses how clients communicate with the harness managing such an agent.
- [Use any Chat SDK adapter with eve](https://feed7.dev/p/eve-chat-sdk-channel-03h905c) — Both aim to let one agent serve multiple interfaces, but eve normalizes messaging adapters whereas ACP standardizes the more general session and permission exchange with a harness.

## Context Map

- Layer: tools
- Domains: coding
- Topics: 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.

## Agent Instruction

Use this item as source-backed context. Do not invent claims beyond the linked source. If this item conflicts with another source, call out the conflict.