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.
#Agent Client Protocol#ACP#open protocol
**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.
Tech-watch note by **Didier Girard** dated **August 2, 2026**, prompted by a colleague's question ("what is ACP?") that turns out to address a problem that is not terminological but **documentary**. **Three protocols compete for the acronym**, with no technical overlap whatsoever: **Agent Client Protocol** (client ↔ agent — Zed, August 2025, JSON-RPC 2.0 over stdio, Apache-2.0, "what LSP did for languages"), **Agentic Commerce Protocol** (agent ↔ merchant — OpenAI + Stripe, Sept. 29, 2025, facing Google's **UCP** of Jan. 11, 2026 backed by **AP2**), and **Agent Communication Protocol** (agent ↔ agent — IBM Research / BeeAI, marginal but polluting searches). **The core of the note is not the disentangling but its observed failure**: the author searches "ACP" in his tech-watch knowledge base and gets **twelve results, all about the commerce protocol, zero about Zed's** — *"our watch agents had indexed the acronym without disambiguating it"*. Hence a knowledge-engineering rule: ***"never index a bare acronym"*** — the entity is "Agent Client Protocol", "ACP" is **only an alias**, carried by three distinct entities. A structuring clarification follows (**MCP connects an agent to its tools, ACP connects a client to an agent; the two stack**), then the textbook case: **Buzz**, published by **Block** on July 21, 2026 under Apache-2.0 — a self-hostable workspace built on **Nostr**, where every human or agent participant is a **keypair** and every message, workflow step, or git push is a **signed event** in an append-only log. A fully protocol-based architecture (`buzz-acp` an ACP harness over stdio, `buzz-agent` an ACP agent calling an LLM, `buzz-dev-mcp` an MCP server for shell + editing), hence the agent-agnosticism: **Goose, Claude Code, and Codex** plug in through the same harness, and **Hermes** (Nous Research) connected to it without Block writing a single line — *"N+M instead of N×M, running in production"*. The note closes on the question of the **Claude subscription** versus third-party agents, with a five-stage 2026 timeline and a **design rule** that applies beyond this case: the line is not legal but **architectural** — ***"who is consuming, and on whose behalf"*** (an `owner-only` agent consumes your subscription for you; an `anyone` agent in a shared channel routes your colleagues' requests through your account). ⭐ **Verification carried out on this corpus**: the thesis holds, and more starkly than the note asserts — not only is "Agent Client Protocol" **completely absent** from it, but the bare acronym `ACP` **is already typed as an entity** in two fiches, and the KB page `Agentic-Commerce-Protocol` **already attributes the protocol to Google** when it belongs to OpenAI + Stripe. The collision described is not a risk yet to come: it has **already produced an attribution error** in the graph.
**Didier Girard** — auteur de la note. Écrit ici depuis la position de **praticien de la veille outillée** : le déclencheur est une question de collègue · le matériau principal est le comportement observé de sa propre base de connaissances · et la conclusion est une **règle de curation** adoptée en interne. Le texte alterne donc deux voix — l'explicateur de protocoles et l'ingénieur de la connaissance qui constate un défaut chez lui et en tire une norme.
**Boris Cherny** (Creator & Head of Claude Code @Anthropic) publishes a framework table on LinkedIn, **« Steps of AI Adoption »**, mapping an engineering team's adoption of agentic AI across **5 stages (0→4)**, each characterized by an **order of magnitude of agents driven** and a **transformation of the engineer's role**: **0 Gated** (0 agents, locked-down access), **1 Assisted** (~1 agent — "you + one agent", supervised pair programming), **2 Parallel** (~10 agents — **orchestrator**), **3 Supervised autonomy** (~100 agents — **manager of managers**, an org tree), **4 AI-native** (~1,000+ agents — **VP steering by intent**). The table crosses five columns: number of agents, *what it looks like*, *the bottleneck*, *the products that help*, *the guardrails*. **Central thesis**: consuming more tokens does not move you up a level — advancing to the next stage requires **identifying and breaking the next bottleneck** AND **building the next set of guardrails**. Concretely: giving Claude a trustworthy **self-verification loop** (tests + build + lint + e2e on a real environment), enabling **Auto mode** (avoiding blocking permission prompts), making **code review and security review the default**, adopting multi-agent interfaces (Agent view CLI, Desktop, iOS/Android apps, Tag), then `/loop`, `/batch`, `/goal`, **dynamic workflows** and **worktree isolation** for subagents. On steering: usage (dashboard) measures **activity, not return**; the right question is *"would we have spent engineering effort on this anyway? if so, how many manual engineer-hours would it have cost?"* — that's the ROI. The real payoff arrives when **fixing and maintaining happens in the background** and teams focus on *building*. Anthropic sits at **stage 3, heading toward 4**; Boris Cherny states he has personally reached **level 4**.
#Boris Cherny#Claude Code#Anthropic
Boris Cherny (Creator & Head of Claude Code @Anthropic)