# agentclientprotocol-introduction-2026-08-02

## Veille

Landing page of the **official specification** of the **Agent Client Protocol (ACP)** (`agentclientprotocol.com/get-started/introduction`), accessed on **August 2, 2026**. This is not a dated article but a **living artifact**: the fiche is dated by its observation, not by a publication date. **One-sentence mission statement**: *"The Agent Client Protocol (ACP) standardizes communication between code editors/IDEs and coding agents and is suitable for both local and remote scenarios."* **The stated problem** fits in three lines: coding agents and editors are **tightly coupled** and *"interoperability isn't the default"* — every editor must build a custom integration per agent, every agent must implement editor-specific APIs. Three named consequences: **integration overhead** (every agent-editor pair requires custom work), **limited compatibility** (an agent only reaches a subset of editors), **developer lock-in** (*"choosing an agent often means accepting their available interfaces"*). **The solution is explicitly modeled on LSP** — *"similar to how the Language Server Protocol (LSP) standardized language server integration"* — with a reciprocal benefit: an agent that speaks ACP works with **any** compatible editor, an editor that supports ACP gains access to the **entire** ACP agent ecosystem. **Two deployment modes, and this is the most underrated point**: **local** agents run as an editor subprocess over **JSON-RPC on stdio**, but **remote** agents are planned over **HTTP or WebSocket** — support stated as *"work in progress"*, with ongoing collaboration with agentic platforms. **Technical lineage with MCP, stronger than mere complementarity**: ACP *"re-uses the JSON representations used in MCP where possible"*, adding types specific to agentic-coding UX needs (**diff** display is the example given); the default format for readable text is **Markdown**, chosen so the editor is not required to render HTML. ⚠️ **Two governance and versioning observations** noted on the page and not in the surrounding discourse: navigation exposes **v1 (Latest)** and **v2 (Draft)** — and **not an "ACP 1.2"** —, and the nav bar links **Zed Industries *and* JetBrains** side by side, alongside an **ACP Registry**, **RFDs**, a **Community** section, **Publications**, **Updates**, and a **Brand** page. Announced official libraries: **Kotlin, Java, Python, Rust, TypeScript**, plus a community track.

## Titre Article

Agent Client Protocol — Introduction

## Date

2026-08-02

## URL

https://agentclientprotocol.com/get-started/introduction

## Keywords

Agent Client Protocol, ACP, open protocol, specification, interoperability, editor-agent decoupling, LSP, Language Server Protocol, JSON-RPC, stdio, subprocess, local agents, remote agents, HTTP, WebSocket, work in progress, MCP, Model Context Protocol, reuse of JSON representations, custom types, diff display, Markdown, integration overhead, limited compatibility, developer lock-in, developer lock-in, N+M, agent ecosystem, Zed Industries, JetBrains, ACP Registry, agent registry, RFD, request for discussion, protocol governance, v1 latest, v2 draft, specification versioning, client libraries, Kotlin, Java, Python, Rust, TypeScript, Mintlify, living documentation, llms.txt

## Authors

**Projet Agent Client Protocol** — spécification collective, sans signature individuelle sur cette page. La barre de navigation du site lie deux organisations au même niveau : **Zed Industries** (à l'origine du protocole) et **JetBrains**. La présence d'une section **RFDs** (*requests for discussion*), d'une page **Community** et d'un **ACP Registry** indique une structure de gouvernance ouverte plutôt qu'une documentation produit.

Documentation construite et hébergée sur **Mintlify**. La page expose un `llms.txt` en tête (*« Fetch the complete documentation index at: /llms.txt — Use this file to discover all available pages before exploring further »*) : le site est explicitement outillé pour être lu par des agents.

## Ton

**Profile**: introduction page of an **open technical specification**, in the register of a *standards body* rather than product marketing. Very short — two sections (`Why ACP?`, `Overview`) — and built entirely to be quoted.

**Style**: the canonical form of the open protocol pitch, in three mechanical moves: (1) **name the existing coupling**, (2) **enumerate its costs** in three symmetrical bullets, (3) **state the legitimizing analogy**. The LSP analogy does all the rhetorical work: it carries a precedent the reader has already accepted (LSP did decouple editors and languages) into a domain where the demonstration is still to be made. Remarkable economy of means — no quantified promise, no business benefit, no mention of a competitor.

Two markers of restraint that build trust: the admission that remote-agent support is *"a work in progress,"* and the justification **by constraint** of the Markdown choice (*"without requiring that the code editor is capable of rendering HTML"*) — a design decision explained by what it does **not** impose on the implementer, the right instinct for a protocol seeking adopters.

**Marker phrases**: *"interoperability isn't the default,"* *"Every new agent-editor combination requires custom work,"* *"choosing an agent often means accepting their available interfaces,"* *"Agents that implement ACP work with any compatible editor,"* *"This decoupling allows both sides to innovate independently."*

## Pense-betes

- **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.
- **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.
- **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.
- **⭐ Two transport modes, not one** — the most underrated point in secondary coverage:
- **Local agents**: editor subprocess, **JSON-RPC on stdio**. This is the known mode, the one everyone cites.
- **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.
- **⭐ 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.
- **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.
- **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.
- **⚠️ 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**.
- **⚠️ 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**.
- **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.
- **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.
- **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**.
- **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`.

## RésuméDe400mots

Introduction page of the **Agent Client Protocol** specification, accessed August 2, 2026. A living artifact with no publication date: the fiche is dated by its observation.

**The problem.** *"AI coding agents and editors are tightly coupled but interoperability isn't the default."* Every editor must build a custom integration for every agent it wants to support, and every agent must implement the APIs specific to each editor. Three distinct costs follow: **integration overhead** (any agent-editor combination requires specific work), **limited compatibility** (an agent only reaches a fraction of editors), and **developer lock-in** — *"choosing an agent often means accepting their available interfaces"*.

**The solution.** ACP standardizes agent-editor communication *"similar to how the Language Server Protocol (LSP) standardized language server integration."* The benefit is reciprocal, and that's what holds the ecosystem together: an agent that implements ACP works with any compatible editor; an editor that supports ACP gains access to the entire ACP agent ecosystem. *"This decoupling allows both sides to innovate independently."*

**The architecture.** ACP assumes the user is **primarily in their editor** and reaches out to an agent for a specific task. Two deployment modes: **local** agents run as an editor subprocess and communicate over **JSON-RPC on stdio**; **remote** agents, hosted in the cloud or on separate infrastructure, communicate over **HTTP or WebSocket** — support stated as *"a work in progress,"* with active collaboration with agentic platforms. The second mode is routinely omitted in secondary coverage, even though it maps out the protocol's enterprise trajectory.

**The link to MCP** is closer than an architectural complementarity: ACP *"re-uses the JSON representations used in MCP where possible,"* while adding types specific to agentic-coding UX — **diff display** is the example given. The default format for readable text is **Markdown**, chosen precisely so the editor is not required to render HTML.

**Two observations about the source itself.** The navigation exposes **v1 (Latest)** and **v2 (Draft)** — not the "ACP 1.2" that circulates elsewhere. And it links **Zed Industries and JetBrains at the same level**, alongside an **ACP Registry**, **RFDs**, a Community section, Publications, Updates, and a Brand page: the structure of a co-governed project with a process. Official libraries in Kotlin, Java, Python, Rust, and TypeScript.

## GrapheDeConnaissance

- Agent Client Protocol —permet→ de standardiser la communication entre éditeurs de code et agents de codage (AFFIRMATION, 0.98)
- Agent Client Protocol —s_inspire_de→ Language Server Protocol (TECHNOLOGIE, 0.96)
- Agent Client Protocol —résout→ le couplage étroit entre agents de codage et éditeurs (AFFIRMATION, 0.95)
- couplage agent-éditeur —s_oppose_à→ l'interopérabilité par défaut (AFFIRMATION, 0.93)
- Agent Client Protocol —réduit→ l'integration overhead, la compatibilité limitée et le verrouillage développeur (AFFIRMATION, 0.94)
- Agent Client Protocol —utilise→ JSON-RPC sur stdio (TECHNOLOGIE, 0.95)
- Agent Client Protocol —utilise→ HTTP ou WebSocket pour les agents distants (TECHNOLOGIE, 0.9)
- Agent Client Protocol —est_basé_sur→ les représentations JSON de Model Context Protocol (AFFIRMATION, 0.93)
- Agent Client Protocol —utilise→ Markdown (TECHNOLOGIE, 0.92)
- Agent Client Protocol —permet→ l'affichage de diffs et autres éléments d'UX propres au codage agentique (AFFIRMATION, 0.9)
- Zed Industries —a_créé→ Agent Client Protocol (TECHNOLOGIE, 0.9)
- JetBrains —collabore_avec→ Zed Industries (ORGANISATION, 0.88)
- Agent Client Protocol —publie→ une spécification versionnée v1 (Latest) et v2 (Draft) (AFFIRMATION, 0.9)
- ACP Registry —fait_partie_de→ Agent Client Protocol (TECHNOLOGIE, 0.88)
- Agent Client Protocol —affirme_que→ le support complet des agents distants est encore un travail en cours (AFFIRMATION, 0.93)

---
Canonical: https://www.thekb.eu/en/fiches/agentclientprotocol-introduction-2026-08-02/