Agent Client Protocol (ACP): How it works
An open editor↔coding-agent wire — and how a local broker speaks it without becoming an IDE or an orchestrator.
The short answer
Agent Client Protocol (ACP) is an open protocol that standardizes how code editors and other clients talk to coding agents. Locally, agents often run as a subprocess and communicate with JSON-RPC over stdio — similar in spirit to how LSP standardized language servers for editors. (agentclientprotocol.com↗)
Scout is a local-first agent broker. It includes an Agent Client Protocol client adapter for subprocess coding agents: start a session, send a prompt, and take session updates, including permission requests. That adapter is not an ACP server. It is not BeeAI's Agent Communication Protocol, which is a different protocol that shares the initials. Full ACP conformance is not claimed. The boundary list is the protocol readiness report. Scout is not an ACP IDE, not the protocol steward, and not an orchestrator.
| Layer | Job |
|---|---|
| ACP | Editor/client ↔ coding-agent wire |
| MCP | How an app or agent connects to tools, data, and prompts |
| Scout | Local broker under agents you already run — discover, address, steer, durable records |
Google’s Agent2Agent (A2A) protocol is a different adjacency: independent agents across vendors. Scout’s A2A surface is a local pilot for card discovery and text tasks, and it does not claim full A2A conformance. Full three-way map: ACP vs A2A vs MCP.
After this page you should be able to read “Speaks ACP,” “Custom ACP backend,” or “ACP in Zed” and tell an editor client from a broker adapter. “Speaks ACP” is a shorthand. The accurate Scout claim is the client adapter above, not full conformance.
What ACP is
AI coding agents and editors used to be tightly coupled: every editor built custom integrations for every agent, and agents implemented editor-specific APIs. ACP’s job is to break that lock-in — one protocol so compatible agents work with compatible editors, and both sides can innovate independently. (Introduction↗)
The mental model is LSP-shaped: the user stays primarily in the editor (or client), and reaches out to agents for specific work. The protocol reuses JSON shapes from MCP where it can, and adds agentic UX types (for example diffs). User-readable text defaults to Markdown.
Local shape: subprocess + JSON-RPC over stdio
For local agents, ACP’s common shape is: the agent runs as a subprocess of the editor, talking JSON-RPC over stdio. That is the wire you hear about in Grok ACP / Kimi ACP style terminals and in IDE “bring your own agent” flows.
Remote / cloud ACP
ACP is also aimed at remote agents (HTTP or WebSocket). Full remote support is called out as work in progress on the official intro — Scout does not ship a cloud-ACP product from that line. See current ACP docs rather than pinning fragile version numbers in evergreen copy.
Who uses the noun today (qualitative)
- Zed ACP↗ — bring-your-own agent into Zed; Apache-licensed open protocol; ecosystem of editors and agents; JetBrains collaboration widely reported
- JetBrains IDEs and other editors on the ACP landing / registry story
- Happier Custom ACP↗ — configurable ACP-compatible CLI backends inside Happier’s AI backends settings
- Scout — ACP client adapter for subprocess coding agents; not an ACP server; full conformance not claimed
- Grok / Kimi Code — listed on openscout.app as
grok-acp (stdio)andkimi-acp (stdio)harnesses among a broader set
Same protocol noun can power different products. That is the point of this page.
What ACP is not
Not MCP. MCP standardizes how an application or agent connects to tools, data, and prompts. ACP standardizes the editor/client ↔ coding-agent session. Many stacks use both. Scout’s manifest also lists mcp among broker transports and preferred MCP tools (whoami, ask, messages_send, …) — that is Scout exposing broker ops over MCP, not “ACP equals MCP.” (scout.json↗)
Not Google A2A. Google’s Agent2Agent protocol targets interoperability between independent agents (discovery cards, tasks, cross-vendor collaboration). ACP targets editor/client integration with coding agents. Do not treat “agent-to-agent” marketing as the same noun as ACP. Map page: ACP vs A2A vs MCP.
Not every product that says “ACP.” On this site and in Zed/JetBrains materials, ACP means Agent Client Protocol — the editor/client ↔ coding-agent wire. Other vendors have used “ACP” for agent↔agent communication (sometimes folded toward A2A). If a post says ACP and means agent-to-agent, that is a naming collision — not Scout’s definition.
Not a multi-agent orchestrator framework. CrewAI / LangGraph / AutoGen-style tools race a swarm inside a framework. Scout is not that either — see Scout vs Agent Orchestrators.
Not “Scout invented ACP.” ACP was created and grown in the Zed + community ecosystem. Scout speaks it as a join path onto a local broker.
How Scout uses ACP
Scout’s job remains: sit underneath agents you already run — one place to see, steer, and remember them. It is not an orchestrator, and “speaks ACP” is narrower than it sounds: a client adapter for subprocess agents, not an ACP product and not lock-in insurance. (openscout.app↗)
Concrete today: among harnesses Scout launches or reaches — Claude Code, Codex, Cursor, Grok, Kimi Code, OpenCode, pi (Hermes via plugin) — Grok and Kimi Code are called out as ACP (stdio) shaped.
On the broker, peers are addressable; coordination is kept as durable records (messages, invocations, flights, deliveries, bindings) instead of terminal scrollback. Surfaces: the CLI is the complete runtime (+ local web dashboard). Mac menu-bar and iPhone are optional; iPhone is beta when mentioned. Early v0.x high-trust local developer pilots — not enterprise, compliance, or untrusted multi-tenant yet.
ACP harnesses vs host packages
Two join paths, not one:
| Path | What it is |
|---|---|
| ACP client adapter | Grok ACP and Kimi ACP are launched as subprocess sessions. They become broker peers through Scout, not through ACP itself |
| Host packages | Thin packages for claude, codex, cursor, pi, hermes that add Scout commands inside those agents without forking the harness runtime |
Not every Scout harness is ACP-only. Protocol-open join is one lane; host packages are another.
Scout is also not a worktree/PR factory (Scout vs Conductor), not Claude Code’s Agent View (Claude Agent View vs cross-harness), and not a tmux dashboard.
ACP on Scout vs ACP in an IDE or inbox app
| Zed / JetBrains (ACP client UX) | Happier Custom ACP | Scout | |
|---|---|---|---|
| Job | Editor talks to coding agents over ACP | Launch/select ACP-compatible CLI backends in a control-room style product | Local broker: addressable peers, durable records, cross-harness steering |
| You live in… | The IDE | Happier’s session / backend picker | CLI (+ optional Mac / iPhone beta) over a local broker |
| Same protocol? | Yes — ACP client in the editor | Yes — ACP-compatible CLIs | Client adapter only; not an ACP server; conformance not claimed |
Category clarification, not “Scout wins ACP.” If you only need one agent inside an ACP IDE, ACP-in-editor may be enough for that job. Scout is for when coordination spans harnesses and you want a local broker underneath.
When you care about ACP on Scout
- You run or plan Grok / Kimi ACP (or other ACP agents) alongside Claude Code, Codex, Cursor, and want one
scout whopane - You want protocol-open join paths without locking coordination inside a single IDE
- Soft: solo ACP-in-Zed with one agent may not need Scout at all
Practical peer messaging and handoffs after agents are addressable: Agent-to-agent on a local broker. (Flights-with-receipts and agents.md discovery pages are in a later ship batch.)
How to try Scout
If you already run ACP-capable coding agents — or mix them with Claude Code, Codex, Cursor, and others — and want one local place to see peers and hand off work:
Then: scout who to see what the broker can see.
ACP literacy helps you read the labels. The install path is still the CLI broker.
FAQ
What is the Agent Client Protocol (ACP)?
ACP is an open protocol that standardizes how code editors and other clients talk to coding agents. Locally, agents often run as a subprocess and communicate with JSON-RPC over stdio — similar in spirit to how LSP standardized language servers for editors.
Is ACP the same as MCP?
No. MCP standardizes how an application or agent connects to tools, data, and prompts. ACP standardizes the editor/client ↔ coding-agent session. Many stacks use both. For a three-way map including Google A2A, see ACP vs A2A vs MCP.
Is ACP the same as Google’s A2A protocol?
No. Google’s Agent2Agent (A2A) protocol targets interoperability between independent agents (discovery cards, tasks, cross-vendor collaboration). ACP targets editor/client integration with coding agents. Scout’s ACP adapter and its A2A pilot are separate surfaces. Neither is a full conformance claim.
What does “Scout speaks ACP” mean?
Treat the phrase as a shorthand. The accurate claim is an Agent Client Protocol client adapter for subprocess coding agents. Scout does not expose an ACP server, does not implement BeeAI’s Agent Communication Protocol, and does not claim full ACP conformance. Addressable peers and durable handoffs are the local broker, not the ACP wire. Scout is not an ACP editor.
Is Scout an orchestrator?
No. Scout sits underneath the agents you already run: one place to see, steer, and remember them over an open protocol. It is not a framework that races a swarm inside its own runtime.
Does Claude Code speak ACP?
Claude Code typically joins Scout through a host package (Claude Scout) and other documented paths — not as claude-acp (stdio). The explicit ACP-stdio examples on openscout.app are Grok and Kimi Code.
Which Scout harnesses are ACP-shaped today?
On openscout.app, Grok is listed as grok-acp (stdio) and Kimi Code as kimi-acp (stdio). Other harnesses (Claude Code, Codex, Cursor, OpenCode, pi; Hermes via plugin) join through host packages or other bridges — not every harness is ACP-only.
How do I install Scout?
Install the CLI with curl -fsSL https://openscout.app/install | sh, then run scout setup and scout doctor. Mac and iPhone apps are optional surfaces over the same local broker; the iPhone app is in beta.
Soft CTA
Protocol first, then the broker — if that matches how you already run agents:
More: openscout.app↗ · agents.md↗ · docs↗ · install↗ · manifest↗