# agentclientprotocol-introduction-2026-08-02

## Veille

Landing page della **specifica ufficiale** dell'**Agent Client Protocol (ACP)** (`agentclientprotocol.com/get-started/introduction`), consultata il **2 agosto 2026**. Non si tratta di un articolo datato ma di un **artefatto vivente**: la scheda è datata in base all'osservazione, non a una data di pubblicazione. **Dichiarazione di missione in una frase**: *"The Agent Client Protocol (ACP) standardizes communication between code editors/IDEs and coding agents and is suitable for both local and remote scenarios."* **Il problema enunciato** sta in tre righe: gli agenti di codifica e gli editor sono **strettamente accoppiati** e *"interoperability isn't the default"* — ogni editor deve costruire un'integrazione su misura per ogni agente, ogni agente deve implementare API specifiche dell'editor. Tre conseguenze nominate: **sovraccarico di integrazione** (ogni coppia agente-editor richiede un lavoro su misura), **compatibilità limitata** (un agente raggiunge solo un sottoinsieme di editor), **lock-in dello sviluppatore** (*"choosing an agent often means accepting their available interfaces"*). **La soluzione è esplicitamente modellata su LSP** — *"similar to how the Language Server Protocol (LSP) standardized language server integration"* — con un vantaggio reciproco: un agente che parla ACP funziona con **qualsiasi** editor compatibile, un editor che supporta ACP accede all'**intero** ecosistema di agenti ACP. **Due modalità di deployment, ed è il punto più sottovalutato**: gli agenti **locali** girano come sottoprocesso dell'editor su **JSON-RPC su stdio**, ma gli agenti **remoti** sono previsti su **HTTP o WebSocket** — supporto dichiarato come *"work in progress"*, con una collaborazione in corso con le piattaforme agentiche. **Filiazione tecnica con MCP, più forte di una semplice complementarità**: ACP *"re-uses the JSON representations used in MCP where possible"*, aggiungendo tipi specifici alle esigenze UX dell'agentic coding (la visualizzazione dei **diff** è l'esempio citato); il formato predefinito per il testo leggibile è **Markdown**, scelto affinché l'editor non sia obbligato a renderizzare HTML. ⚠️ **Due osservazioni su governance e versioning** rilevate sulla pagina e assenti dal discorso circostante: la navigazione espone **v1 (Latest)** e **v2 (Draft)** — e **non un "ACP 1.2"** —, e la barra di navigazione collega **Zed Industries *e* JetBrains** allo stesso livello, insieme a un **ACP Registry**, agli **RFD**, a una sezione **Community**, a **Publications**, **Updates** e a una pagina **Brand**. Librerie ufficiali annunciate: **Kotlin, Java, Python, Rust, TypeScript**, più un canale comunitario.

## Titre Article

Agent Client Protocol — Introduction

## Date

2026-08-02

## URL

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

## Keywords

Agent Client Protocol, ACP, protocollo aperto, specifica, interoperabilità, disaccoppiamento agente-editor, LSP, Language Server Protocol, JSON-RPC, stdio, sottoprocesso, agenti locali, agenti remoti, HTTP, WebSocket, work in progress, MCP, Model Context Protocol, riutilizzo delle rappresentazioni JSON, tipi personalizzati, visualizzazione dei diff, Markdown, sovraccarico di integrazione, compatibilità limitata, lock-in dello sviluppatore, lock-in dello sviluppatore, N+M, ecosistema di agenti, Zed Industries, JetBrains, ACP Registry, registro degli agenti, RFD, request for discussion, governance del protocollo, v1 latest, v2 draft, versioning della specifica, librerie client, Kotlin, Java, Python, Rust, TypeScript, Mintlify, documentazione vivente, 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

**Profilo**: pagina di introduzione a una **specifica tecnica aperta**, nel registro di un *ente di standardizzazione* piuttosto che di marketing di prodotto. Molto breve — due sezioni (`Why ACP?`, `Overview`) — e costruita interamente per essere citata.

**Stile**: la forma canonica del pitch del protocollo aperto, in tre mosse meccaniche: (1) **nominare l'accoppiamento esistente**, (2) **enumerarne i costi** in tre punti simmetrici, (3) **enunciare l'analogia legittimante**. L'analogia con LSP fa tutto il lavoro retorico: porta un precedente già accettato dal lettore (LSP ha effettivamente disaccoppiato editor e linguaggi) in un dominio dove la dimostrazione è ancora da fare. Economia di mezzi notevole — nessuna promessa quantificata, nessun beneficio commerciale, nessun riferimento a un concorrente.

Due marcatori di sobrietà che costruiscono fiducia: l'ammissione che il supporto agli agenti remoti è *"a work in progress,"* e la giustificazione **per vincolo** della scelta di Markdown (*"without requiring that the code editor is capable of rendering HTML"*) — una scelta di design spiegata da ciò che **non** impone all'implementatore, l'istinto giusto per un protocollo in cerca di adottanti.

**Frasi marcatrici**: *"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

- **La frase da ricordare**: *"AI coding agents and editors are tightly coupled but interoperability isn't the default."* L'intero protocollo discende da questa osservazione.
- **I tre costi dell'accoppiamento** (struttura da riutilizzare tale e quale nelle presentazioni): **sovraccarico di integrazione** — ogni combinazione agente×editor richiede un lavoro su misura; **compatibilità limitata** — un agente raggiunge solo un sottoinsieme di editor; **lock-in dello sviluppatore** — scegliere un agente significa accettarne le interfacce. I tre sono costi **diversi** (produzione, distribuzione, libertà), non tre formulazioni dello stesso concetto.
- **L'analogia con LSP fa il lavoro**: *"similar to how the Language Server Protocol standardized language server integration."* È efficace perché il precedente è già accettato. ⚠️ Ma è anche **dove serve cautela**: LSP standardizza uno scambio in gran parte **deterministico** (posizioni, simboli, diagnostica); ACP standardizza l'interfaccia di un agente **non deterministico**, che negozia permessi, produce diff e il cui comportamento varia da un'esecuzione all'altra. La forma del problema è la stessa; la natura di ciò che vi transita no. La pagina non discute questo scarto.
- **⭐ Due modalità di trasporto, non una** — il punto più sottovalutato nella copertura secondaria:
- **Agenti locali**: sottoprocesso dell'editor, **JSON-RPC su stdio**. È la modalità nota, quella citata da tutti.
- **Agenti remoti**: ospitati nel cloud o su un'infrastruttura separata, **HTTP o WebSocket**. Dichiarati come *"work in progress,"* con una collaborazione attiva con le piattaforme agentiche. → **Conseguenza**: ACP non è strutturalmente un protocollo "da workstation". La sua traiettoria punta all'agente ospitato, quindi all'enterprise. Riassumere ACP come "JSON-RPC su stdio" ne descrive il presente, non il suo obiettivo.
- **⭐ La relazione con MCP è una filiazione, non una semplice complementarità**: *"The protocol re-uses the JSON representations used in MCP where possible."* Si dice comunemente che "ACP e MCP si sovrappongono" (il client parla ACP con l'agente, l'agente parla MCP con i propri strumenti) — vero dal punto di vista architetturale, ma **incompleto**: ACP **prende in prestito le strutture dati di MCP**. I due protocolli non sono semplicemente vicini, condividono un vocabolario di serializzazione. Vedi [[girard-acp-deux-protocoles-un-sigle-2026-08-02]] per la distinzione funzionale.
- **Le estensioni specifiche dell'agentic coding**: ACP aggiunge *"custom types for useful agentic coding UX elements, like displaying diffs."* È ciò che giustifica l'esistenza di ACP **accanto** a MCP: un diff da approvare non è una chiamata a uno strumento, è un elemento di interfaccia che richiede una decisione umana. **Il protocollo codifica il momento della revisione**, non solo l'esecuzione.
- **Markdown di default, e la ragione dichiarata**: *"which allows enough flexibility to represent rich formatting without requiring that the code editor is capable of rendering HTML."* Una scelta di design giustificata dall'**onere risparmiato all'implementatore** — l'istinto giusto per un protocollo in cerca di adozione. Da notare per chi progetta un protocollo: abbassare il costo d'ingresso sul lato che si vuole reclutare.
- **⚠️ Correzione sul versioning**: la navigazione della specifica espone **`v1` (Latest)** e **`v2` (Draft)**. **Non** espone un "ACP 1.2." Questo numero, che circola nella copertura secondaria (e che era stato registrato come non verificato in [[girard-acp-deux-protocoles-un-sigle-2026-08-02]]), **non è confermato dalla fonte primaria**. Citare **v1 / v2 draft**.
- **⚠️ Correzione sulla governance**: la frase "Zed l'ha lanciato poi l'ha lasciato andare" è troppo forte. La barra di navigazione collega **Zed Industries e JetBrains allo stesso livello**, e la struttura del sito (**ACP Registry**, **RFD**, **Community**, **Publications**, **Updates**, **Brand**) è quella di un **progetto co-governato con un processo**, non di un protocollo o di una documentazione di prodotto abbandonati. L'inquadramento corretto: **apertura reale e co-governance, non abbandono**.
- **Segnale sull'ecosistema**: librerie ufficiali in **Kotlin, Java, Python, Rust, TypeScript** + un canale comunitario. L'abbinamento **Kotlin/Java** è il marcatore JetBrains — la presenza di entrambi segnala che l'implementazione per IDE JVM è di prima classe, non una porta tardiva.
- **Un dettaglio rivelatore**: la pagina si apre con un rimando a **`/llms.txt`** — *"Use this file to discover all available pages before exploring further."* La documentazione di un protocollo per agenti è essa stessa **predisposta per gli agenti**. Coerenza dell'impianto, e un segnale debole su cosa sta diventando la documentazione tecnica.
- **Ciò che la pagina non dice** (da non colmare per inferenza): nessuna data, nessun numero di versione dichiarato nel corpo, **nessuna licenza mostrata su questa pagina**, nessun modello di governance formalizzato, nessun elenco di implementatori. La licenza Apache-2.0 spesso citata per ACP proviene dal repository, **non da questa pagina**.
- **Meta / rimandi incrociati**: fonte primaria per le affermazioni su ACP #1 in [[girard-acp-deux-protocoles-un-sigle-2026-08-02]] (che corregge sul versioning e sfuma sulla governance); da leggere insieme a [[dethlefsen-zed-anthropic-subscription-changes-2026-05-14]], che mostra quanto vale l'opzionalità qui promessa il giorno in cui un fornitore cambia i propri prezzi; il disaccoppiamento qui descritto si collega al contratto di portabilità analizzato in [[janakiram-agent-platform-portability-contract-2026-07-20]]; un'implementazione di riferimento lato prodotto in [[block-goose-mcp-ui-future-agentic-interfaces-2025-08-25]]. ⚠️ **Disambiguazione obbligatoria**: "ACP" qui si riferisce esclusivamente all'**Agent Client Protocol**. Non digitare mai la sigla come entità — vedi `docs/solutions/conventions/sigles-jamais-entites-graphe.md`.

## RésuméDe400mots

Pagina di introduzione alla specifica dell'**Agent Client Protocol**, consultata il 2 agosto 2026. Un artefatto vivente senza data di pubblicazione: la scheda è datata in base all'osservazione.

**Il problema.** *"AI coding agents and editors are tightly coupled but interoperability isn't the default."* Ogni editor deve costruire un'integrazione su misura per ogni agente che vuole supportare, e ogni agente deve implementare le API specifiche di ciascun editor. Ne derivano tre costi distinti: **sovraccarico di integrazione** (ogni combinazione agente-editor richiede un lavoro specifico), **compatibilità limitata** (un agente raggiunge solo una frazione degli editor) e **lock-in dello sviluppatore** — *"choosing an agent often means accepting their available interfaces"*.

**La soluzione.** ACP standardizza la comunicazione agente-editor *"similar to how the Language Server Protocol (LSP) standardized language server integration."* Il beneficio è reciproco, ed è ciò che tiene insieme l'ecosistema: un agente che implementa ACP funziona con qualsiasi editor compatibile; un editor che supporta ACP accede all'intero ecosistema di agenti ACP. *"This decoupling allows both sides to innovate independently."*

**L'architettura.** ACP presuppone che l'utente si trovi **principalmente nel proprio editor** e si rivolga a un agente per un compito specifico. Due modalità di deployment: gli agenti **locali** girano come sottoprocesso dell'editor e comunicano su **JSON-RPC su stdio**; gli agenti **remoti**, ospitati nel cloud o su un'infrastruttura separata, comunicano su **HTTP o WebSocket** — supporto dichiarato come *"a work in progress,"* con una collaborazione attiva con le piattaforme agentiche. La seconda modalità viene sistematicamente omessa nella copertura secondaria, pur tracciando la traiettoria enterprise del protocollo.

**Il legame con MCP** è più stretto di una complementarità architetturale: ACP *"re-uses the JSON representations used in MCP where possible,"* aggiungendo al contempo tipi specifici all'UX dell'agentic coding — la **visualizzazione dei diff** è l'esempio citato. Il formato predefinito per il testo leggibile è **Markdown**, scelto proprio affinché l'editor non sia obbligato a renderizzare HTML.

**Due osservazioni sulla fonte stessa.** La navigazione espone **v1 (Latest)** e **v2 (Draft)** — non l'"ACP 1.2" che circola altrove. E collega **Zed Industries e JetBrains allo stesso livello**, insieme a un **ACP Registry**, agli **RFD**, a una sezione Community, Publications, Updates e a una pagina Brand: la struttura di un progetto co-governato con un processo. Librerie ufficiali in Kotlin, Java, Python, Rust e 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/it/fiches/agentclientprotocol-introduction-2026-08-02/