A2A: gli agenti imparano a parlarsi
Lo standard che fa dialogare agenti costruiti da aziende diverse — e perché è il pezzo mancante accanto a MCP.
Luciano Cipriano
6/25/20264 min read
Ciao a tutti,
Ben arrivati su WikiLuc.
Abbiamo passato un anno intero a celebrare MCP come la soluzione che permette a un agente di parlare con i suoi strumenti. Giusto, ma in fase di review di architetture mi sono accorto che il problema più grande era un altro, e nessuno lo nominava: come fa il mio agente a parlare con il tuo, se sono costruiti da aziende diverse, su framework diversi, con logiche diverse? Senza una risposta, ogni sistema multi-agente resta un'isola. A2A — Agent2Agent — è il tentativo di costruire il ponte tra le isole.
Di cosa parliamo oggi:
La differenza tra MCP (agente↔strumenti) e A2A (agente↔agente)
Cosa risolve l'interoperabilità cross-vendor e perché conta
Quanto è già adottato: i numeri del primo anno
Sicurezza e governance integrate nel protocollo
Partiamo dal problema.
MCP e A2A: due ponti diversi
Cosa intendiamo per A2A
La confusione più comune è mettere MCP e A2A sullo stesso piano. Non lo sono, e capire perché chiarisce tutto. MCP (Model Context Protocol, di Anthropic) standardizza il modo in cui un agente accede a strumenti, dati e contesto: è il ponte tra l'agente e ciò che usa. A2A standardizza il modo in cui due agenti comunicano e collaborano tra loro: è il ponte tra un agente e un altro agente.
Detto in modo diretto: MCP dà all'agente le mani per afferrare gli strumenti, A2A gli dà una lingua per parlare con i suoi simili. Sono complementari, non alternativi. Un sistema multi-agente consistente nel 2026 li usa entrambi — uno per l'accesso alle risorse, l'altro per il coordinamento. È la stessa logica per cui il web ha avuto bisogno sia di HTTP per trasferire pagine sia di standard per farle dialogare tra servizi.
MCP dà all'agente le mani per afferrare gli strumenti. A2A gli dà una lingua per parlare con i suoi simili.
La fine dei silos cross-vendor
Il valore vero di A2A è far cadere una barriera che oggi blocca quasi tutti i progetti ambiziosi: l'incompatibilità tra agenti di fornitori diversi. Finché ogni vendor parla solo la propria lingua, costruire un workflow che mette in fila un agente di Salesforce, uno di SAP e uno interno significa scrivere integrazioni custom fragili, da rifare a ogni aggiornamento. A2A offre un'interfaccia standardizzata e vendor-agnostica: gli agenti si scoprono, si scambiano compiti e collaborano in tempo reale senza che tu debba cucire a mano ogni connessione.
Non è un dettaglio da architetti. È la differenza tra un'azienda che può comporre liberamente i migliori agenti di mercato e una che resta prigioniera di un unico fornitore perché cambiare costa troppo. Lo standard sposta il potere verso chi compone, non verso chi vende il silo.
Quanto è già reale: i numeri del primo anno
Qui A2A esce dalla categoria "bella idea". Lanciato da Google con il contributo di oltre 50 partner iniziali, ad aprile 2026 il progetto — ora ospitato dalla Linux Foundation — ha superato le 150 organizzazioni aderenti, con integrazione profonda nelle piattaforme di Google, Microsoft e AWS e deployment in produzione in più settori: supply chain, servizi finanziari, assicurazioni, IT operations. Tra i contributori non ci sono solo big tech ma anche i grandi system integrator (Accenture, BCG, Deloitte, McKinsey, PwC, TCS) — il segnale che lo standard sta entrando nei progetti enterprise reali, non solo nei repository.
Il fatto che A2A sia passato sotto la Linux Foundation è il punto che mi dà più fiducia: un protocollo di interoperabilità governato da un singolo vendor è una contraddizione in termini. La neutralità della governance è ciò che permette ai concorrenti di adottarlo senza sentirsi in trappola.
Sicurezza e governance: dentro il protocollo, non dopo
Far collaborare agenti autonomi di aziende diverse apre ovviamente un problema di fiducia: chi autorizza cosa, chi risponde di un'azione sbagliata, come si traccia una catena di deleghe tra agenti. A2A integra autenticazione e meccanismi di governance nel protocollo stesso, non come strato aggiunto a posteriori. È la scelta corretta: in un sistema dove gli agenti si passano compiti a vicenda, la sicurezza non può essere un cerotto applicato alla fine, perché ogni handoff non protetto è un anello debole nella catena.
Le domande operative da farsi
Sto trattando MCP e A2A come la stessa cosa, o ho capito che coprono due livelli diversi del mio stack?
I miei agenti potrebbero collaborare con agenti di altri vendor, o ho già costruito un silo che dovrò smontare?
La governance degli handoff tra agenti è progettata fin dall'inizio, o è qualcosa che conto di aggiungere "dopo"?
Sono le domande che oggi sembrano premature e che tra dodici mesi saranno la base di ogni architettura multi-agente seria. Lo scenario verso cui andiamo è un'economia di agenti che si parlano tra organizzazioni come oggi i servizi web si chiamano via API: chi imposta ora il proprio stack pensando all'interoperabilità arriverà a quel mondo con sistemi che si compongono, mentre chi costruisce isole si troverà a doverle demolire proprio quando saranno diventate critiche.
Notizie da tenere d'occhio
A2A sotto la Linux Foundation
Il protocollo, nato in Google, è ora governato in modo neutrale dalla Linux Foundation.
Perché importa: la governance neutrale è ciò che rende uno standard adottabile dai concorrenti senza lock-in.
150+ organizzazioni in un anno
Adozione cross-cloud (Google, Microsoft, AWS) e in produzione in più settori.
Perché importa: la massa critica di adesioni è ciò che trasforma un protocollo in uno standard de facto.
Una cosa da provare
🔧 La specifica ufficiale di A2A (a2a-protocol.org) — Vale una lettura anche solo della parte introduttiva: chiarisce in poche pagine la differenza con MCP e mostra come si descrive un "agent card" per rendere un agente scopribile da altri. È il modo più rapido per capire se la tua architettura è pronta a parlare con il resto del mondo o è ancora un'isola.
A2A non è la notizia appariscente del 2026 — l'interoperabilità non lo è mai. Ma è esattamente il tipo di standard noioso e decisivo su cui si costruiscono i decenni successivi: è successo con HTTP per le pagine, con OAuth per le identità. La cura con cui un'azienda progetta oggi i propri agenti per parlare anche con quelli degli altri è ciò che deciderà se domani potrà comporre il meglio del mercato o resterà chiusa nel proprio recinto.
Grazie per aver letto questo articolo fammi sapere cosa ne pensi!
Ci vediamo presto qui su WikiLuc!