Agent Client Protocol (ACP) Specification: Editor-Agent Interop

Key takeaways

1. The sentence to remember. "AI coding agents and editors are tightly coupled but interoperability isn't the default." The whole protocol follows from this observation.
2. The three costs of coupling. (structure to reuse as-is in presentations): integration overhead — every agent×editor combination requires custom work; limited compatibility — an agent only reaches a subset of editors; developer lock-in — choosing an agent means accepting its interfaces. The three are different costs (production, distribution, freedom), not three phrasings of the same one.
3. The LSP analogy does the work. "similar to how the Language Server Protocol standardized language server integration." It's effective because the precedent is already accepted. ⚠️ But it's also where caution is warranted: LSP standardizes a largely deterministic exchange (positions, symbols, diagnostics); ACP standardizes the interface of a non-deterministic agent, which negotiates permissions, produces diffs, and whose behavior varies from run to run. The shape of the problem is the same; the nature of what flows through it is not. The page does not discuss this gap.
4. ⭐ Two transport modes, not one. — the most underrated point in secondary coverage:
5. Local agents. editor subprocess, JSON-RPC on stdio. This is the known mode, the one everyone cites.
6. Remote agents. hosted in the cloud or on separate infrastructure, HTTP or WebSocket. Stated as "work in progress," with active collaboration with agentic platforms. → Consequence: ACP is not structurally a "workstation" protocol. Its trajectory targets the hosted agent, hence the enterprise. Summarizing ACP as "JSON-RPC over stdio" describes its present, not its target.
7. ⭐ The relationship to MCP is a lineage, not mere complementarity. "The protocol re-uses the JSON representations used in MCP where possible." It is commonly said that "ACP and MCP stack" (the client speaks ACP to the agent, the agent speaks MCP to its tools) — true architecturally, but incomplete: ACP borrows MCP's data structures. The two protocols are not merely neighbors, they share a serialization vocabulary. See [[girard-acp-deux-protocoles-un-sigle-2026-08-02]] for the functional distinction.
8. The extensions specific to agentic coding. ACP adds "custom types for useful agentic coding UX elements, like displaying diffs." This is what justifies ACP's existence alongside MCP: a diff to approve is not a tool call, it's an interface element that requires a human decision. The protocol encodes the review moment, not just execution.
9. Markdown by default, and the stated reason. "which allows enough flexibility to represent rich formatting without requiring that the code editor is capable of rendering HTML." A design decision justified by the burden it spares the implementer — the right instinct for a protocol seeking adoption. Worth noting for anyone designing a protocol: lower the entry cost on the side you want to recruit.
10. ⚠️ Versioning correction. the specification's navigation exposes v1 (Latest) and v2 (Draft). It does not expose an "ACP 1.2." This number, which circulates in secondary coverage (and was logged as unverified in [[girard-acp-deux-protocoles-un-sigle-2026-08-02]]), is not corroborated by the primary source. Cite v1 / v2 draft.
11. ⚠️ Governance correction. the phrase "Zed launched it then let it go" is too strong. The nav bar links Zed Industries and JetBrains at the same level, and the site's structure (ACP Registry, RFDs, Community, Publications, Updates, Brand) is that of a co-governed project with a process, not an orphaned protocol or product docs. The correct framing: real openness and co-governance, not abandonment.
12. Ecosystem signal. official libraries in Kotlin, Java, Python, Rust, TypeScript + a community track. The Kotlin/Java pairing is the JetBrains marker — the presence of both signals that the JVM IDE implementation is first-class, not a late port.
13. A telling detail. the page opens with a pointer to /llms.txt — "Use this file to discover all available pages before exploring further." The documentation of a protocol for agents is itself tooled for agents. Consistency of the setup, and a weak signal about what technical documentation is becoming.
14. What the page does not say. (not to be filled in by inference): no date, no version number stated in the body, no license displayed on this page, no formalized governance model, no list of implementers. The Apache-2.0 license often cited for ACP comes from the repository, not from this page.
15. Meta / cross-references. primary source for the claims about ACP #1 in [[girard-acp-deux-protocoles-un-sigle-2026-08-02]] (which it corrects on versioning and nuances on governance); to be read alongside [[dethlefsen-zed-anthropic-subscription-changes-2026-05-14]], which shows what the optionality promised here is worth the day a provider changes its pricing; the decoupling described here connects to the portability contract analyzed in [[janakiram-agent-platform-portability-contract-2026-07-20]]; a reference implementation on the product side in [[block-goose-mcp-ui-future-agentic-interfaces-2025-08-25]]. ⚠️ Mandatory disambiguation: "ACP" here refers to Agent Client Protocol only. Never type the acronym as an entity — see docs/solutions/conventions/sigles-jamais-entites-graphe.md.