The hype around AI coding agents is at an all-time high. Claude Code, GitHub Copilot, Cursor, Windsurf, Augment β the list grows every month. But there is a fundamental problem underneath: every agent-editor combination requires custom integration work.
The Agent Client Protocol (ACP) aims to fix this the same way the Language Server Protocol (LSP) fixed language tooling a decade ago.
The Problem: Tight Coupling Everywhere
Right now, AI coding agents and editors are tightly coupled. Each editor must build custom integrations for every agent they want to support, and agents must implement editor-specific APIs to reach users.
This creates several problems:
- Integration overhead β every new agent-editor combination requires custom work
- Limited compatibility β agents work with only a subset of available editors
- Developer lock-in β choosing an agent often means accepting their available interfaces
If you have used LSP, you know exactly how powerful standardization can be. Before LSP, every editor needed its own language plugin for every language. After LSP, a single language server works everywhere. ACP wants to do the same for AI agents.
How ACP Works
ACP defines a standard interface for communication between AI agents and client applications (editors/IDEs). The architecture follows three key principles:
- MCP-friendly β built on JSON-RPC, reuses MCP types where possible so integrators do not need to build yet another representation for common data types
- UX-first β designed to solve the UX challenges of interacting with AI agents, with enough flexibility to render the agentβs intent clearly
- Trusted β ACP works when you are using a code editor to talk to a model you trust, with controls over the agentβs tool calls
Local and Remote Agents
ACP supports both deployment models:
- Local agents run as sub-processes of the code editor, communicating via JSON-RPC over stdio
- Remote agents can be hosted in the cloud or on separate infrastructure, communicating over HTTP or WebSocket
For local agents, when the user connects, the editor boots the agent sub-process on demand. All communication happens over stdin/stdout. Each connection supports several concurrent sessions, so you can have multiple trains of thought running simultaneously.
MCP Integration
ACP integrates natively with the Model Context Protocol (MCP). The code editor forwards user-configured MCP server configurations to the agent, allowing the agent to connect directly to MCP servers.
The editor can also export its own MCP-based tools. Since agents may only support MCP over stdio, the editor provides a small proxy that tunnels requests back to itself. This means the agent gets access to:
- File system operations
- Terminal commands
- Editor-specific tools (selection, diagnostics, symbols)
- User-configured external MCP servers
Key Protocol Features
Sessions and Modes
ACP supports rich session management:
- Session creation and loading β persist conversations across editor restarts
- Session listing β discover existing sessions
- Session config options β flexible configuration selectors per session
- Session modes β switch between different agent operating modes (e.g., autonomous vs. interactive)
- Session forking β branch a conversation into parallel explorations
Agent Plans
Agents can communicate their execution plans to the editor before taking action. This gives the developer visibility into what the agent intends to do β and the ability to approve, modify, or reject steps before execution.
Content and Diffs
The protocol includes custom types for agentic coding UX elements like displaying diffs. The default format for user-readable text is Markdown, which allows rich formatting without requiring the editor to render HTML.
Slash Commands
Agents can advertise available slash commands to clients, providing a discoverable interface for agent capabilities beyond free-form conversation.
Tool Calls
ACP defines how agents report tool call execution, including requesting permissions from the user. This is the trust layer β the developer stays in control of what the agent can actually do.
The ACP Registry
The ACP ecosystem includes an Agent Registry β the easiest way to find and install ACP-compatible agents. Think of it as a package manager for coding agents. The registry has been stabilized and is part of the core protocol.
Libraries and SDK Support
ACP provides official libraries for building agents and clients:
- Python β for Python-based agents
- TypeScript β for VS Code extensions and web-based editors
- Rust β for high-performance agents
- Java and Kotlin β for JetBrains ecosystem integration
- Community libraries β growing ecosystem of third-party implementations
Why This Matters for the Industry
ACP is significant because it addresses the same fragmentation problem that LSP solved:
| Before LSP | Before ACP |
|---|---|
| Every editor needed custom language plugins | Every editor needs custom agent integrations |
| Language tooling was editor-locked | Agent capabilities are editor-locked |
| Developers chose editors based on language support | Developers choose editors based on agent support |
With ACP:
- Agent developers build once, work everywhere
- Editor developers support one protocol, gain access to all compatible agents
- Developers choose their editor and agent independently
Getting Started
If you are building an AI coding agent or an editor integration:
- Read the ACP introduction
- Review the architecture overview
- Pick your SDK library (Python, TypeScript, Rust, Java, Kotlin)
- Browse the ACP Registry for existing agents
The project uses an open governance model with Requests for Dialog (RFDs) β a structured process for proposing protocol changes, similar to RFCs in the IETF world.
My Take
As someone who works with AI agents in production and helps enterprises build AI-ready platforms, I see ACP as a critical piece of the puzzle.
The current state of agent-editor integration reminds me of the early days of container orchestration β before Kubernetes standardized the interface, every platform had its own deployment model. ACP could do for AI coding agents what Kubernetes did for containers: provide a common abstraction that lets the ecosystem innovate on both sides independently.
The key question is adoption. LSP succeeded because Microsoft open-sourced it and VS Code demonstrated the value. ACP needs similar momentum β a major editor and a major agent both committing to the standard publicly.
Related Posts
- ZenML and Kitaru: Building Durable AI Agents
- Clemens Scholz: AI as Your Second Brain
- Advancing Platform Engineering on AI, K8s, and the Product Mindset
- Content Credentials: How C2PA Is Building Trust in the Age of Generative AI
About the Author
I am Luca Berton, AI and Cloud Advisor. I help enterprises adopt AI tooling and build developer-friendly platforms. Book a consultation.