Agent Client Protocol: Breaking the IDE Prison

Zed just shipped a protocol, not a feature. It’s called the Agent Client Protocol (ACP), and it could reshape how AI agents talk to our code editors. Google’s Gemini CLI was the first to adopt it. Now, Claude Code—one of the most requested agents—has joined in.

But what everyone is missing is that ACP isn’t just about IDEs. It’s the first crack in a prison wall that has caged agents since they were born.

The Prison We’ve Built

Every AI agent today lives in a box. Claude is trapped in its web UI. Cursor can’t leave its IDE. A terminal agent is blind to your editor. They can’t follow you from one tool to the next.

This forces each agent to build the same integrations from scratch. It’s more than inefficient; it’s a cage that stunts their growth.

Think about how you work. You don’t live in one tool. You flow between the terminal, your editor, the browser. You pipe commands together. You switch contexts as the task demands.

Your agents can’t do that. They are stuck in their lanes, unable to follow you where the problem leads.

What ACP Actually Does

ACP borrows its strategy from the Language Server Protocol (LSP): standardize the conversation. Instead of every agent building custom bridges for every editor, agents and editors just need to speak ACP.

The protocol is simple:

• Agents run as subprocesses of the editor.
• They talk using JSON-RPC over stdio.
• They use Markdown for text and custom types for things like code diffs.

Your data stays on your machine. With Gemini CLI, Zed showed how the same agent from your terminal can integrate deeply with the IDE—visualizing edits in real-time and navigating between code and agent responses.

Cleverly, Zed rebuilt its own internal agent on ACP. They use their own protocol, ensuring any UI they build for themselves is available to every other ACP agent.

The Bigger Picture

Solving IDE integration is just the start. The real prize is using ACP as a stepping stone toward something bigger: composable agents that can control any interface.

An agent should be able to control your terminal, your IDE, your browser—even other agents. The protocol shouldn’t be a cage.

Imagine this: You start a task in the terminal. Your agent needs better code navigation, so it opens your IDE to the right files and sets breakpoints. It finds a relevant GitHub issue and opens it in your browser. It pulls a code snippet from that discussion and drops it back into your editor.

This isn’t possible today. But with protocols like ACP, we can build it.

Composability: The Missing Primitive

The breakthrough isn’t an agent that works in an IDE. It’s agents that work together.

Think of them as Unix pipes for intelligence:

terminal-agent | analysis-agent | ide-agent | review-agent

Claude Code already proves this works. It uses specialized subagents—a debugger, a reviewer, a data scientist—that can be chained together. Each one is a simple, focused tool. Each has its own context. But they can pass control from one to the next to solve complex problems.

You can tell it: ‘Use the code-analyzer to find performance issues, then use the optimizer to fix them.’ The debugger captures stack traces; the code-reviewer runs git diff. They are specialized, focused, and composable.

This isn’t a theory. It’s shipping code.

Why Protocols Matter More Than Products

Zed could have built a proprietary system. Instead, they open-sourced a protocol. This is the right move.

Protocols build ecosystems, just as LSP did for language support. They let developers focus on building better agents, not endless integrations. And they create network effects: every new ACP agent makes every ACP editor more valuable, and vice versa.

The Hard Problems Ahead

ACP is a first step, not a final answer. Hard problems remain.

How do agents manage state as they move between tools? How do we grant them power without losing control? How do they coordinate without chaos? How do we keep them fast?

These are the next walls we need to break down.

The Community Speaks (And Argues)

The Hacker News thread on ACP revealed the fault lines in how developers see this future.

’Why Not Just LSP?’

A fair question. LSP handles editor-tool communication. But agents are not language servers. Language servers report on code; agents change code. They orchestrate work across multiple files and need to show diffs, get your approval, and manage complex workflows. Stuffing that into LSP misses the point.

The Prompt Coding Rebellion

One developer rejected the whole idea:

‘I’m fine with treating AI like a human developer: I ask AI to write a feature and then I read the commit. If the commit is not to my liking, I ‘git reset —hard’, improve my prompt and ask the AI to do the task again.’

This is the Unix philosophy for AI: treat the agent as a command-line tool. It works, but it’s a black box. You get a final result, not a collaborator. It’s code review, not pair programming. You can’t guide it, correct it, or see it think.

The Hallucination Wars

The thread exploded over hallucinations. One person said LLMs ‘always use old APIs, APIs that don’t exist, or mix things up.’ Another claimed, ‘I can’t remember the last time I saw a hallucination in a commit.’

Both are right. The difference is context. An agent with no context is a guesser. An agent armed with documentation, source code, and a compile step is a tool. Protocols provide the scaffolding to deliver that context reliably.

Protocol Fatigue Is Real

‘I don’t see why we need so many protocols. In such a greenfield tech, many are eager to define rules.’

The exhaustion is real. But this messiness is how standards emerge. The browser wars gave us web standards. The Unix wars gave us POSIX. The chaos is a feature, not a bug—it means the space is important enough to fight over.

The Practical Concerns

Others raised sharp, practical points. One noted that an agent using ripgrep can’t search your unsaved files. Another pointed out that if Zed wants to be the home for agents, its own diff view needs to be better. You can’t build the future on a shaky foundation.

The Sublime Text Longing

‘I’m tempted to see if Gemini can write a Sublime Text plugin that implements this protocol.’

This comment captures why open protocols matter. Developers love their tools. They don’t want to switch editors to get new capabilities. A protocol lets them have both.

Claude Code Breaks Free

The community demanded it. And on September 3rd, 2025, the protocol delivered. Claude Code now runs in Zed via ACP.

This is more than an integration; it’s proof. The most-requested agent now works in multiple editors not through a custom hack, but through an open standard.

It works because of an open-source ACP adapter written in TypeScript. Any editor can use it. Any developer can improve it.

This is why protocols win. They create leverage. Zed’s work on the protocol brought Claude not just to Zed, but to Neovim (via Code Companion) and any other editor that speaks ACP. It shows the ecosystem is bigger than any single tool. Developers can watch the agent edit files in real-time, review changes across multiple buffers, and accept or reject individual hunks.

The protocol approach isn’t just theory. It’s working.

A Challenge to the Community

This is my challenge to you: Stop building agents that live in one place. Demand tools that work together. Build bridges, define protocols, and compose agents.

The walled gardens will fall. Open, composable systems always win—it’s the story of Unix, the web, and open source.

ACP is the next chapter. The path is clear. The question is who will build it.

Will it be you?

The Agent Client Protocol is open source and actively seeking contributions. Zed has implemented support, Claude Code is now available through ACP, and Code Companion brings both to Neovim. The protocol is yours to build on.