# ACP: The Protocol That Lets You Use Any Agent in Any Editor — and What Comes Next There's a pattern emerging in how developers work with AI coding agents — and a protocol quietly standardizing it. Most AI coding tools are vertically integrated: this agent, in this editor, by this company. You switch tools, you start over. Every new agent means a new integration, a new workflow, a new set of limitations. **ACP (Agent Client Protocol) is the fix for that.** It's an open standard for connecting any coding agent to any editor — and it's already shipping in the tools most developers use every day. ## What ACP Actually Is Agent Client Protocol is an open standard for connecting code editors to coding agents. Think of it as [LSP](https://microsoft.github.io/language-server-protocol/) (Language Server Protocol) but for AI agents instead of language servers. LSP was the protocol that let any language server (TypeScript, Go, Rust, Python) work in any editor (VS Code, Vim, Emacs, JetBrains) without custom integrations. Before LSP, every editor had to build native support for every language. After LSP, you implemented the protocol once and got every editor for free. ACP does the same thing for AI coding agents: - Implement ACP as an **agent** → works in every ACP-compatible editor - Implement ACP as an **editor** → gets access to every ACP-compatible agent Built by **JetBrains** and **Zed**, the ACP registry already includes Claude Code, Gemini CLI, Codex, GitHub Copilot CLI, OpenCode, and more. JetBrains plans to bring ACP support to their entire IDE lineup — IntelliJ IDEA, PyCharm, WebStorm, and the rest. ## How It Works Today: stdio Transport Right now, ACP uses **stdio** as its transport. The agent runs as a sub-process of the editor, communicating via JSON-RPC over standard input/output. Fast, private, no network involved. This is the default for agents like Claude Code running on your machine. When you open Zed or a JetBrains IDE and invoke an ACP-compatible agent, the editor spawns it as a local process and talks to it directly. It's simple and it works well. The editor stays in control; the agent stays scoped to the task. ## What's Coming: Streamable HTTP Transport The ACP spec includes a [Streamable HTTP transport](https://agentclientprotocol.com/protocol/transports#streamable-http) — currently a proposal. When finalized, it will let agents expose a single HTTP endpoint instead of running as a sub-process. The editor connects over HTTP; the server streams events back via Server-Sent Events. This is a meaningful shift. HTTP transport means: - Agents can run remotely — on a server, in the cloud, or on a different machine - Editors can connect to agents they didn't spawn - The same agent can serve multiple clients It's the foundation for using your local machine as a remotely-accessible coding agent endpoint — reachable from anywhere, running in your real environment with your actual codebase. ## The Opportunity: Delegating to Your Local Machine While Away Here's the combination worth thinking through now, even as the HTTP transport matures. Your local dev machine has: - Your entire codebase checked out - All your credentials, configs, and tooling - Direct file system access — no cloud sync lag - Persistent state across sessions A cloud agent working on a copy of your repo isn't the same as an agent working in your actual environment. The local machine is where the real context lives. Today, tools like **AgentRQ** already bridge this gap. You run Claude Code locally (stdio, via ACP or directly), connect it to AgentRQ, and you have a task channel you can send work to from anywhere — your phone, a browser, an API. The agent runs on your machine; you control it remotely. When ACP's HTTP transport ships, this pattern gets standardized at the protocol level. Any ACP-compatible editor will be able to connect to any remote ACP agent — including one running on your own machine. ## What This Unlocks **Brief tasks from your phone.** You remember a bug on the way to a meeting. Instead of writing a note to deal with it later, you send it to your local Claude Code instance via AgentRQ. By the time you're back, the fix is drafted and waiting for review. **Run long jobs while away.** A refactor that takes 40 minutes doesn't need you staring at a terminal. Brief it, leave, come back to results. **Headless execution.** Tools like [acpx](https://github.com/openclaw/acpx) — a headless CLI for ACP sessions — let you send tasks programmatically to any ACP-compatible agent. No terminal UI, no interactive prompt. One command, structured output. This is how you wire ACP agents into pipelines and automation systems. **Multi-agent orchestration.** Because ACP standardizes the interface, one agent can dispatch tasks to another. Your orchestrator sends a coding task to a Claude Code ACP session, receives the diff, applies it, and moves on. The protocol handles the communication; you handle the judgment. ## The Missing Layer: Human-in-the-Loop There's one thing ACP doesn't solve on its own. When your agent is running on your local machine and you're somewhere else, how do you stay in control? How do you know when it needs a decision? How do you approve a risky change before it's committed? Headless execution is powerful, but it's also opaque. Without a feedback channel, you're flying blind. This is where **AgentRQ** comes in. AgentRQ connects Claude Code to a persistent task channel — one you can monitor and respond to from your phone, from a browser, from anywhere. When your local Claude Code hits a decision point, it surfaces the question to you as a task. You reply with your answer. The agent continues. The result: your local machine is running real work in the background, with your judgment injected at exactly the moments that matter. ## How to Set It Up Today You don't need to wait for HTTP transport to start working this way. 1. **Run Claude Code locally** — it's an ACP-compatible agent, works via stdio today 2. **[Connect it to AgentRQ](/docs/getting-started)** — 60 seconds, gives you a remote task channel 3. **Brief tasks from anywhere** — phone, browser, or API 4. **The agent works; you approve** — human-in-the-loop without being present ACP standardizes how agents and editors talk to each other. AgentRQ is the channel that lets you talk to the agent. Together, the picture is: your machine does the work while you're somewhere else, and you stay in control. As HTTP transport in ACP matures, this pattern will get easier to set up and more broadly compatible. The protocol is laying the groundwork. The workflow is available now.