ACP: The LSP Moment for AI Coding Tools, Ending Agent Lock-In
The Agent Client Protocol (ACP) is doing for AI coding agents what LSP did for programming languages — decoupling editors from agents with a single standard. This article breaks down ACP's architecture, ecosystem, and what it means for developers.
The Tower of Babel Problem in Coding Tools
Developers in 2026 face a strange dilemma: AI coding tools are unprecedentedly powerful, but they don't talk to each other.
You're writing code in Cursor, and you want to invoke Claude Code for a cross-file refactor — not possible. You're using Aider in the terminal, and you want to sync results back to your IDE for Copilot to continue — also not possible. Every tool is an island. Agent-to-editor interfaces are proprietary protocols, and every combination requires custom integration.
This is the same problem the programming language tooling ecosystem faced before 2015. Back then, every editor had to separately implement autocomplete, go-to-definition, and find-references for every language — until the Language Server Protocol (LSP) decoupled editors from language servers with a single standard. Today, you can write Rust in VS Code, TypeScript in Vim, and Python in Emacs, all with the same level of language intelligence.
ACP (Agent Client Protocol) aims to be LSP for the AI coding era.
What Is ACP
ACP standardizes communication between code editors and coding agents. It entered public view in June 2026 with the release of Devin Desktop, and is currently stewarded by Cognition with an open community model.
The core idea is elegantly simple:
- Agent side: any ACP-compliant agent (Claude Code, Devin, Aider, etc.) works with any compatible editor — no per-editor custom integration required
- Editor side: any editor supporting ACP (VS Code, JetBrains, Zed, etc.) gains access to the entire ecosystem of ACP-compatible agents
The LSP analogy is precise. Before LSP: N editors × M languages = N×M integrations. After LSP: one language server serves all editors. ACP solves the same for agents: N editors × M agents → one protocol to rule them all.
Technical Architecture
ACP is built on JSON-RPC 2.0 and reuses JSON representations from MCP where applicable. In local mode, agents run as subprocesses of the editor, communicating over stdio. Remote mode supports HTTP/WebSocket for cloud-hosted agent scenarios — though remote support is still in active development.
The communication model revolves around three core concepts:
Sessions: When a user initiates an agent interaction, the editor creates an ACP session. Within the session, the agent has access to file read/write, terminal execution, and search capabilities — all governed by the editor's permission model.
Tools: Agents interact with the editor through standardized tool interfaces — reading files, applying changes, running commands, displaying diffs. The editor handles diff rendering, confirms dangerous operations, and manages permissions.
Messages: Both user messages and agent responses use a unified message format. The default text format is Markdown, balancing rich-text expressiveness with cross-editor compatibility.
ACP includes native support for agent-specific UX: diff display, inline suggestions, file lists, and progress reporting — defined at the protocol level rather than hacked through Markdown conventions.
Why ACP Matters More Than You Think
MCP (Model Context Protocol) solves "how models get context" — editors expose codebases, documentation, and infrastructure to models through MCP. It has been very successful, with Anthropic leading and a mature ecosystem.
But MCP has a boundary it does not cross: it governs the model←editor information flow, not the agent→editor action flow. You used Claude Code to complete a refactor and want to send the diff back to your editor for review — that's not MCP's domain.
ACP fills exactly this gap. It governs the agent→editor action channel: how agent modifications are displayed, confirmed, and merged. To put it simply:
- MCP = what the model sees
- ACP = what the agent can do, and how results are presented
They are complementary, not competing. A complete AI coding protocol stack should use both.
Ecosystem Status
ACP is young, but adoption has exceeded expectations. Current public supporters and integrators include:
- Editors: JetBrains (full family), Google Antigravity, GitHub (for Copilot integration), Zed
- Agents: Devin Local (native ACP support), Claude Agent (via Devin Desktop's ACP bridge), Aider (community adapter in progress)
Devin Desktop is ACP's first full production deployment. Its Agent Command Center lets you manage and run multiple ACP-compatible agents simultaneously within a single editor — you initiate tasks in the editor, agents execute in the background, and results return as diffs.
This signals a shift in AI coding tools from "whose agent is stronger" to "whose agent orchestration is better." Individual agent capability is being leveled by model improvements; how to make multiple agents work together is the new differentiator.
What This Means for Developers
The most immediate benefit of ACP for everyday developers: you are no longer locked into any single tool's ecosystem.
Today, if you go deep on Cursor's Agent mode, your workflow is coupled to Cursor — switching editors carries a high cost. Similarly, if your muscle memory is in Claude Code's terminal workflow, migrating to an IDE is painful.
Once ACP matures, you can:
- Initiate tasks in VS Code, choosing different agents for different jobs — Claude Code for refactoring, Copilot for code review, Aider for documentation
- Write code in JetBrains but invoke Cursor's Composer Agent for UI-layer changes
- Pull a diff produced by a terminal agent seamlessly into your editor for review and merge
Editors go back to being editors. Agents go back to being agents. Developers freely choose the best tool for each task.
Risks and Challenges
ACP is not without concerns.
First, governance. ACP is currently stewarded by Cognition. While nominally open, a de facto standard controlled by a single commercial entity raises ecosystem health questions. LSP succeeded in large part because of Microsoft's open posture — ACP needs to prove the same degree of openness.
Second, protocol stability and fragmentation risk. ACP is early-stage, and API changes are frequent. If different implementations develop compatibility divergences, a fragmented ACP could be worse than no standard at all.
Third, the security boundary. ACP grants agents broader editor operation rights. The standardized permission model must have sufficiently fine granularity — a code review agent should not be able to silently delete files.
Closing Thoughts
ACP is doing something important: building a public layer for AI coding tool interoperability.
The history of LSP is instructive. When LSP launched in 2016, many dismissed it as "just a protocol." Looking back a decade later, LSP may be one of the most impactful technical infrastructures on daily developer experience — it transformed editor choice from "forced choice" to "free choice."
ACP has the chance to play the same role in the AI coding tool space. If it succeeds, developers in 2028 may forget there was ever a "Cursor vs. Copilot" zero-sum debate — because they can invoke any agent from any editor.
That's what tools should look like.