Protocollo A2A di Google nel 2026: Adozione, Hype e Realtà

A2A non è morto. Semplicemente, non è universale.

Indice

Il protocollo Agent2Agent di Google, solitamente abbreviato in A2A, ha avuto un primo anno strano.

Quando Google ha annunciato A2A ad aprile 2025, il messaggio era chiaro: gli agenti AI sviluppati da diversi fornitori, framework e team avevano bisogno di uno standard per comunicare. Il protocollo prometteva scoperta degli agenti, delega di attività, scambio di messaggi, aggiornamenti in streaming e condivisione di artefatti. La reazione, tuttavia, è stata considerevolmente meno lineare dell’annuncio.

Alcuni sviluppatori hanno visto in A2A lo strato mancante di comunicazione agente-agente per la nascente pila agentic. Altri lo hanno visto come un altro protocollo Google, un altro acronimo e un altro tentativo di definire un mercato prima che il mercato avesse reali esigenze produttive. La posizione scettica si riduceva a una singola domanda: “Abbiamo già MCP. Perché abbiamo bisogno di A2A?” Era una domanda legittima nel 2025, e rimane tale nel 2026 — anche se la risposta è cambiata considerevolmente.

Due sistemi di agenti AI collegati dal ponte del protocollo A2A

A2A non è morto, ma non è nemmeno universalmente utile. La realtà pratica è che A2A sta diventando genuinamente prezioso in un contesto specifico: dove gli agenti sono sistemi indipendenti con la propria proprietà, strumenti e confini di fiducia, piuttosto che semplici funzioni interne o wrapper per strumenti. Questa distinzione tra integrazione degli strumenti e delega degli agenti è ciò che il protocollo è progettato per affrontare, e comprenderla è la chiave per valutare A2A senza l’ipotesi in nessuna direzione.

Cos’è il protocollo A2A di Google?

A2A sta per Agent2Agent Protocol, e quel nome ne cattura precisamente lo scopo. È uno standard aperto per la comunicazione e l’interoperabilità tra sistemi di agenti AI indipendenti — specificamente, agenti che potrebbero essere costruiti utilizzando framework, linguaggi o stack di fornitori diversi.

A2A non riguarda principalmente la connessione di un agente a un database, filesystem, calendario, API o indice di ricerca. Questo è più vicino al lavoro di MCP, il Model Context Protocol. A2A riguarda qualcos’altro: un agente che comunica con un altro agente, trattando il sistema peer come un attore con le proprie capacità piuttosto che come una fonte passiva di dati.

Un flusso A2A tipico potrebbe coinvolgere:

La scoperta di un agente tramite un Agent Card
La lettura delle competenze e delle capacità dell’agente
L’invio di un’attività
Lo scambio di messaggi
La ricezione di aggiornamenti di stato
La gestione degli stati che richiedono input
La ricezione di artefatti finali
Il monitoraggio del completamento, del fallimento o dell’annullamento

La parola importante in questa lista è “attività”. A2A non è solo una chiamata di funzione con un wrapper diverso — è un protocollo per il ciclo di vita delle attività per la collaborazione degli agenti, progettato per gestire l’intero arco dalla scoperta e delega all’esecuzione, agli aggiornamenti di stato e al ritorno degli artefatti. Per un’analisi tecnica approfondita di ciascun concetto — Agent Cards, ciclo di vita delle attività, messaggi, parti e artefatti — vedere Cos’è il protocollo A2A? Agent Cards e Attività Spiegate.

Perché A2A era facile da prendere in giro

A2A è arrivato in un mercato già sommerso di acronimi di agenti.

Entro il 2025, gli sviluppatori avevano già a che fare con:

API LLM
Chiamate di funzione
Chiamate di strumenti
Framework per agenti
Server MCP
Pipeline RAG
Motori di workflow
Librerie di orchestrazione multi-agente
Protocolli JSON personalizzati
Sistemi di plugin interni

Quindi quando Google ha annunciato A2A, una reazione comune era prevedibile:

“Abbiamo davvero bisogno di un altro standard?”

Lo scetticismo non era irrazionale, e proveniva da diverse direzioni contemporaneamente. A2A sembrava sovrapporsi a MCP. Veniva da Google, il che faceva preoccupare alcuni sviluppatori riguardo all’impegno a lungo termine. È arrivato prima che la maggior parte dei team avesse risolto l’accesso di base agli strumenti, l’iniezione di prompt, l’osservabilità, il controllo dei costi e la sicurezza per i sistemi a singolo agente.

In quell’ambiente, l’“interoperabilità agente-agente” suonava ambiziosa, ma anche un po’ prematura.

E per essere schietti, molte dimostrazioni di agenti AI nel 2025 non avevano bisogno di A2A affatto.

Avevano bisogno di prompt migliori, strumenti migliori, permessi migliori, logica di retry migliore e log migliori.

L’aggiornamento 2026: A2A non è morto

Il grande cambiamento nel 2026 è che A2A non è più solo un annuncio di Google.

Ad aprile 2026, la Linux Foundation ha riferito che il progetto A2A aveva superato le 150 organizzazioni sostenitrici, ottenuto integrazioni con le principali piattaforme cloud e raggiunto distribuzioni in produzione in più settori.

Questo non significa che ogni affermazione debba essere accettata senza scetticismo. “Sostenuto da” non è la stessa cosa di “utilizzato in profondità in produzione dalla maggior parte degli sviluppatori”. Gli ecosistemi dei protocolli spesso sembrano più grandi nelle release stampa di quanto non siano nel lavoro ingegneristico quotidiano.

Il segnale è importante, tuttavia, perché è più difficile da respingere. A2A ha superato una linea importante: non è più solo un post sul blog di Google. Ha una specifica formale, slancio di governance, esempi pubblici, lavoro su SDK, attenzione da parte delle piattaforme cloud e un ecosistema in crescita attorno all’interoperabilità degli agenti. Questo rende difficile difendere l’etichetta “morto” su basi tecniche o di adozione.

Una critica più difendibile è che A2A è vivo ma il suo ambito utile è più ristretto di quanto suggerisca l’ipotesi.

A2A vs MCP: La confusione che non voleva morire

La maggior parte della confusione su A2A deriva dalla sua relazione con MCP.

MCP, creato da Anthropic, standardizza come le applicazioni AI si connettono a strumenti esterni e fonti di dati. I server MCP espongono strumenti, risorse e prompt. I host e i client AI li consumano.

In termini semplici:

MCP connette gli agenti agli strumenti.
A2A connette gli agenti ad altri agenti.

Suona pulito, ma il mondo reale è considerevolmente più caotico. Un server MCP può esporre qualcosa che sembra molto agentic — per esempio, uno strumento MCP denominato ricerca_azienda che internamente esegue ricerca, recupero, sintesi, classificazione e scrittura di report. Dal punto di vista dell’host MCP, è uno strumento. Dal punto di vista architetturale, sta nascondendo un flusso di lavoro simile a un agente dietro un confine di chiamata di funzione. Questa ambiguità è precisamente il motivo per cui alcuni sviluppatori sostenevano che A2A non fosse necessario: se un agente può essere rappresentato come uno strumento MCP, perché creare un protocollo separato?

La risposta è che A2A dà una struttura di prima classe a cose che MCP tratta in modo più goffo:

Scoperta degli agenti
Capacità degli agenti
Ciclo di vita delle attività
Lavoro a lungo termine
Stato dell’attività multi-turno
Messaggistica agente-agente
Artefatti
Collaborazione tra agenti opachi
Delega attraverso confini organizzativi

MCP può avvolgere molto, ma avvolgere tutto come uno strumento alla fine diventa una cattiva astrazione. A un certo punto, un sistema specializzato ha abbastanza del proprio stato, policy, ciclo di vita e autorità decisionale che modellarlo come uno strumento oscura l’architettura piuttosto che semplificarla. Questo è il punto di inflessione dove trattare un agente peer come un agente peer — piuttosto che come una chiamata di strumento — inizia a dare frutti. Per un confronto dettagliato di dove cade il confine nella pratica, vedere A2A vs MCP: Gli agenti AI hanno davvero bisogno di entrambi i protocolli?

Il miglior modello mentale: MCP sotto, A2A sopra

L’architettura più pulita non è “A2A vs MCP”.

L’architettura più pulita è stratificata:

flowchart TD U["Utente o applicazione"] O["Assistente principale / orchestratore"] S1["Agente specializzato A"] S2["Agente specializzato B"] T1["Strumenti, API, file, database"] T2["Più strumenti e fonti di dati"] U --> O O -->|A2A| S1 O -->|A2A| S2 S1 -->|MCP| T1 S2 -->|MCP| T2

In questo modello:

A2A è lo strato di collaborazione degli agenti.
MCP è lo strato di integrazione degli strumenti.

Questo è il pattern che ha più senso nel 2026, ed è l’inquadratura su cui la maggior parte degli architetti di agenti seri si sta concentrando. A2A non dovrebbe sostituire MCP, e MCP non dovrebbe essere costretto a rappresentare ogni confine di agente — risolvono problemi diversi a strati diversi della pila. L’inquadratura della “guerra dei protocolli” è per lo più un’analisi pigia che fa buoni titoli mentre non aiuta gli ingegneri a progettare sistemi migliori.

Dove A2A è realmente utile

A2A diventa utile quando un agente non è più solo una chiamata di libreria all’interno della tua applicazione.

È utile quando gli agenti sono:

Distribuiti indipendentemente
Proprietà di team diversi
Costruiti con framework diversi
Esposti da fornitori
In esecuzione con i propri strumenti e permessi
Responsabili di attività a lungo termine
Restituiscono artefatti piuttosto che valori semplici
Parte di un più ampio flusso di lavoro multi-agente

Per esempio, immagina un assistente aziendale che deve preparare un report sul rischio dei fornitori.

Potrebbe delegare il lavoro a:

Un agente di approvvigionamento
Un agente di revisione legale
Un agente finanziario
Un agente di conformità
Un agente di ricerca di mercato
Un agente di scrittura report

Ogni agente ha il proprio dominio, strumenti, regole, permessi e requisiti di audit.

Per quel tipo di sistema, A2A non è assurdo. È un confine ragionevole.

L’assistente principale non dovrebbe aver bisogno di accesso diretto a ogni database di approvvigionamento, archivio di policy legali, foglio di calcolo finanziario e flusso di lavoro di conformità. Dovrebbe chiedere all’agente responsabile di eseguire l’attività.

Questa è la distinzione essenziale: l’accesso agli strumenti è una connessione verticale tra un agente e le sue risorse, mentre la delega di dominio è un passaggio orizzontale tra agenti autonomi, ciascuno con il proprio confine di autorità e responsabilità. Il modello stratificato per come questi componenti si combinano — LLM, memoria, strumenti, routing e osservabilità — è coperto in Architettura dell’Assistente AI: LLM, Memoria, Strumenti, Routing, Osservabilità.

Dove A2A è ancora sopravvalutato

A2A è sopravvalutato quando viene presentato come infrastruttura obbligatoria per ogni progetto AI.

La maggior parte dei progetti non ne ha bisogno.

Se stai costruendo un assistente di codice locale, un chatbot per la tua documentazione, un piccolo agente di automazione interna o un singolo flusso di lavoro che chiama un pugno di strumenti, A2A è probabilmente inutile.

Potresti aver bisogno di:

MCP
Schema di strumenti buoni
Guardrails
Valutazione
Logging
Controllo dei costi
Logica di retry
Prompt migliori
Recupero migliore

Probabilmente non hai bisogno di un protocollo completo agente-agente.

A2A può essere un errore quando:

C’è solo un agente
Tutti i componenti vivono in un’unica codebase
I flussi di lavoro sono brevi e sincroni
Gli agenti non hanno bisogno di scoperta
Gli agenti non hanno bisogno di stato di attività indipendente
Non ci sono fornitori di agenti esterni
Un’API o una coda sarebbero più semplici
Il team non può gestire la complessità extra

Un protocollo non è gratis. Aggiunge concetti, modalità di fallimento, sovraccarico di debugging, preoccupazioni di sicurezza e lavoro operativo.

In molti sistemi piccoli, adottare A2A è cosplay architetturale — mutuare il vocabolario dei sistemi di agenti distribuiti senza nessuno dei problemi di confine reali che rendono il protocollo prezioso.

A2A e il problema Google

Parte dello scetticismo su A2A proviene da Google stesso.

Gli sviluppatori hanno una lunga memoria. Quando Google lancia una piattaforma, un protocollo, un prodotto o un ecosistema, molti ingegneri chiedono immediatamente:

“Esisterà ancora tra tre anni?”

Questa reazione non è del tutto giusta per il design tecnico di A2A, ma è un fattore reale di adozione.

La storia dell’hosting della Linux Foundation aiuta qui. A2A diventare parte di un ambiente di governance aperta più ampio lo rende meno dipendente dalle priorità interne di Google.

Questo non garantisce il successo. La governance aperta non crea magicamente l’adozione degli sviluppatori. Ma riduce una delle preoccupazioni più grandi: che A2A sia solo una mossa strategica controllata da Google.

Nel 2026, A2A dovrebbe essere giudicato meno come “il protocollo di Google” e più come uno standard emergente di interoperabilità degli agenti che Google ha aiutato a iniziare.

Questo è uno sguardo più sano, ed è quello che rende più facile valutare i meriti tecnici di A2A per conto loro piuttosto che attraverso il filtro della relazione storica di Google con gli ecosistemi degli sviluppatori.

Adozione: Segnale forte, ma non la storia completa

Le 150+ organizzazioni sostenitrici riportate sono significative, ma non dovrebbero essere confuse con l’adozione universale degli sviluppatori. “Sostenuto da” è uno spettro, non un binario, ed è utile leggere le affermazioni di adozione tenendo questo a mente.

All’estremità più debole c’è l’adozione del logo: un’azienda dice di supportare lo standard, il che potrebbe riflettere un’implementazione genuina, posizionamento strategico, un prototipo o semplicemente supporto pianificato che non si è materializzato. Leggermente più forte è l’adozione di SDK, dove gli sviluppatori possono effettivamente costruire con librerie, esempi e documentazione disponibili — questo significa che il protocollo è passato dalla slideware all’implementazione funzionante, e ingegneri reali l’hanno trovato degno del loro tempo. Ancora più forte è l’adozione della piattaforma, dove cloud, framework di agenti e sistemi enterprise espongono un supporto nativo reale, rendendo A2A una scelta architetturale predefinita plausibile piuttosto che qualcosa che i team devono cablare da soli.

L’unico livello di adozione che conta davvero per la salute a lungo termine dell’ecosistema è la ritenzione in produzione. Per un’idea di come appaiono le curve di adozione reali nello spazio degli agenti AI — misurate in stelle GitHub, token OpenRouter e tendenze di download — i dati sulla popolarità di OpenClaw vs Hermes Agent mostrano quanto rapidamente si costruisce e si plateau il momentum una volta che l’energia dei primi adottatori si attenua.: team che si affidano al protocollo per flussi di lavoro live oltre la luna di miele iniziale di 90 giorni. L’aggiornamento 2026 della Linux Foundation afferma l’uso in produzione attraverso più settori, che è una prova significativa. Ma la domanda più utile non è “chi supporta A2A?” — è “chi mantiene A2A in produzione dopo il primo incidente operativo reale?”. La ritenzione a lungo termine sotto pressione è il segnale che separa l’infrastruttura genuina dalla teoria del protocollo.

Il vero test: Ritenzione in produzione

L’entusiasmo degli sviluppatori è economico, e la ritenzione in produzione è costosa. I due sono raramente proporzionali, ed è per questo che la domanda sulla ritenzione a 90 giorni conta più dell’entusiasmo della settimana di lancio.

A2A si dimostrerà se i team continueranno a usarlo dopo aver incontrato:

Problemi di autenticazione
Problemi di autorizzazione
Problemi di identità degli agenti
Problemi di debugging
Casi limite del ciclo di vita delle attività
Fallimenti di streaming
Compatibilità delle versioni
Differenze tra fornitori
Sorprese sui costi
Revisioni di sicurezza
Requisiti di audit
Flussi di lavoro di approvazione umana

È qui che molti framework e protocolli di agenti falliscono. Sembra elegante nei diagrammi, poi diventa doloroso in produzione.

A2A ha un buon motivo per esistere, ma i buoni motivi non si traducono automaticamente in resilienza in produzione. Il protocollo deve sopravvivere alla realtà operativa che incontra sul cammino dalla demo al deployment.

Il miglior segno per A2A nel 2026 non è che le persone stanno scrivendo post sul blog su di esso. Il miglior segno è che le aziende stanno iniziando a usarlo per confini reali multi-agente.

Il peggior segno sarebbe se gli sviluppatori lo usassero solo nelle demo mentre i sistemi di produzione tornano a API e code personalizzate.

La sicurezza è la domanda più grande irrisolta

I problemi più difficili di A2A non sono problemi di sintassi o specifica. Sono problemi di fiducia che emergono quando si distribuiscono effettivamente agenti autonomi attraverso confini organizzativi o di sistema.

Quando un agente parla con un altro agente, diverse domande diventano urgenti:

Chi è questo agente?
Chi lo possiede?
Cosa gli è permesso sapere?
Cosa gli è permesso fare?
Può delegare lavoro ulteriormente?
Può chiamare strumenti per conto di un utente?
Può preservare l’intento dell’utente?
Può provare cosa è successo?
Può essere auditato dopo il completamento dell’attività?

Queste domande non sono opzionali negli ambienti enterprise.

A2A rende più facile la collaborazione degli agenti. Crea anche nuovi luoghi dove la fiducia può rompersi.

Per esempio:

Un agente malizioso potrebbe falsificare le sue capacità.
Un agente compromesso potrebbe richiedere contesto sensibile.
Un’attività delegata potrebbe superare l’autorità dell’utente.
Un agente potrebbe restituire artefatti avvelenati.
Una catena di agenti potrebbe rendere l’accountabilità chiara.
Dati sensibili potrebbero fluire attraverso confini senza logging appropriato.

Questo è il motivo per cui i sistemi A2A seri hanno bisogno di più della conformità al protocollo.

Hanno bisogno di:

Identità agente forte
Autorizzazione scoped
Log di audit a livello di attività
Tracciamento della delega
Approvazione umana per azioni rischiose
Provenienza degli artefatti
Limiti di rate
Applicazione delle policy
Osservabilità attraverso i confini degli agenti

A2A non è un’architettura di sicurezza di per sé — è un protocollo di comunicazione che deve essere distribuito all’interno di una, con decisioni esplicite prese su identità, autorizzazione, audit e enforcement delle policy ad ogni confine che attraversa.

A2A e l’idea del marketplace degli agenti

Uno dei casi d’uso A2A a lungo termine più interessanti sono i marketplace degli agenti.

Se gli agenti possono annunciare capacità tramite Agent Cards, allora altri agenti o piattaforme possono scoprirli, valutarli e inviare attività.

Questo crea un possibile futuro in cui le capacità degli agenti diventano più modulari:

Un agente fiscale
Un agente legale
Un agente di revisione del codice
Un agente di pianificazione viaggi
Un agente di analisi di sicurezza
Un agente di approvvigionamento
Un agente di qualità dei dati

Ognuno potrebbe esporre un’interfaccia standard per la collaborazione basata su attività.

Questo suona eccitante, ma è anche dove l’ipotesi diventa pericolosa.

Un marketplace di agenti aperto richiede più di Agent Cards. Ha bisogno di identità, reputazione, fatturazione, conformità, sandboxing, responsabilità, versioning e risoluzione delle controversie.

Senza questi, un marketplace di agenti diventa un incidente di sicurezza in attesa di accadere.

A2A è un blocco di costruzione utile per questo tipo di futuro, ma è un pezzo di un puzzle molto più grande che richiede anche sistemi di identità, meccanismi di reputazione, infrastruttura di fatturazione, controlli di conformità e risoluzione delle controversie prima che diventi un mercato sicuro in cui operare.

A2A per agenti enterprise interni

Il caso d’uso a breve termine più realistico non è quello dei marketplace di agenti pubblici.

È quello delle reti di agenti enterprise interne.

Le grandi organizzazioni hanno già molti confini:

Team
Dipartimenti
Sistemi
Fornitori
Domini di dati
Zone di conformità
Policy di sicurezza
Processi di approvazione

A2A si mappa naturalmente su questi confini, perché il protocollo è progettato attorno allo stesso bisogno fondamentale: comunicazione strutturata tra sistemi che hanno la propria proprietà e non condividono una codebase. Il cluster più ampio di Sistemi AI copre come agenti specializzati come Hermes e OpenClaw si inseriscono in questo tipo di architettura stratificata nella pratica.

Invece di costruire un unico assistente gigante con accesso diretto a tutto, un’azienda può costruire agenti specializzati con responsabilità limitata:

Agente HR
Agente finanziario
Agente di supporto
Agente DevOps
Agente di sicurezza
Agente di gestione della conoscenza
Agente piattaforma dati

Ogni agente può possedere i propri strumenti e policy internamente. Altri agenti possono interagire con esso tramite A2A.

Questo è un modello molto migliore rispetto a dare a un singolo agente general-purpose accesso diretto a ogni sistema nell’organizzazione, sia da una prospettiva di sicurezza che operativa. Ogni agente specializzato può essere posseduto, operato, auditato e secured indipendentemente, il che rende anche il sistema complessivo più facile da ragionare quando qualcosa va storto.

A2A per piccoli team e indie hacker

Per i piccoli team che costruiscono prodotti con uno o due agenti, A2A è genuinamente meno urgente — e spesso una distrazione da problemi più immediati. Probabilmente non hai ancora bisogno di un protocollo agente-agente.

Usa codice normale. Usa API HTTP. Usa code. Usa MCP dove l’integrazione degli strumenti è importante.

Aggiungi A2A quando hai effettivamente:

Più agenti indipendenti
Confini di agenti di terze parti
Attività delegate a lungo termine
Requisiti di scoperta degli agenti
Requisiti di scambio di artefatti
Esigenze di interoperabilità cross-framework

La sequenza conta più dell’ambizione. Inizia con l’architettura più semplice che espone i punti di pressione reali, e lascia che quei punti di pressione ti dicano se hai davvero bisogno di A2A prima di impegnarti nella complessità che porta. Per la maggior parte dei costruttori piccoli, MCP prima e A2A dopo è la strada giusta.

Un framework decisionale pratico

Usa questo framework quando decidi se A2A appartiene al tuo sistema.

Niente A2A quando il flusso di lavoro è locale. Evita A2A quando tutto gira all’interno di un’applicazione e i componenti non sono distribuibili indipendentemente. Una funzione Python, una classe, un servizio, una coda o un motore di workflow è probabilmente sufficiente.

MCP quando l’agente ha bisogno di strumenti. Usa MCP quando il tuo agente ha bisogno di accesso standardizzato a file, database, API, sistemi SaaS, indici di ricerca, repository, documentazione interna o sistemi di osservabilità. MCP dà valore pratico immediato ed è il punto di partenza giusto per la maggior parte dei team che costruiscono agenti oggi.

A2A quando l’agente ha bisogno di peer. Usa A2A quando il tuo agente ha bisogno di comunicare con altri agenti indipendenti — specialmente quando quegli agenti hanno le proprie capacità, policy, stato, strumenti, proprietari, ciclo di vita di deployment e confine di sicurezza.

Entrambi quando l’architettura ha strati. Usa entrambi quando gli agenti specializzati collaborano tra loro e ogni specialista ha anche bisogno di strumenti. Il pattern di produzione è A2A tra agenti e MCP tra agenti e strumenti. Questa è la versione più sensata dello stack di protocolli di agenti del 2026, e l’architettura che si mappa più pulitamente su come i sistemi multi-agente di produzione vengono effettivamente costruiti.

Errori comuni con A2A

Usare A2A perché suona strategico. Questa è la classica trappola dell’architettura enterprise. A2A dovrebbe risolvere un vero problema di confine che esiste nell’architettura, non uno inventato per giustificare la scelta del protocollo. Se non c’è un confine genuino — nessun deployment indipendente, nessuna proprietà separata, nessun perimetro di sicurezza distinto — probabilmente non c’è bisogno di A2A.

Trattare MCP e A2A come competitor. MCP non è obsoleto perché A2A esiste, e A2A non è inutile perché MCP esiste. Affrontano problemi strutturali diversi e funzionano meglio come strati complementari, non alternative competitive.

Esporre ogni capacità come un agente. Una calcolatrice non ha bisogno di essere un agente. Un’API del meteo non ha bisogno di essere un agente. Una query al database non ha bisogno di essere un agente. Molte cose sono strumenti diretti, e l’astrazione dell’agente aggiunge sovraccarico senza aggiungere chiarezza quando applicata a componenti che non hanno autonomia, stato o ciclo di vita significativi propri.

Nascondere un agente completo dietro uno strumento. L’errore opposto è anche comune. Se uno “strumento” ha il proprio ciclo di vita delle attività, memoria, policy, artefatti e comportamento di delega, potrebbe meritare di essere modellato come un agente piuttosto che essere stretto dietro un confine di chiamata di funzione.

Ignorare l’osservabilità. I sistemi multi-agente senza trace sono dolorosi da debuggare e impossibili da auditare. Devi sapere quale agente ha ricevuto l’attività, quali messaggi sono stati scambiati, quali strumenti sono stati chiamati, quali artefatti sono stati prodotti, quali policy sono state applicate e quale agente ha preso la decisione finale. Senza quella visibilità, il debugging diventa archeologia — ricostruire cosa è successo per inferenza piuttosto che per osservazione. Lo stack di osservabilità completo per i sistemi AI e supportati da LLM, incluse metriche, trace distribuite e SLO che attraversano i confini degli agenti, è coperto in Osservabilità per sistemi LLM: Metriche, Trace, Log e Testing in produzione.

Quindi A2A è sopravvalutato?

Sì, in parte. A2A è sopravvalutato quando viene presentato come il default inevitabile per tutti i sistemi di agenti AI, quando le persone implicano che ogni sviluppatore deve adottarlo immediatamente, quando le demo degli agenti usano A2A per coordinare ciò che avrebbe potuto essere tre chiamate di funzione, o quando la discussione sul protocollo ignora identità, autorizzazione, osservabilità e operazioni di produzione. Questi sono esempi reali di hype che rendono A2A suonare più universale di quanto sia.

Ma sopravvalutato non significa inutile. Molte tecnologie importanti sono sopravvalutate prima di diventare infrastrutture noiose, e l’hype spesso arriva ben prima che l’ecosistema sia maturo abbastanza per supportarlo. La domanda reale non è se il marketing sia eccessivo — chiaramente lo è a volte. La domanda reale è se l’astrazione sottostante sia utile, e per A2A, la risposta è sì quando gli agenti diventano attori genuinamente indipendenti in un sistema con confini reali, proprietà reale e interessi reali.

Quindi A2A è morto?

No.

L’argomento “A2A è morto” aveva più senso durante la fase di scetticismo iniziale, quando il protocollo sembrava una risposta guidata da Google al momentum di MCP.

Nel 2026, quell’argomento è più debole.

A2A ha una specifica formale, supporto dell’ecosistema, slancio della Linux Foundation, attenzione delle principali cloud e distribuzioni in produzione riportate.

Niente di tutto questo rende A2A dominante, obbligatorio o universalmente amato dalla comunità degli sviluppatori — ma chiaramente non è morto. Un’affermazione migliore è che A2A è vivo e sta ancora dimostrando il suo valore di produzione oltre gli ecosistemi enterprise e di piattaforma, dove vive la maggior parte dei deployment confermati attualmente.

Quindi A2A è finalmente utile nel 2026?

Sì, ma solo nell’architettura giusta. A2A è utile quando il tuo sistema ha confini di agenti reali — non solo perché il tuo codice ha più prompt, o perché il tuo sistema usa la parola “agente” nei nomi delle variabili. Diventa utile quando la collaborazione degli agenti ha genuinamente bisogno di struttura standard:

Scoperta
Capacità
Ciclo di vita delle attività
Messaggi
Artefatti
Lavoro a lungo termine
Confini di implementazione opachi
Interoperabilità cross-vendor

Questo è dove A2A guadagna il suo posto, fornendo un contratto comune per la collaborazione che altrimenti richiederebbe lavoro di protocollo personalizzato ad ogni confine.

La mia opinione

A2A non è il protocollo con cui la maggior parte degli sviluppatori dovrebbe iniziare — MCP sì. MCP risolve un problema più immediato e ampiamente applicabile: connettere gli agenti a strumenti e contesto utili. A2A risolve un problema di fase successiva: connettere agenti indipendenti l’uno con l’altro attraverso confini di deployment e proprietà reali. Questo rende MCP più utile oggi per la vasta maggioranza degli sviluppatori individuali e piccoli team.

A2A potrebbe diventare più importante man mano che i sistemi di agenti maturano dalle demo ai flussi di lavoro enterprise. Una volta che le organizzazioni hanno più agenti specializzati posseduti da team diversi, la necessità di un confine standard agente-agente diventa ovvia e il sovraccarico del protocollo inizia a ripagarsi.

La mia raccomandazione pratica è iniziare con MCP, progettare confini di agenti puliti fin dall’inizio, e aggiungere A2A solo quando quei confini diventano vincoli reali di deployment, proprietà o interoperabilità. Non adottare A2A per le vibrazioni. Adottalo quando l’architettura lo richiede.

Verdetto finale

Il protocollo A2A di Google non è morto.

Non è nemmeno il futuro universale di ogni progetto di agenti AI.

È un protocollo utile, ancora in maturazione, per un problema specifico: comunicazione tra agenti AI indipendenti.

Se stai costruendo un assistente semplice, A2A è probabilmente inutile.

Se stai costruendo un sistema enterprise multi-agente, un marketplace di agenti, una rete di agenti neutrale rispetto ai fornitori o un insieme di agenti specializzati distribuiti indipendentemente, A2A merita seria attenzione.

L’inquadratura migliore del 2026 non è:

A2A vs MCP

È:

MCP per gli strumenti.
A2A per gli agenti.
Entrambi per sistemi multi-agente seri.

Questo è meno drammatico di una narrazione di guerra dei protocolli, ma è anche più accurato e più utile per gli ingegneri che devono prendere decisioni architetturali reali.