GitHub Copilot joined the Agent Client Protocol registry on November 3. That means you can now run Copilot inside JetBrains Air—without the Copilot plugin—by selecting it as an ACP agent. That is one headline. The bigger story is that ACP has quietly crossed a threshold: 40+ agents, 19+ editors, and now GitHub’s flagship AI tool. If you have been treating ACP as a Zed-specific experiment, it is time to reconsider.
The LSP Moment for AI Coding Agents
The Language Server Protocol solved a combinatorial problem in tooling. Before LSP, every language needed a bespoke plugin per editor — Go had a plugin for VS Code, another for Vim, another for Emacs, all maintained separately and all subtly different. After LSP, one language server works everywhere. The protocol standardized the conversation; editors and language tools both spoke to it.
ACP is the same idea applied to AI coding agents. Before ACP: Copilot had a plugin for VS Code, a separate plugin for JetBrains, partial or no support in Zed. Each required separate engineering. After ACP: Copilot CLI speaks the protocol, and any ACP-compatible editor — Zed, JetBrains IDE, Neovim, Emacs — connects to it without a custom plugin.
ACP originated at Zed Industries in August 2025. JetBrains joined in October 2025, co-developing the spec and folding in its own internal Junie protocol effort. The repository now lives under the vendor-neutral agentclientprotocol organization — Apache 2.0, open governance, official SDKs for Python, TypeScript, Rust, Kotlin, and Java.
ACP and MCP Are Not Competing — They Are Different Layers
The most common confusion in developer discussions is treating ACP and MCP as alternatives. They are not. They answer different questions in opposite directions and belong to different layers of the same stack.
MCP (Model Context Protocol) is agent-to-tools: it defines how an AI agent calls external tools, databases, and APIs. The agent is the MCP client; the tool server is the MCP server. The question MCP answers is “what can the agent access?”
ACP is editor-to-agent: it defines how an IDE talks to a coding agent. The editor is the ACP client; the agent is the ACP server. The question ACP answers is “where does the agent live in my editor?” In a complete agentic setup, your agent speaks both simultaneously: it is an ACP server to your IDE and an MCP client to its tools. A full breakdown of the ACP/MCP distinction is worth reading if you are building in this space.
| ACP | MCP | |
|---|---|---|
| Connects | Editor to Agent | Agent to Tools |
| Direction | IDE asks, agent answers | Agent asks, server answers |
| Key question | Where does the agent live? | What can the agent access? |
| Competing? | No — complementary layers of the same stack | |
The Registry Has Reached Critical Mass
The official ACP registry lists 40+ agents as of October 2026: Claude Agent, Codex CLI, Gemini CLI, GitHub Copilot, Cursor, Qwen Code, Kimi CLI, Goose, OpenCode. On the editor side: Zed, every JetBrains IDE, Neovim, Emacs, and VS Code via extension.
The practical implication is that your IDE choice and your agent choice are now decoupled. You can run the same Copilot subscription in JetBrains, Zed, and Neovim. You can switch from Copilot to Claude Agent without touching your editor configuration. If your team standardizes on JetBrains, every developer brings their preferred agent — no one is forced onto a single AI tool because the IDE demands it.
That is a meaningful shift from where things were eighteen months ago. It is also why GitHub’s decision to ship Copilot as an ACP agent rather than a standalone plugin signals where the industry is going.
V1 Is Stable. V2 Is Coming.
ACP v1 is the production spec. Use it today. A v2 draft landed in July 2026 with notable changes: it drops JSON-RPC batches (following MCP’s lead), removes the session modes API, and replaces the old oldText/newText diff format with a structured approach using git_patch plus explicit file operations (add, delete, modify, move, copy). It also removes the client filesystem surface — a security improvement that reduces the agent’s footprint on the host system.
The recommendation: implement v1 for production use and start testing v2 in parallel. If you are building an agent, v2’s structured diff format is a significant improvement and worth planning for.
How to Use ACP Right Now
If you use Zed or JetBrains, ACP support is already built in. Open the agent picker, select from the registry, and authenticate once. For JetBrains Air, Copilot now runs locally or via Air Teams cloud — each cloud task runs in an isolated Docker container on a fresh VM, nothing persists between tasks, and usage is billed against your existing Copilot plan.
If you are building an agent, the Python and TypeScript SDKs are the fastest path in:
# Python
pip install agent-client-protocol
# TypeScript
npm install @agentclientprotocol/sdkBoth SDKs expose async base classes and handle the JSON-RPC-over-stdio transport. You implement the prompt handler; ACP manages the session, permissions, and diff streaming.
The Bigger Picture
ACP has not solved every problem. The optional JWS enforcement in v1 creates integrity risks if skipped, and the registry architecture requires rate-limiting configuration to guard against flooding. These are real concerns — not blockers, but worth addressing before you open agent access to production systems.
The more interesting question is what happens when VS Code formally adopts ACP as first-class — not via an extension, but baked in. At that point, the proprietary IDE-agent coupling era is effectively over. GitHub Copilot’s decision to become an ACP agent rather than deepen its VS Code-specific integration suggests Microsoft is already moving in that direction. Watch the GitHub Changelog.
