Il panorama dei protocolli per agenti AI sta vivendo una fase di proliferazione senza precedenti, simile a quella che ha caratterizzato i primi anni del web o l'era dei servizi REST. Negli ultimi diciotto mesi sono stati pubblicati quattro protocolli significativi: il Model Context Protocol (MCP) di Anthropic, l'Agent Communication Protocol (ACP) di IBM Research, l'Agent2Agent (A2A) di Google e l'Agent Network Protocol (ANP) di un gruppo indipendente. A prima vista sembra caos, ma osservando più da vicino emerge una stratificazione chiara. Ogni protocollo risolve un livello diverso dello stack, non compete per la stessa fetta. Il problema reale, oggi, non è quale protocollo scegliere, ma cosa manca ancora: il trasporto peer-to-peer per agenti che devono comunicare oltre i confini di cloud, reti domestiche e periferie.
Il Livello delle Chiamate a Strumenti
MCP ha già vinto la battaglia per il tool calling. Definisce come un modello scopre le funzioni esposte da un server, come invocarle e come interpretare la risposta. È un contratto RPC tipizzato tra un client modello e un server strumento, funzionante su HTTP. La Linux Foundation ha confermato oltre 10.000 server MCP pubblici attivi e 164 milioni di download mensili dell'SDK Python entro aprile 2026. La standardizzazione a questo livello è di fatto completata. Le squadre di sviluppo possono adottare MCP oggi con un rischio bassissimo, come sottolineato anche nella guida operativa al Cyber Resilience Act, dove l'integrazione di protocolli standardizzati è un requisito per la conformità.
Sponsored Protocol
Il Livello di Coordinamento dei Compiti
A2A colma un vuoto che MCP lascia aperto. Mentre MCP definisce come un agente chiama uno strumento, A2A definisce come due agenti si delegano un compito. Introduce Agent Cards (annunci di capacità), stati del ciclo di vita del task e tre modalità di interazione: sincrona, in streaming e asincrona. Google ha donato A2A alla Linux Foundation nel giugno 2025, e i team AI enterprise lo hanno adottato ampiamente. Per la coordinazione multi-agente, adottare A2A oggi è ragionevole, con l'aspettativa che il protocollo evolverà. Questo si allinea con le raccomandazioni della normativa NIS2, che richiede un approccio architetturale orientato alla sicurezza e all'interoperabilità.
Il Livello di Messaggistica Leggera e Scoperta
ACP e ANP completano lo stack. ACP è un formato di envelope per messaggi, leggero e stateless, utile quando non serve la gestione completa del ciclo di vita del task offerta da A2A. ANP si concentra su scoperta e identità, usando Identificatori Decentralizzati (DID) e grafi JSON-LD per descrivere le capacità degli agenti, gettando le basi per mercati di agenti decentralizzati senza registro centrale. Lo stack emergente è chiaro: scoperta delle capacità via ANP, coordinamento dei task via A2A, chiamate a strumenti via MCP e messaggistica leggera via ACP. Questi livelli si complementano, non competono.
Sponsored Protocol
Il Problema del Trasporto Che Resta
Ogni protocollo fin qui descritto viaggia su HTTP. Questo riflette le origini dei team: team di ricerca, provider API e aziende enterprise per cui HTTP è un assunto indiscutibile. Ma in produzione, HTTP presuppone un server raggiungibile. L'88% dei dispositivi di rete si trova dietro NAT (Network Address Translation), dove non esiste un server raggiungibile senza un relay. Per flotte di agenti che devono instradare task direttamente tra peer attraverso confini cloud, reti domestiche e deployment edge, questa centralizzazione forza ogni messaggio attraverso infrastrutture di relay, aggiungendo latenza, costi e un punto di guasto. I protocolli applicativi risolvono la semantica di ciò che gli agenti si dicono; non risolvono come si trovano e stabiliscono connessioni dirette. Questo è un problema di livello sessione (Layer 5 del modello OSI) che nessuno di MCP, A2A, ACP o ANP affronta.
Sponsored Protocol
Le tecnologie per risolverlo esistono già. L'UDP hole-punching con STUN (Session Traversal Utilities for NAT) funziona per circa il 70% delle topologie di rete. X25519 Diffie-Hellman e AES-256-GCM forniscono crittografia autenticata senza necessità di un'autorità di certificazione. QUIC (RFC 9000) o protocolli a finestra scorrevole su UDP offrono consegna affidabile senza il blocco head-of-line di TCP. Sono gli stessi primitivi usati da WireGuard per VPN e da WebRTC per flussi multimediali browser-to-browser. Quello che cambia nel contesto degli agenti è il routing basato sulle capacità: un agente deve poter chiedere "quali peer hanno dati forex in tempo reale?" e ricevere una lista di agenti specializzati attivi. Questo è più vicino a un service registry che a DNS, ed è un'estensione naturale della filosofia di ANP applicata al trasporto.
Alcuni progetti stanno assemblando questi pezzi. Pilot Protocol è il più completo tra le specifiche pubblicate, con un Internet-Draft IETF che copre indirizzamento, stabilimento di tunnel e NAT traversal per reti di agenti. libp2p fornisce una fondazione robusta con primitivi simili. Il gruppo di lavoro QUIC dell'IETF sta sviluppando estensioni per NAT traversal che saranno rilevanti. Secondo fonti autorevoli come Wikipedia, l'ecosistema MCP è già in fase di produzione, ma il trasporto è ancora in evoluzione.
Sponsored Protocol
Come Convergerà il Trasporto
I protocolli applicativi HTTP-based (MCP, A2A) stanno convergendo su versioni stabili. Nei prossimi 12 mesi vedremo indurimento produttivo, miglioramenti di sicurezza, server MCP stateless per scalabilità orizzontale e migliore federazione A2A. I livelli di tool-calling e coordinamento task sono in gran parte risolti. Il livello di trasporto è da 18 a 24 mesi indietro. Ci si aspetta un periodo di diversità implementativa, seguito da consolidamento attorno a poche implementazioni quando i dati empirici su prestazioni e affidabilità si accumuleranno. I percorsi di standardizzazione IETF e W3C produrranno probabilmente qualcosa nella finestra 2027-2028, quando una o due implementazioni open-source avranno accumulato abbastanza deployment produttivi da stabilire de facto standard prima della specifica formale.
Sponsored Protocol
Per i leader tecnici che prendono decisioni architetturali oggi, l'implicazione pratica è l'adozione a strati. I protocolli applicativi sono sufficientemente stabili per essere usati. L'adozione di MCP è a basso rischio. L'adozione di A2A per la coordinazione multi-agente è ragionevole. Il trasporto è il livello dove o si costruisce qualcosa di custom con l'intenzione di sostituirlo, o si valutano implementazioni early sapendo che lo spazio è ancora in movimento. I team che avranno la maggiore leva quando il trasporto si stabilizzerà sono quelli che hanno progettato i propri sistemi di agenti con una netta separazione tra semantica applicativa (MCP, A2A) e trasporto (qualunque cosa stia sotto). Una separazione pulita è economica da implementare ora e costosa da retrofitare dopo, una lezione che l'era dei microservizi ha insegnato a chiunque abbia provato ad aggiungere osservabilità o circuit breaking a sistemi che non ne avevano.
