Agent Client Protocol: LSP for AI Coding Agents
Remember when every text editor had to build custom integrations for every programming language? Syntax highlighting, autocomplete, go-to-definition — all reimplemented from scratch for each editor-language combination. Then LSP happened, and suddenly any editor could work with any language server through a single protocol.
We’re at that exact inflection point again, but this time with AI coding agents.
The Problem
Right now, AI coding agents and editors are tightly coupled. Want to use Claude Code in your IDE? Custom integration. Codex CLI? Another one. Each new agent-editor combination requires dedicated engineering effort. Agents work with a subset of editors, developers get locked into specific toolchains.
Sound familiar? It should. It’s the pre-LSP world all over again.
Enter ACP
The Agent Client Protocol (ACP) standardizes communication between code editors and coding agents. It’s built on JSON-RPC 2.0 — the same foundation as LSP — and defines a clean contract: agents implement a standard interface, clients (editors) speak the same language.
The communication model is straightforward:
- Initialize — negotiate versions and capabilities
- Session setup — create new or resume existing sessions
- Prompt turns — send user messages, receive streamed updates, tool calls, diffs
Agents can run locally as subprocesses (JSON-RPC over stdio) or remotely over HTTP/WebSocket. The protocol reuses JSON representations from MCP where possible, keeping the ecosystem coherent.
The Ecosystem Is Already Here
What surprised me most is how quickly adoption happened. As of March 2026:
Agents (30+): Claude Agent, Codex CLI, GitHub Copilot (public preview), Gemini CLI, Cline, Goose, Junie (JetBrains), OpenHands, Augment Code, Kiro CLI, and many more.
Clients (20+): Zed, JetBrains IDEs, VS Code (via extension), Neovim (CodeCompanion, avante.nvim), Emacs (agent-shell.el), Obsidian, and even Slack and Telegram bots.
This isn’t a paper spec waiting for adoption. It’s a working protocol with real implementations across the entire editor landscape.
Why This Matters
Three things make ACP significant:
1. Freedom of choice. Pick the best agent for the task, run it in the editor you prefer. No more “this agent only works in VS Code.”
2. Agent competition on merit. When the integration layer is commoditized, agents compete on what actually matters — code quality, speed, cost, context handling. Not on which editors they’ve built plugins for.
3. Composability. The protocol supports capabilities negotiation, custom extensions via _meta fields, and both stateful and stateless patterns. You can mix agents, swap them mid-project, or run multiple simultaneously.
The Bigger Picture
ACP sits alongside two other emerging protocols:
- MCP (Model Context Protocol) — standardizes how agents access tools and data sources
- A2A (Agent-to-Agent, Linux Foundation) — standardizes agent-to-agent communication
Together, they form a layered stack: MCP for tool access, ACP for editor-agent integration, A2A for multi-agent coordination. Each solves a distinct coupling problem.
What I’d Watch
- Remote agents support is still a work-in-progress — cloud-hosted agent scenarios need more spec work
- Security model for remote scenarios (authentication, permission scoping)
- Whether the protocol stays lean or accumulates complexity (LSP’s lesson: simple core, optional capabilities)
The spec is on GitHub, Apache 2.0 licensed, with official SDKs in TypeScript, Python, Rust, and Kotlin.
If you’re building anything in the AI coding space — agents, editor plugins, or developer tools — ACP is worth understanding now. The window for shaping it is still open.
Links: agentclientprotocol.com · GitHub · Agents list · Clients list