TL;DR: As of 2026, Agent Client Protocol adoption is accelerating as the emerging standard that lets coding agents communicate with any editor the same way LSP unified language features. JetBrains, Google, GitHub, and 25+ coding agents back ACP, but Anthropic backs the competing Model Context Protocol instead. This fragmentation means developers must currently choose sides, making ecosystem momentum real but incomplete.
Key Takeaways
- ACP mirrors the LSP playbook: just as LSP decoupled language tools from editors, ACP lets any coding agent plug into any compliant editor without custom glue code.
- As of mid-2026, adoption is real but not universal: JetBrains, Google, GitHub, and 25+ coding agents back ACP, while Anthropic has standardized on MCP instead.
- Anthropic's holdout changes the math: because Anthropic created and backs MCP as its primary integration standard, a genuine split ecosystem is possible rather than theoretical.
- MCP and ACP solve different problems: MCP gives agents access to tools and context; ACP standardizes how agents communicate with the editor itself.
- The ecosystem is at its LSP inflection point: enough adoption to take seriously, not enough to treat as a safe default.
- Building on ACP today carries fragmentation risk: choosing between standards is a bet on which model of developer workflow, editor-as-orchestrator or agent-as-orchestrator, wins long term.
What does Agent Client Protocol actually standardize?
ACP standardizes the communication layer between code editors and coding agents, defining the methods each side can call and the notifications each side can send to track shared state.
ACP works by exposing methods that agents and clients can call on each other, alongside asynchronous notifications that keep both sides informed of state changes. That bidirectional design gives the editor and agent a continuous shared session rather than a one-way command pipe.
ACP supports both local and remote scenarios, which matters for teams with data-residency requirements. The open-source repository follows a structured change process, signaling governance maturity rather than an early-stage experiment.
The LSP parallel is instructive. Before LSP, every editor needed its own implementation for every language. After LSP, that integration burden collapsed. ACP applies the same logic to coding agents: one protocol, any compliant editor, no custom glue code per integration.
Who has adopted ACP as of mid-2026, and who has not?
ACP has been adopted by JetBrains, Google, GitHub, and 25+ coding agents, making it the most broadly backed editor-agent standard available right now, but Anthropic has chosen Model Context Protocol instead.
| Stakeholder | ACP Status | Notes |
|---|---|---|
| JetBrains | Adopted | Dedicated product page at jetbrains.com/acp |
| Adopted | On record as supporter | |
| GitHub | Adopted | On record as supporter |
| 25+ coding agents | Adopted | Documented multi-agent support |
| Anthropic | Holdout | Standardizing on MCP for agent integration |
What is the real difference between ACP and MCP?
ACP standardizes how agents communicate with the editor as an orchestrating host. MCP standardizes how agents call external tools and retrieve context. They become architectural rivals in practice when a vendor chooses one as its primary integration surface, because that choice determines whether the editor or the agent holds the control plane.
ACP's bet: the editor is the control plane. The editor orchestrates the agent, deciding when it runs, what it sees, and what it can do. This maps to how most engineers already work: the IDE is the primary environment, and agents operate within it.
Choosing between ACP and MCP is therefore a vote on which entity, editor or agent, runs the developer workflow. The architectural difference is not theoretical: it determines where session state lives, who initiates actions, and which side can be swapped out independently.
Should you build your coding agent on ACP or MCP?
Build on ACP, MCP, or both depending on your integration surface, but during genuine standard competition, building for both is the most defensible architecture
Build on ACP if your primary surface is JetBrains, Google, or GitHub tooling; your agent needs to report progress and respond to editor-originated requests; or you want the broadest compatible install base available today.
Build on MCP if your agent is tool-heavy and needs rich context retrieval; your primary target is Anthropic's ecosystem; or you believe the agent-as-orchestrator model will dominate long term.
Build on both if you are building a general-purpose agent that cannot afford to exclude either ecosystem. Running both adds integration complexity but avoids a forced bet while neither standard has achieved clear dominance.
ACP-only agents will not work in Anthropic-aligned editors without a rewrite. MCP-only agents miss the JetBrains, Google, and GitHub install base. As a practical rule of thumb used in this guide: document your architecture decision now and revisit it at the next major adoption signal, because the ecosystem is moving fast enough that a six-month-old integration bet may already need updating.
FAQ
Q: What is the difference between Agent Client Protocol and Model Context Protocol? ACP defines the session lifecycle, progress reporting, and bidirectional state tracking between an agent and an editor. MCP defines how an agent reaches external tools, files, and services. A vendor choosing MCP as its primary editor integration makes the two standards competitors in practice, even though they address different problems in isolation.
Q: Which editors support ACP natively as of mid-2026? JetBrains has product-level support at jetbrains.com/acp; Google and GitHub are documented backers; 25+ coding agents have adopted ACP. The conspicuous absence is Anthropic, which has standardized on MCP instead.
Q: Why is Anthropic standardizing on MCP instead of ACP? MCP treats the agent as the primary entity, with the editor as one surface among many. That is an explicit architectural bet that the future of developer workflows is agent-centric rather than editor-centric, a different philosophy from ACP's editor-as-orchestrator model, not simply a different implementation of the same idea.
Q: Can a coding agent support both ACP and MCP simultaneously? Yes. Running both adds integration complexity but avoids a forced bet while neither standard has achieved dominance. ACP handles editor-side session communication; MCP handles tool and context access. The two protocols are not mutually exclusive at a technical level, the cost is maintenance overhead, not architectural impossibility.
Conclusion
ACP is at a pre-tipping-point moment: the coordination benefit is real, the fragmentation risk is real, and the outcome is not yet settled. If the editor-as-orchestrator model wins, developers retain the control plane they already work in. If agent-as-primary-citizen wins, the editor becomes a more passive surface and workflows shift without a formal breaking change announcement.
The Anthropic holdout is the single most important variable to watch. A protocol standard that excludes one of the most influential AI labs in the space is not a settled standard, it is a strong candidate. Whether ACP clears that bar depends on decisions being made right now by teams deciding where to put their integration effort.
Your next step: Read the ACP protocol overview at agentclientprotocol.com/protocol/v1/overview, then verify whether your primary editor is on the adopter list before committing your integration architecture.
Learn from me
Claude Code in Practice, my Maven cohort. Master Claude Code from fundamentals to advanced orchestration: skills, subagents, hooks, MCP, and production automation. Join the next cohort →
Hire us
Traversaal.ai. We're a team of forward deployed engineers solving the toughest AI problems for Fortune 100 companies: document intelligence, agentic data platforms, and real-time web intelligence, deployed in production. Work with our team to deploy your next agentic ecosystem. Talk to Traversaal.ai →
Join us
Want to solve these problems with us? We're always looking for forward deployed engineers who want to ship production AI. jobs@traversaal.ai
