What actually shipped and why 'LSP moment' is the structurally correct framing
The Agent Client Protocol (ACP) has been moving from spec to install base steadily through the back half of 2025 and into 2026; the events of the last quarter mark the point where the protocol crossed from emerging standard to working infrastructure across most of the editor install base.
The operationally important specifications and adoption events, summarized from the consolidated Zed, JetBrains, and Devin documentation and the practitioner write-ups around the June rollout:
- ACP is JSON-RPC 2.0 over stdin/stdout, designed by Zed and JetBrains as an open editor-agent interoperability standard. License is Apache 2.0. The framing the maintainers use is explicit: ACP is to coding agents what the Language Server Protocol (LSP) was to language tooling — a thin, well-specified handshake that decouples the editor from the implementation upstream so the editor and the agent can evolve on their own clocks.
- JetBrains shipped native ACP support across the entire IntelliJ-family lineup — IntelliJ IDEA, PyCharm, WebStorm, GoLand, RubyMine, the rest of the family — via the AI Assistant. The shape of the rollout is the editor surfaces ACP as a first-class agent integration mechanism, the IDE vendor is not the one who picks which agent the developer uses, the developer chooses from the registry.
- Zed has native ACP support built into the core editor.
- The ACP Registry, co-launched by Zed and JetBrains, is a public directory of ACP-compatible agents. Maintainers register an agent once; the registry surfaces it inside every compatible editor; the editor pulls the latest version on the developer's behalf. 25+ agents are in the registry as of June 2026, including Claude Code (Claude Agent), Codex CLI, OpenCode, Gemini CLI, GitHub Copilot CLI, and a growing tail of in-house and specialty agents.
- VS Code support is available via extension, not native, but the install path is a single command for the developer.
- Devin Desktop's June 2 relaunch shipped with ACP as the default integration surface — the customer points Devin Desktop at any ACP-compatible agent (Codex, Claude Agent, OpenCode, an in-house agent the customer's team built) and the same editor runs the workflow.
The 'LSP moment' framing is not a marketing line; it is the structurally correct description of what just happened. Through the 2000s, every editor implemented its own integration for every language: a TypeScript plugin in VS Code, a separate one in Sublime, a separate one in JetBrains, a separate one in Vim. LSP collapsed that to the language ships a server, the editor speaks the protocol, the integration is N+M effort instead of N×M effort. Through 2024 and 2025, every coding agent shipped its own plugin for every editor: a Cursor surface, a Claude Code surface, a Codex surface, a Windsurf surface — each rebuilt for each editor the agent's vendor decided to support. ACP collapses that the same way LSP did: the agent speaks the protocol, the editor speaks the protocol, the integration is N+M effort.
The difference between N+M and N×M is the difference between a new agent can ship into the install base in a week and a new agent needs a multi-quarter engineering investment to reach the same install base. That difference is what unlocks the next generation of agent variety; it is also what removes the moat the IDE vendors were quietly counting on to keep agent choice locked to their platform.
Why an open editor-agent protocol changes the IDE vendor's leverage
For the last three years, the IDE choice has been increasingly tangled up with the agent choice. The team that standardized on VS Code got nudged toward Copilot; the team that picked Cursor got Cursor's agent; the team that adopted JetBrains had a JetBrains-native AI Assistant story that was harder to extend with third-party agents. The agent choice was de facto coupled to the editor choice, and the coupling was working in the IDE vendor's favor — every additional bit of IDE-specific integration the developer learned was lock-in that the editor vendor accumulated against the others.
Three shifts that follow when the editor-agent integration runs over an open standard with a public registry.
The editor choice and the agent choice become independent decisions. A team using IntelliJ can now run OpenCode against an open-weights model on the air-gapped engagement and Claude Code against Opus 4.8 on the standard product work, with the same editor, the same configuration, the same registry. A team that prefers Zed for the lightweight surface and JetBrains for the heavy refactor work can run the same agent in both. The IDE vendor's leverage to bundle the agent with the editor collapses; the agent vendor's leverage to bundle the editor with the agent collapses. Each side has to compete on what they actually do well — the editor on the editing surface, the agent on the agent capability — and the customer captures the gains from both sides of the now-decoupled competition.
The IDE vendor's incentive shifts from lock-in to differentiation on the editing surface. The IDE vendors that recognize the shift early — JetBrains is the canonical example, building the protocol they will eventually compete inside — get to define the editor-surface conventions the protocol assumes, ship the highest-quality editor for the new world, and capture the developer mindshare on the actual editing experience. The IDE vendors that fight the protocol get to spend the next two quarters watching the developer base migrate to the editors that didn't. The competitive lesson from LSP is not subtle: the IDEs that embraced LSP early (VS Code, JetBrains, Zed in its own time) won the next decade; the IDEs that resisted (the holdouts that wanted to keep language integration proprietary) lost the install base they were trying to protect.
The in-house agent question gets a much cheaper answer. Most enterprise engineering organizations have at least one workload that would benefit from a custom agent — a domain-specific code review agent, a workflow-specific deployment agent, an internal automation agent with access to systems the off-the-shelf agents don't reach. Through 2024 and 2025, the in-house agent was expensive to build and expensive to deploy: the customer had to build a per-editor plugin for every editor the engineering org used, maintain it across editor updates, and re-implement the integration surface every time the editor's plugin API changed. ACP collapses the deployment cost. The customer builds the agent once, ships it as an ACP-compatible binary, and it works inside every editor the engineering org uses. The build-vs-buy boundary moves: workloads that were on the buy because we can't justify the integration cost side of the boundary move to the build because the integration cost just collapsed side.
What changes about the multi-vendor routing strategy at the editor layer
Four shifts that follow when the editor layer is open, the agent registry is public, and the integration surface is one protocol away from the customer's preferred IDE.
The routing strategy gets a per-developer dimension the platform layer can't override. Through 2025 most multi-vendor routing was happening at the platform layer: the customer's gateway sat between the IDE and the model providers, the routing logic chose which model the request hit, the IDE was a passive surface above that. ACP brings the routing decision into the editor itself: the same developer, in the same session, can ask Codex CLI for one task, Claude Agent for the next, OpenCode for the third, and the in-house agent for the fourth, with the choice made by the developer based on the task at hand rather than by a routing rule at the gateway. The platform layer's routing logic is still useful for defaults and cost ceilings, but the per-developer per-task choice is now a first-class capability of the editor itself.
The eval matrix has to be replicable across every agent the developer can invoke. A registry with 25+ agents and a developer base that can pick any of them per task is a routing surface where the aggregate quality of the engineering output depends on the developer making good per-task choices. The eval matrix that informs those choices — which agent is best on which workload class, on the customer's specific codebase — has to be authored, maintained, and surfaced to the developer at decision time. The teams that ship the eval matrix as a first-class internal tool (a dashboard, an editor-side recommendation, a runbook) will see the per-task routing compound into top-quartile output. The teams that leave it to the developer's intuition will see uneven quality and cost across the engineering org.
The procurement conversation moves from 'which IDE' and 'which agent' to 'which combination, and how do we govern it.' A buyer signing the procurement contract for an editor + agent stack in June 2026 is no longer signing a single-vendor commitment. The contract structure has to reflect the new reality: the editor license, the agent licenses, the model provider rate cards, and the governance surface that ties them together are four separate procurement objects with four separate negotiating dynamics. The buyer that anchors the conversation on which single vendor we sign with will sign a contract that is structurally misaligned with the operational reality six months in. The buyer that anchors on the editor + agent + model + governance surface as a portfolio gets the procurement structure that matches how the engineering org actually uses the stack.
The lock-in moves from the editor and agent layers up to the governance and observability layer. When the editor is open, the agent is interchangeable, and the model is multi-provider, the durable lock-in in the AI coding stack is the governance surface — the audit log of which agent ran which workload, the cost-per-successful-task attribution per agent and per model, the senior-review queue calibration, the eval matrix the customer maintains. The teams that own the governance surface, in a portable representation the customer controls, keep the optionality across vendor cycles. The teams that let the platform vendor own the governance surface have shifted the lock-in from the editor (where ACP collapsed it) to a layer where the consequences are bigger and the exit harder.
What this does not change
Three honest caveats, because the temptation will be to read the ACP rollout as a complete answer to the lock-in problem.
It does not eliminate the model-layer differentiation. ACP standardizes the editor-agent boundary, not the agent-model boundary. The agents still differ in which models they're optimized for, which models they ship with, which models the underlying runtime supports. A customer running Claude Code through ACP still gets a Claude-flavored experience; running OpenCode through ACP still gets the customer's choice of model with the routing the customer owns. The protocol is the integration; the agent is still the agent.
It does not eliminate the workload-specific eval discipline. An open ecosystem with 25+ agents available in every editor is an ecosystem where the buyer's question — which of these agents is the right one for our specific workload — gets harder, not easier. The eval discipline that grades each agent honestly on the customer's codebase is what makes the choice rational. The buyer who reads the registry as more agents means more options without authoring the eval matrix will discover that more options is the same as no decision in operational reality.
It does not collapse the multi-vendor reality at the higher layers. ACP is a portability win at the editor layer specifically. The same buyer still has to design the multi-vendor strategy at the model layer (which models, on which routing policy), at the MCP tool layer (which data sources, on which permission surface), at the observability layer (which spans flow into which dashboard), and at the governance layer (which audit, against which policy). The protocols are stacking up — MCP for tool-and-data, ACP for editor-agent, A2A for inter-agent — and the customer who designs against all three keeps the optionality. The customer who treats any one of them as a complete answer to portability will discover the lock-in at the layer they didn't think about.
Where Sonnet Code fits
An open editor-agent protocol with a public registry and credible adoption across the IDE install base is the easy half of the portability story. The hard half is the engineering and human-judgment work that turns the editor speaks ACP into the right agent runs on the right workload, the eval matrix is calibrated, the governance surface is owned in a portable representation, and the in-house agent surface extends the protocol where the workload warrants it. AI development at Sonnet Code is the engineering half: designing the ACP-native deployment of multi-agent routing into the customer's existing IDE footprint; building in-house agents as ACP-compatible binaries that ship into every editor the engineering org uses without per-editor rewrites; wiring the agent-side observability into the customer's existing telemetry surface so the cost-per-successful-task attribution per agent and per task is a first-class metric; and structuring the governance surface — audit, policy, eval matrix — in a portable representation the customer owns. AI training is the human-judgment half: senior engineers and domain experts who author the agent-specific gold sets that grade each registered agent honestly on the customer's actual workload, calibrate the senior-review queue for the per-agent failure-mode shape, build the eval matrix that the developer's per-task choices reference at decision time, and serve as the senior-judge pool whose calibrated decisions feed back into the success criteria the routing strategy compounds against.
The editor-agent interoperability boundary just got standardized. The teams that walk into Q3 with the multi-agent routing deployed inside the existing IDE footprint, the eval matrix authored against the registry, the governance surface owned in a portable representation, and the senior-review queue calibrated for the per-agent failure-mode shape are the teams that turn the ACP rollout into a compounding cost-and-capability advantage through the rest of 2026. The teams that pick a single agent from the registry and treat the protocol as solved will discover, two renewal cycles later, that the buyer down the road who designed the stack against the protocol — not against any single registered agent — is paying meaningfully less for higher-quality output, and is rotating in new agents from the registry as the relative-capability ranking shifts under everyone else.
