JetBrains’ decision to join Zed Industries and Google in backing the Agent Client Protocol (ACP) is a decisive early vote of confidence for an interoperability story that could reshape how AI coding agents plug into editors and IDEs — but it also raises hard questions about standards maturity, security, and whether the de facto monopoly of Visual Studio Code will bend to a more open approach.
The Agent Client Protocol (ACP) is an open, JSON-RPC–style specification originally published and shepherded by Zed Industries to standardize how interactive coding agents communicate with editors and IDEs. The goal is straightforward: instead of each agent implementing bespoke plugins for every editor, or every editor building integrations for every agent, ACP defines a common wire format and lifecycle for agent sessions, tool calls, file access, streaming assistant messages, and permission dialogs. Early implementations and libraries are available in Rust and TypeScript, and Zed and others have published examples and a public documentation site for the spec.
JetBrains’ announcement that it will collaborate with Zed to bring ACP to its family of IDEs — IntelliJ IDEA, PyCharm, WebStorm and the rest — moves the protocol beyond a niche experiment into mainstream tooling territory. JetBrains frames the move as a defense of developer choice and a way to avoid vendor lock-in: if a coding assistant supports ACP, it ought to “just work” inside any ACP-aware editor, without custom adapters. The company also highlights UX goals such as streaming updates, clear intent, and explicit review flows handled by the IDE.
Zed’s initial public push for ACP included early integrations with Google’s Gemini CLI (to bring Gemini’s terminal-based agent into Zed’s GUI experience) and adapters for other agents like Claude Code, and clients such as Emacs and Neovim already have community extensions. The ACP ecosystem is therefore real and growing, but still young: the spec is described by its maintainers as “under heavy development,” and early adopters are building the first practical UX patterns.
That said, ACP is young. Implementations are growing but not yet battle-hardened; early agent-editor integrations show instability and resource sensitivity; and the security model — permissions, MCP server vetting, and secret handling — must be treated as a first-class governance effort. Organizations that rush to enable unmediated agent actions risk data leaks, misconfigurations, and costly automation mistakes.
For WindowsForum readers who manage developer platforms, the sensible path is to experiment quickly but deploy cautiously: pilot ACP in controlled sandboxes, require human-in-the-loop approval for agent actions, and demand signed manifests and robust telemetry before any production rollout. If the protocol matures and VS Code eventually embraces it, developers and enterprises may gain the long‑promised freedom to mix and match editors and agents without bespoke plumbing. Until then, the promise is real — but so are the implementation and governance headaches that come with being first.
Source: theregister.com JetBrains throws support behind Agent Client Protocol
Background / Overview
The Agent Client Protocol (ACP) is an open, JSON-RPC–style specification originally published and shepherded by Zed Industries to standardize how interactive coding agents communicate with editors and IDEs. The goal is straightforward: instead of each agent implementing bespoke plugins for every editor, or every editor building integrations for every agent, ACP defines a common wire format and lifecycle for agent sessions, tool calls, file access, streaming assistant messages, and permission dialogs. Early implementations and libraries are available in Rust and TypeScript, and Zed and others have published examples and a public documentation site for the spec. JetBrains’ announcement that it will collaborate with Zed to bring ACP to its family of IDEs — IntelliJ IDEA, PyCharm, WebStorm and the rest — moves the protocol beyond a niche experiment into mainstream tooling territory. JetBrains frames the move as a defense of developer choice and a way to avoid vendor lock-in: if a coding assistant supports ACP, it ought to “just work” inside any ACP-aware editor, without custom adapters. The company also highlights UX goals such as streaming updates, clear intent, and explicit review flows handled by the IDE.
Zed’s initial public push for ACP included early integrations with Google’s Gemini CLI (to bring Gemini’s terminal-based agent into Zed’s GUI experience) and adapters for other agents like Claude Code, and clients such as Emacs and Neovim already have community extensions. The ACP ecosystem is therefore real and growing, but still young: the spec is described by its maintainers as “under heavy development,” and early adopters are building the first practical UX patterns.
Why JetBrains’ support matters
1) Scale and credibility
JetBrains is not a niche vendor. Its IntelliJ-based products are widely used across professional Java, Kotlin, Python and polyglot teams. Bringing ACP to JetBrains’ ecosystem gives the protocol immediate reach into large, established user bases and signals that this is not just a point project for an experimental editor. JetBrains’ blog post makes the collaboration explicit and positions ACP as the interoperability layer the company prefers for integrating both first‑party and third‑party agents.2) Platform parity across editors
If ACP gains traction, agents that implement ACP could run in a JetBrains IDE, Neovim, Emacs, Zed, and potentially VS Code and Visual Studio — using the same agent implementation. That lowers engineering overhead for agent vendors and increases choice for developers. Zed’s own blog frames the JetBrains announcement as a pivotal milestone in that direction.3) Better UX for agent workflows
ACP is designed to let the client (the editor) mediate access to the file system, terminal, and permission dialogs, and to render an agent’s plan and incremental edits in a reviewable, multi-buffer UI. That’s a stronger UX model than agents that simply paste large diffs or run CLI scripts without clear, editor-integrated review. JetBrains emphasizes these UX goals and promises native-like experiences that still remain editor-agnostic underneath.What ACP actually standardizes (concise technical summary)
- A JSON-RPC transport model (newline-delimited JSON over stdin/stdout in common implementations).
- Session management: create/load/save discrete agent sessions.
- Streaming assistant messages and incremental “assistant chunk” events for real-time UI updates.
- Tool-call semantics and permission flows: agents request permission to run tools or access MCP servers, and the client mediates approval.
- File access primitives for safe, auditable reads/writes, and multi-buffer edit presentation.
- Extensibility points for custom metadata while preserving core compatibility.
The immediate competitive and market implications
VS Code’s dominance vs. protocol-driven pluralism
Visual Studio Code still dominates editor usage in most surveys, and that reality is the key strategic obstacle to any editor-agnostic protocol: if a single editor has >70% mindshare and a mature extension ecosystem, vendors and users naturally optimize for it. Stack Overflow survey data and related reports show VS Code as the most-used environment by a substantial margin, with IntelliJ-based tools (JetBrains) trailing as the strongest competitor. That market posture is why The Register and commentators call out the question: will Microsoft/VS Code adopt ACP?- If VS Code implements ACP, agents could reach the majority of developers without bespoke VS Code plugins.
- If VS Code declines, ACP adoption still benefits other editors and creates a viable multi‑editor alternative for teams that care about agent portability.
Agents, not editors, become the product boundary
ACP flips part of the integration calculus: instead of editor vendors courting each agent, agent vendors build to ACP once and benefit from multiple clients. That reduces the churn of per-editor adapters and accelerates agent feature parity across editors — assuming implementers stick faithfully to the spec and producers invest in robust ACP server implementations. Zed highlights this lever, and early adopters like Gemini CLI and Claude Code are shipping ACP adapters and plugins.Strengths and practical benefits
- Lower integration cost: Agents only need one ACP server implementation to reach multiple editors.
- Portable UX expectations: The agent’s plan, tool calls, and edits can be presented in a consistent, reviewable way across editors.
- Governance and permission flows: The client controls what the agent can access or run; that mediation is crucial for safer automation.
- Faster experimentation: Editors can add ACP client support quickly using the provided libraries and examples; early adopters are already shipping integrations.
Risks, unanswered questions, and operational caveats
1) Protocol maturity and fragmentation risk
ACP is new. The spec and reference implementations are moving rapidly, and early adopters may diverge or extend the protocol in incompatible ways. That pattern is common in nascent standards and risks fragmentation rather than consolidation. Enterprises and large teams should treat ACP as promising but not yet stable enough to be the single-function reliance for mission-critical flows.2) Security and permission surface
Opening an editor to an agent that can read the repo, open terminals, or invoke external MCP (Model Context Protocol) servers is a powerful capability — and a high-risk attack surface. Threat vectors include:- Prompt injection and content poisoning that manipulates agents into executing dangerous tool calls.
- Credential and secret leakage if agent adapters or MCP connectors mishandle tokens or pass secrets to third-party endpoints.
- Malicious MCP servers or tool manifests that present themselves as benign tools while performing exfiltration or destructive actions.
3) UX and stability trade-offs
Editor-mediated agent flows are more complex than CLI-only patterns. Streaming plan updates, multi-buffer diffs, and interactive tool calls are great for control — but they also demand low-latency IPC, resilient error handling, and UX polish. JetBrains, Zed and early community adapters must all iterate to reduce hangs, memory pressure, and UX glitches that can erode trust. Community issue threads and user reports already call out problems with some agent extensions (hangs, crashes, memory leaks) in VS Code integrations; these are not protocol problems per se, but implementation and integration realities that matter to end users.4) Lock-in trade-offs still exist
ACP reduces lock-in at the agent/editor boundary but does not erase platform lock-in on other axes. Platform ecosystems (marketplaces, paid AI quotas, model hosting providers) still create switching costs. Vendors can build first-party convenience features or richer connectors that make migration nontrivial even if the agent protocol is common. Expect ACP to reduce some friction while new forms of differentiation — and thus lock-in — arise elsewhere.Evidence and verification (what’s confirmed and what is tentative)
- Confirmed: JetBrains published a blog post announcing collaboration with Zed and support for ACP in JetBrains IDEs. Zed separately posted its own blog noting the collaboration. These are primary vendor confirmations showing intent and early engineering work.
- Confirmed: The ACP repository, documentation site, and language libraries exist and are actively maintained by Zed Industries; early client and agent integrations (Zed, Emacs, Neovim, Gemini CLI, Claude Code adapters) are visible in the community and example repos.
- Confirmed: Community reports and issue threads show real-world problems in editor-agent integrations (hangs, crashes, memory issues) in several agent plugins, especially in early VS Code extensions for Gemini and related tools. Those user reports are numerous and visible on forums and issue trackers, indicating operational fragility in some integrations.
- Tentative / unverifiable (as of this writing): A single-line claim reported in some coverage — that a Microsoft engineer explicitly said “this is interesting, but I don't plan to implement it right away” in a specific GitHub issue — could not be independently located in authoritative Microsoft repositories during verification. There are many related feature requests and discussions where Microsoft engineers and maintainers weigh in, but the exact quote and assignment are not found in primary Microsoft sources we checked; treat that specific attribution as plausible reporting rather than a vendor statement. Readers should treat similar paraphrases cautiously until Microsoft provides an explicit public position.
Practical guidance for IT teams and developers (actionable checklist)
- Evaluate ACP in a sandbox
- Run a small proof-of-concept with an ACP client (Zed, Neovim adapter, or a JetBrains preview) and a single ACP agent (Gemini CLI or Claude adapter).
- Measure latency, resource use, and UI behavior on representative repositories.
- Harden permissions and secrets
- Disable or restrict automatic “apply edits” or “auto-run” behavior until workflows and logging are audited.
- Use ephemeral credentials and environment-scoped secrets for any agent that can call external APIs.
- Treat agent tool manifests as code
- Keep MCP/ACP tool manifests in version control, review changes in PRs, and require signed manifests for production MCP servers.
- Instrument observability and rollback paths
- Log agent actions in centralized telemetry with correlation IDs, and ensure agent-driven edits are easy to revert (automation that creates draft PRs or separate branches is safer than in-place commits).
- Pilot with non-critical workflows first
- Start with read-only or reviewable workflows (code search, scaffolding, test generation) before enabling agent-driven refactors or CI/CD changes.
- Maintain protocol version tolerance
- Assume ACP will evolve. Design adapters and CI checks to validate compatibility across minor versions and maintain migration plans.
- Watch for editor and extension health signals
- Track community issue lists for your chosen agent/editor combinations; early deployments will surface stability and UX bugs that require rapid patching.
What to watch next (short-term signals)
- Official Microsoft stance: a public statement or an issue where the VS Code team commits to ACP integration would be a major inflection point for ubiquity. Without that, ACP can still succeed in polyglot environments, but VS Code accommodation would accelerate mass adoption.
- JetBrains preview releases and early-access builds: practical, shippable integrations in IntelliJ IDEA/other JetBrains IDEs will be the acid test for real-world quality and parity with existing agent experiences. JetBrains’ blog signals planned previews and milestones.
- Standardization and cross-vendor testing: community-driven conformance tests, signed tool registries, and interop test suites will be the mechanisms that move ACP from “useful experiment” to “enterprise-ready standard.” Look for cross‑vendor hackathons and a growing set of validated MCP/ACP pairings.
Final assessment: pragmatic optimism with guarded controls
JetBrains joining ACP is an important practical milestone: it brings a heavyweight IDE vendor into the interoperability story and materially improves the protocol’s chance of becoming a durable part of the tooling landscape. The potential benefits are concrete and immediate: fewer bespoke adapters, more agent choice for developers, and a path toward consistent UX for interactive agent workflows.That said, ACP is young. Implementations are growing but not yet battle-hardened; early agent-editor integrations show instability and resource sensitivity; and the security model — permissions, MCP server vetting, and secret handling — must be treated as a first-class governance effort. Organizations that rush to enable unmediated agent actions risk data leaks, misconfigurations, and costly automation mistakes.
For WindowsForum readers who manage developer platforms, the sensible path is to experiment quickly but deploy cautiously: pilot ACP in controlled sandboxes, require human-in-the-loop approval for agent actions, and demand signed manifests and robust telemetry before any production rollout. If the protocol matures and VS Code eventually embraces it, developers and enterprises may gain the long‑promised freedom to mix and match editors and agents without bespoke plumbing. Until then, the promise is real — but so are the implementation and governance headaches that come with being first.
Source: theregister.com JetBrains throws support behind Agent Client Protocol
