# 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 vivo**: la scheda è datata in base alla sua 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 personalizzata per ogni agente, ogni agente deve implementare API specifiche dell'editor. Tre conseguenze nominate: **onere di integrazione** (ogni coppia agente-editor richiede lavoro personalizzato), **compatibilità limitata** (un agente raggiunge solo un sottoinsieme di editor), **dipendenza dal fornitore per lo 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 beneficio 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 distribuzione, ed è il punto più sottovalutato**: gli agenti **locali** girano come sottoprocesso dell'editor via **JSON-RPC su stdio**, ma gli agenti **remoti** sono previsti su **HTTP o WebSocket** — supporto dichiarato *« work in progress »*, con collaborazione in corso con 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 della codifica agentica (la visualizzazione dei **diff** è l'esempio riportato); il formato predefinito per il testo leggibile è **Markdown**, scelto affinché l'editor non sia tenuto a renderizzare HTML. **Due osservazioni su governance e versioning** tratte dalla pagina stessa, non 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, accanto a un **ACP Registry**, alle **RFD**, a una sezione **Community**, a **Publications**, **Updates** e una pagina **Brand**. Librerie ufficiali annunciate: **Kotlin, Java, Python, Rust, TypeScript**, più un percorso community.

## 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 editor-agente, LSP, Language Server Protocol, JSON-RPC, stdio, sottoprocesso, agenti locali, agenti remoti, HTTP, WebSocket, work in progress, MCP, Model Context Protocol, riuso delle rappresentazioni JSON, tipi personalizzati, visualizzazione diff, Markdown, onere di integrazione, compatibilità limitata, dipendenza dal fornitore per lo sviluppatore, dipendenza dal fornitore per lo 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 introduttiva di una **specifica tecnica aperta**, nel registro di un *organismo di standardizzazione* piuttosto che del marketing di prodotto. Molto breve — due sezioni (`Why ACP?`, `Overview`) — e interamente costruita per essere citata.

**Stile**: la forma canonica del pitch per protocollo aperto, in tre movimenti meccanici: (1) **nominare l'accoppiamento esistente**, (2) **enumerare i suoi 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 in cui la dimostrazione è ancora da fare. Economia di mezzi notevole — nessuna promessa quantificata, nessun beneficio di business, nessuna menzione di un concorrente.

Due marcatori di misura che costruiscono fiducia: l'ammissione che il supporto agli agenti remoti è *« a work in progress »*, e la **giustificazione basata sui vincoli** per la scelta di Markdown (*« without requiring that the code editor is capable of rendering HTML »*) — una decisione di design spiegata da ciò che **non** impone all'implementatore, che è 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. »* Da questa constatazione discende l'intero protocollo.
- **I tre costi dell'accoppiamento** (struttura da riutilizzare così com'è nelle presentazioni): **onere di integrazione** — ogni combinazione agente×editor richiede lavoro personalizzato; **compatibilità limitata** — un agente raggiunge solo un sottoinsieme di editor; **dipendenza dal fornitore per lo sviluppatore** — scegliere un agente significa accettarne le interfacce. I tre sono costi **diversi** (produzione, distribuzione, libertà), non tre formulazioni dello stesso costo.
- **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 **il punto in cui serve cautela**: LSP standardizza uno scambio in gran parte **deterministico** (posizioni, simboli, diagnostiche); 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 infrastrutture separate, **HTTP o WebSocket**. Dichiarato *« work in progress »*, con collaborazione attiva con 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.
- **Il rapporto 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 suoi strumenti) — vero sul piano architetturale, ma **incompleto**: ACP **prende in prestito le strutture dati di MCP**. I due protocolli non sono solo vicini, condividono un vocabolario di serializzazione. Vedi [[girard-acp-deux-protocoles-un-sigle-2026-08-02]] per la distinzione funzionale.
- **Estensioni specifiche alla codifica agentica**: ACP aggiunge *« custom types for useful agentic coding UX elements, like displaying diffs »*. È ciò che giustifica l'esistenza di ACP **in aggiunta 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 motivazione dichiarata**: *« which allows enough flexibility to represent rich formatting without requiring that the code editor is capable of rendering HTML »*. Una decisione di design giustificata dall'**onere che risparmia all'implementatore** — l'istinto giusto per un protocollo in cerca di adozione. Da notare per chiunque progetti 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 è corroborato dalla fonte primaria**. Citare **v1 / v2 draft**.
- **Correzione sulla governance**: l'espressione "Zed l'ha lanciato poi 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 orfano o di una documentazione di prodotto. La formulazione corretta: **apertura reale e co-governance, non spossessamento**.
- **Segnale d'ecosistema**: librerie ufficiali in **Kotlin, Java, Python, Rust, TypeScript** + un percorso community. La coppia **Kotlin/Java** è il marcatore JetBrains — la presenza di entrambe 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 **attrezzata per agenti**. Coerenza dell'impostazione, e un segnale debole su ciò che 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 del testo, **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 / da collegare**: 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 il proprio pricing; il disaccoppiamento descritto si collega al contratto di portabilità analizzato in janakiram-agent-platform-portability-contract-2026-07-20; un'implementazione di riferimento sul lato prodotto in block-goose-mcp-ui-future-agentic-interfaces-2025-08-25. **Disambiguazione obbligatoria**: qui, "ACP" si riferisce solo all'**Agent Client Protocol**. Non digitare mai la sigla come entità — vedi `docs/solutions/conventions/sigles-jamais-entites-graphe.md`.

## RésuméDe400mots

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

**Il problema.** *« AI coding agents and editors are tightly coupled but interoperability isn't the default. »* Ogni editor deve costruire un'integrazione personalizzata per ogni agente che vuole supportare, e ogni agente deve implementare le API specifiche di ogni editor. Ne derivano tre costi distinti: **onere di integrazione** (ogni combinazione agente-editor richiede lavoro specifico), **compatibilità limitata** (un agente raggiunge solo una frazione degli editor) e **dipendenza dal fornitore per lo 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 sia **principalmente nel proprio editor** e ricorra a un agente per un compito specifico. Due modalità di distribuzione: gli agenti **locali** girano come sottoprocesso dell'editor e comunicano via **JSON-RPC su stdio**; gli agenti **remoti**, ospitati nel cloud o su infrastrutture separate, comunicano via **HTTP o WebSocket** — supporto dichiarato *« a work in progress »*, con collaborazione attiva con piattaforme agentiche. La seconda modalità viene regolarmente omessa dalla 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 della codifica agentica — la visualizzazione dei **diff** è l'esempio riportato. Il formato predefinito per il testo leggibile è **Markdown**, scelto proprio affinché l'editor non sia tenuto 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**, accanto a un **ACP Registry**, alle **RFD**, a una sezione Community, Publications, Updates e 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/