ACP: Il Protocollo per Usare Qualsiasi Agente nel Tuo IDE

Claude Code funziona in Zed. E in JetBrains. E in Neovim. E in Emacs. Ma non perché Anthropic abbia scritto un plugin per ciascuno di questi editor.

Funziona perché esiste un protocollo che gli dice come parlare con qualsiasi IDE. Un protocollo che fa per gli agenti AI quello che LSP ha fatto per i language server: elimina il problema della moltiplicazione.

Si chiama Agent Client Protocol (ACP). È open source, ha 30+ agenti compatibili, 13+ editor supportati, e in sette mesi ha raggiunto un livello di adozione che LSP ci ha messo cinque anni a ottenere. Ma ha anche un grande assente — e qualche problema serio.

Il Problema: N per M

Se hai 10 editor e 15 agenti AI, senza uno standard servono 150 integrazioni custom. Ogni agente deve costruire un plugin per ogni editor. Ogni editor deve capire come dialogare con ogni agente.

È lo stesso problema M x N che abbiamo già visto con MCP per i tool, e con A2A per la comunicazione tra agenti. Solo che qui il collo di bottiglia è l'interfaccia: l'IDE dove scrivi codice ogni giorno.

Con ACP, ogni agente implementa il protocollo una volta. Ogni editor lo supporta una volta. E qualsiasi combinazione funziona.

10 + 15 = 25 implementazioni. Non 150.

Nathan Sobo — co-fondatore di Atom, lo stesso editor su cui è nato VS Code — ha creato ACP con Zed Industries. Google è entrato come partner iniziale con Gemini CLI. E nel giro di pochi mesi, l'ecosistema è esploso.

Cos'è ACP: l'LSP degli Agenti

Il Language Server Protocol (LSP) è uno degli standard più importanti nella storia degli editor. Prima di LSP, ogni IDE doveva implementare il supporto per ogni linguaggio di programmazione: autocompletamento, go-to-definition, errori inline. Con LSP, un language server implementa la logica una volta, e qualsiasi editor la usa.

ACP replica lo stesso modello, ma per gli agenti AI. Invece di standardizzare "come un editor capisce un linguaggio", standardizza "come un editor comunica con un agente".

L'analogia è precisa:

Se hai vissuto l'era pre-LSP — quando Eclipse aveva il suo parser Java, Visual Studio il suo, e ogni editor faceva tutto da zero — sai quanto LSP ha cambiato le cose. ACP vuole fare lo stesso salto per gli agenti.

Come Funziona: Architettura Tecnica

ACP usa JSON-RPC 2.0 su stdio. In pratica: l'editor spawna l'agente come sottoprocesso, e i due comunicano tramite messaggi JSON su stdin/stdout.

Nessun server web, nessuna porta aperta, nessun networking. L'agente è un processo figlio dell'editor. Semplice e sicuro.

Comunicazione bidirezionale

Il protocollo è session-based con una state machine che gestisce il ciclo di vita della sessione. L'editor manda richieste all'agente. L'agente manda richieste all'editor. Entrambi possono iniziare la comunicazione.

Questo è fondamentale: l'agente non è un tool passivo che risponde a comandi. Può chiedere all'editor di mostrare un diff, aprire un file, chiedere una conferma all'utente.

Il modello di permessi

Ecco la parte più importante dal punto di vista della sicurezza: l'agente non accede direttamente al filesystem. Tutto passa per l'editor.

Vuole leggere un file? Lo chiede all'editor. Vuole modificare codice? Lo chiede all'editor. Vuole eseguire un comando nel terminale? Lo chiede all'editor.

L'editor è il gatekeeper. Può mostrare un prompt di conferma, filtrare richieste pericolose, limitare l'accesso a certe directory. L'agente non ha mai accesso diretto alla macchina dell'utente.

Integrazione con MCP

Al momento della creazione di una nuova sessione (session/new), l'editor passa all'agente gli endpoint dei server MCP configurati. L'agente può quindi usare i tool MCP — database, API, servizi — attraverso il canale ACP.

In questo modo ACP e MCP lavorano insieme: ACP gestisce il dove (l'IDE), MCP gestisce il cosa (i tool). Sono complementari per design.

Chi Lo Supporta: Editor

Tredici editor supportano ACP a marzo 2026. Alcuni nativamente, altri tramite plugin community.

Il dato che salta all'occhio: VS Code, l'editor più usato al mondo, non ha supporto nativo. Ne parliamo tra poco.

Chi Lo Supporta: Agenti

La lista degli agenti compatibili supera i 30. Ecco i principali:

Un punto notevole: Cursor in JetBrains. Dal 4 marzo 2026, puoi usare Cursor — che è un fork di VS Code — come agente all'interno degli IDE JetBrains, grazie ad ACP. È un tipo di integrazione cross-editor che prima era semplicemente impossibile.

Lo Stack dei Protocolli: ACP vs MCP vs A2A

Tre protocolli, tre layer diversi. Non sono concorrenti — sono complementari. Come citano dal team di Goose: "MCP handles the what, while ACP handles the where."

Un sistema completo potrebbe usare tutti e tre: l'agente vive nell'IDE (ACP), usa tool esterni (MCP), e coordina con altri agenti (A2A). Tre standard che si incastrano.

Per chi vuole approfondire il concetto di tool use — come gli agenti decidono quali strumenti usare e quando — ne abbiamo parlato in dettaglio.

L'Elefante nella Stanza: VS Code e Microsoft

VS Code ha il 65%+ di market share tra gli editor. Ed è l'unico dei grandi a non avere supporto nativo ACP.

Esistono estensioni community, ma Microsoft non ha mai annunciato integrazione ufficiale. E la ragione è ovvia: GitHub Copilot.

Microsoft ha investito miliardi in OpenAI e costruito Copilot come prodotto integrato in VS Code. Supportare ACP significherebbe aprire la porta a qualsiasi agente concorrente — Claude Code, Gemini CLI, Goose — con la stessa esperienza utente di Copilot. Zero incentivi commerciali.

È una situazione curiosa. Microsoft partecipa alla Agentic AI Foundation (che governa MCP). GitHub Copilot è tra gli agenti compatibili con ACP. Ma VS Code, l'editor controllato da Microsoft, resta chiuso.

Il risultato pratico: se usi VS Code e vuoi provare ACP, ti servono estensioni non ufficiali. Funzionano, ma non avrai mai l'integrazione profonda che ottieni in Zed o JetBrains.

Ed è qui che ACP diventa interessante in ottica strategica. Per anni gli editor "minori" — Zed, Neovim, Helix, Emacs — hanno lottato contro lo strapotere di VS Code, che aveva più estensioni, più community, più tutto. ACP ribalta la dinamica: adesso sono loro ad avere il supporto nativo per gli agenti AI. E con il coding assistito dall'AI che diventa sempre più centrale nel workflow quotidiano, questa potrebbe essere la feature che sposta utenti.

Attenzione ai Nomi: Due ACP Diversi

C'è un problema di naming che genera confusione. Esistono due protocolli chiamati ACP:

1. Agent Client Protocol — quello di questo articolo, creato da Zed Industries e JetBrains, per la comunicazione editor-agente
2. Agent Communication Protocol — creato da IBM, per la comunicazione tra agenti AI

Il secondo (IBM) è stato di fatto assorbito da A2A (Agent-to-Agent di Google) e non è più sviluppato attivamente. Ma se cerchi "ACP protocol" su Google, trovi risultati per entrambi. Quando leggi documentazione o articoli, verifica sempre quale dei due stanno descrivendo.

Per chiarezza: in questo blog, quando diciamo ACP, intendiamo sempre l'Agent Client Protocol di Zed/JetBrains.

Lo Stato Attuale: Numeri e Limiti

I numeri

La timeline

In sette mesi: da repo vuoto a 13+ editor e 30+ agenti. LSP, per raggiungere adozione comparabile, ha impiegato circa cinque anni. La velocità è impressionante.

I limiti reali

Non è tutto rose. Siamo ancora alla v0.x — il protocollo può cambiare in modo non retrocompatibile. Alcune criticità concrete:

Stabilità. Breaking change tra versioni. Se costruisci un'integrazione oggi, potresti doverla aggiornare domani.

Windows. Il supporto WSL non è ancora completo. Se lavori su Windows senza WSL, potresti incontrare problemi con certi agenti.

Bug degli agenti. Il protocollo standardizza la comunicazione, non la qualità dell'agente. Se un agente ha un bug nel suo reasoning, ACP non lo risolve. La pipe è pulita, ma l'acqua dipende dalla sorgente.

Standardizzazione prematura? Qualcuno nella community cita il classico XKCD "Standards": 14 standard in competizione, ne creiamo uno nuovo per unificarli — ora ci sono 15 standard. È una critica legittima, anche se i numeri di adozione sembrano darle torto.

Docker che ha annunciato il supporto con cagent a dicembre 2025 è un segnale forte. Quando Docker adotta uno standard — come ha fatto con LSP e MCP — tende a validarne la traiettoria.

Cosa Significa per Chi Sviluppa

ACP cambia il workflow in modi concreti.

Libertà di scelta. Non sei più bloccato con l'agente del tuo editor. Usi JetBrains? Puoi scegliere tra Claude Code, Gemini CLI, Cursor, Goose — tutti attraverso la stessa interfaccia. L'agente diventa un componente intercambiabile, come il tema o il font.

Editor minori, agenti maggiori. Se usi Neovim o Emacs per scelta, non sei più cittadino di serie B. ACP ti dà accesso allo stesso catalogo di agenti disponibili in JetBrains.

Portabilità delle competenze. Impari a lavorare con un agente, e quel workflow funziona in qualsiasi editor. Non devi reimparare le interfacce ogni volta che cambi ambiente.

Il caveat importante. Se usi VS Code e sei soddisfatto di Copilot, ACP non cambia molto per te — oggi. Ma se usi un altro editor, o se vuoi provare agenti diversi, ACP è quello che rende tutto possibile.

Il protocollo è giovane, la v1.0 non è ancora arrivata, e l'assenza di VS Code è un limite reale. Ma la direzione è chiara: nel futuro degli IDE, l'agente AI non sarà un plugin proprietario — sarà un servizio intercambiabile che parla un linguaggio comune.

LSP ci ha messo cinque anni. ACP ha fretta.

Fonti:

1. Agent Client Protocol — Repository GitHub (2.4k stelle)
2. Nathan Sobo — "Bring Your Own Agent to Zed" (agosto 2025)
3. JetBrains — "Bring your own AI agent to JetBrains IDEs" (dicembre 2025)
4. Goose/Block — "Intro to Agent Client Protocol" (ottobre 2025)
5. Docker — "Building a Common Language for Agents and IDEs" (dicembre 2025)
6. Cursor — "Cursor is now available in JetBrains IDEs" (marzo 2026)
7. XKCD 927 — Standards