Server rack con cavi di rete, rappresentazione dell'infrastruttura di trasporto per agenti AI

Protocolli per agenti AI: MCP, A2A e il problema del trasporto ancora irrisolto

Il mondo dei protocolli per agenti AI sta vivendo una fase di proliferazione che ricorda da vicino la storia del distributed computing: tanti standard competono, poi il mercato converge. MCP, A2A, ACP e ANP sono stati pubblicati negli ultimi 18 mesi. Ognuno risolve un pezzo diverso del puzzle, ma c’è un buco grosso: il trasporto.

MCP (Model Context Protocol, Anthropic, fine 2024) è di fatto l’interfaccia per tool calling. Un modello scopre quali funzioni espone un server, le invoca e interpreta la risposta. Il Linux Foundation ha certificato oltre 10.000 server MCP pubblici attivi e 164 milioni di download mensili dell’SDK Python. È già lo standard consolidato per questo livello.

A2A (Agent2Agent, Google, aprile 2025) definisce invece come due agenti si delegano un task. Introduce Agent Cards, stati del ciclo di vita e tre modalità di interazione. Donato alla Linux Foundation nel giugno 2025, è ampiamente adottato dai team enterprise perché colma un vuoto che MCP lascia aperto.

ACP (IBM Research, marzo 2025) è un formato di messaggio leggero per scambi semplici senza la complessità di A2A. ANP (agent network protocol) si occupa di scoperta e identità, usando Decentralized Identifiers (DID) e grafi JSON-LD. Lo stack emergente è complementare: scoperta via ANP, coordinazione via A2A, tool calling via MCP, messaggistica leggera via ACP.

Ma tutti questi protocolli girano su HTTP. HTTP presuppone un server raggiungibile. L’88% dei dispositivi di rete sta dietro NAT (network address translation), senza un relay centrale non c’è connessione diretta. E il relay aggiunge latenza, costi e un punto di guasto in più. Questo è un problema di livello sessione (Layer 5 OSI), che nessuno dei protocolli applicativi affronta.

Le tecnologie per risolverlo esistono: UDP hole-punching con STUN funziona per circa il 70% delle topologie, X25519 e AES-256-GCM per la crittografia autenticata senza autorità di certificazione, QUIC come trasporto affidabile su UDP. La differenza rispetto a WireGuard o WebRTC è che gli agenti devono trovare peer non per hostname, ma per capacità: “qual è il peer che ha dati forex in tempo reale?” È un registro di servizi, non DNS. ANP, esteso al trasporto, sarebbe la strada naturale.

Progetti come Pilot Protocol (più completo, con Internet-Draft IETF già scritto) e libp2p (collaudato, stessi primitivi) stanno assemblando questi pezzi. L’IETF sta sviluppando estensioni NAT traversal per QUIC che saranno rilevanti.

Nei prossimi 12-18 mesi i protocolli applicativi si stabilizzeranno (MCP e A2A sono già quasi definitivi), mentre il livello di trasporto vivrà una fase di sperimentazione. La standardizzazione IETF/W3C arriverà probabilmente nel 2027-2028, preceduta da una o due implementazioni open source che diventeranno standard de facto. Per chi sceglie oggi: adottare MCP è a basso rischio, A2A è ragionevole, il trasporto va progettato con una netta separazione dai livelli applicativi — ripensarlo dopo costa molto di più.

Articoli simili