Agent Client Protocol (ACP) Spec: LSP for Coding Agents

Key takeaways

1. The sentence to remember. « AI coding agents and editors are tightly coupled but interoperability isn't the default. » The entire 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 reaches only 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 is also where caution is warranted: LSP standardizes an exchange that is largely deterministic (positions, symbols, diagnostics); ACP standardizes the interface of a non-deterministic agent, which negotiates permissions, produces diffs, and whose behavior varies from one run to the next. The shape of the problem is the same; the nature of what passes 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. subprocess of the editor, 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. Declared « 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 on the architecture side, but incomplete: ACP borrows MCP's data structures. The two protocols are not just neighbors, they share a serialization vocabulary. See [[girard-acp-deux-protocoles-un-sigle-2026-08-02]] for the functional distinction.
8. Extensions specific to agentic coding. ACP adds « custom types for useful agentic coding UX elements, like displaying diffs ». This is what justifies ACP existing in addition to MCP: a diff to approve is not a tool call, it is 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 which 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 navigation 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 a product doc. The right phrasing: real openness and co-governance, not dispossession.
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 on 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 / to link. primary source for the claims about ACP #1 in [[girard-acp-deux-protocoles-un-sigle-2026-08-02]] (which it corrects on versioning and qualifies on governance); to 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 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: here, "ACP" refers to Agent Client Protocol only. Never type the acronym as an entity — see docs/solutions/conventions/sigles-jamais-entites-graphe.md.