OpenIDE adds ACP: how the JetBrains and Zed protocol changes how AI agents work in IDEs

ACP becomes a new compatibility layer between IDE and AI agents: instead of a separate integration for each tool, the editor and agent agree on a common protocol. OpenIDE has already implemented basic ACP support and is preparing it for beta testing.

What is ACP

Over the past year, the market for AI tools for development has turned into a jumble of separate ecosystems. Claude Code, Codex, Cursor, Windsurf, Kilo Code, Qwen Code and other agents can write, fix and refactor code, but almost each one comes with its own scheme for connecting to the editor. As a result, the developer chooses not only the strongest agent, but also the editor where an integration for it has already been written.

ACP tries to break this dependency. In its concept, ACP is very similar to LSP, which once freed editors from the need to separately implement support for each language. If back then a unified protocol connected the editor and the language server, now such a compatibility layer is appearing between the IDE and the AI agent.

The protocol describes how the parties exchange messages, context, action requests and execution status. In practice, this means that an agent can be connected entirely — along with its logic, tools and way of working, rather than simply sending requests to the selected model via API.

Why standards are difficult without them

The main problem with the current market is that many integrations remain custom-made. One editor can work with one agent, another with two, a third requires a separate plugin or semi-official script. While this looks tolerable if you use one tool.

But as soon as you want to compare several agents, you quickly hit incompatibilities, extra configurations and vendor lock-in. For teams, this is even more painful: changing an editor or agent starts to require extra process migration. ACP is needed precisely to divide the roles.

The IDE is responsible for the development environment: code navigation, highlighting, diffs, refactoring, file and terminal work. The agent is responsible for autonomous logic: how to build a plan, which tools to call, how to make changes and when to ask for confirmation. In the official protocol description, both basic stages like initialization and prompt transmission, and more practical things are provided — file reading and writing, terminal creation, task updates and requests for action permissions.

Another important point: connecting a model via API is not the same as connecting an agent. When you simply provide a key to an LLM, the editor itself remains the orchestrator and merely sends requests to the provider. ACP allows you to embed a ready-made agent in the IDE as a separate entity.

For the developer, this is more convenient: you can use your favorite editor without losing the features of a specific AI tool. In other words, the standard brings not just a model to the IDE, but its entire working loop.

What will appear in OpenIDE

Haulmont writes that the basic implementation of ACP in OpenIDE is already ready, and the next stage is beta testing. For users, this is not an abstract "we'll support it eventually," but a quite practical step towards an IDE where an agent is connected as a standard component. If support reaches a stable release without serious limitations, OpenIDE will be able to adopt new compatible agents more quickly without separate custom integrations for each one.

• Basic ACP support is already implemented
• The feature will be part of OpenIDE Pro
• During the beta period, compatibility is promised in the base version of OpenIDE
• Those interested can request early access and configuration in advance

The logic is clear: instead of manually supporting an increasing number of separate AI plugins, the IDE receives a single interface for external agents. At the same time, OpenIDE itself continues to rely on things familiar to developers — the editor, navigation, refactoring, terminal and the plugin ecosystem. The article specifically emphasizes that the environment is currently designed for Java, Spring, Python, Go, JavaScript and TypeScript, and can also work with Docker and extensions from a compatible marketplace. ACP in this scheme looks not like a fashionable add-on, but as the next infrastructure layer.

What this means

If ACP takes hold the way LSP once did, the AI coding market will become noticeably more open. Developers will be able to choose the best agent separately from their favorite IDE, and agent creators will spend less effort on dozens of individual integrations. For OpenIDE, this is a chance to connect popular tools more quickly, and for the entire ecosystem, a step from a chaotic zoo of AI plugins to a more coherent standard. It is usually such protocols that determine which approaches become mainstream and which remain niche.