Il protocollo Google A2A 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 bizzarro.

Quando Google ha annunciato A2A nell’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 la scoperta degli agenti, la delega dei compiti, lo scambio di messaggi, aggiornamenti in streaming e la condivisione di artefatti. La reazione, tuttavia, è stata decisamente meno limpida rispetto all’annuncio.

Alcuni sviluppatori hanno visto in A2A lo strato mancante per la comunicazione agente-agente nell’emergente stack 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. Il punto di vista scettico si riduceva a una singola domanda: “Abbiamo già MCP. Perché abbiamo bisogno di A2A?” Era una domanda legittima nel 2025, e lo rimane nel 2026 — anche se la risposta è cambiata considerevolmente.

Due sistemi di agenti AI connessi tramite il 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 tra agenti è ciò che il protocollo è effettivamente progettato per affrontare, e comprenderla è la chiave per valutare A2A senza cadere nell’hype in nessuna delle due direzioni.

Cos’è il protocollo A2A di Google?

A2A sta per Agent2Agent Protocol, e quel nome ne cattura lo scopo con precisione. È 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 il collegamento di un agente a un database, file system, calendario, API o indice di ricerca. Questo è più vicino al lavoro di MCP, il Model Context Protocol. A2A riguarda qualcosa di diverso: un agente che comunica con un altro agente, trattando il sistema peer come un attore con le proprie capacità piuttosto che come una fonte di dati passiva.

Un flusso A2A tipico potrebbe coinvolgere:

La scoperta di un agente tramite una Agent Card
La lettura delle competenze e delle capacità dell’agente
L’invio di un compito
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 è “compito”. A2A non è solo una chiamata di funzione con un wrapper diverso — è un protocollo per il ciclo di vita dei compiti per la collaborazione tra 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 dei compiti, messaggi, parti e artefatti — consulta Cos’è il protocollo A2A? Agent Cards e Compiti Spiegati. Per informazioni su come funzionano lo streaming, le notifiche push e le pause con intervento umano in produzione, consulta Streaming A2A e Compiti Asincroni per Flussi di Lavoro Agenti a Lungo Termine.

Perché A2A Era Facile Da Schernire

A2A è arrivato in un mercato già sommerso da acronimi legati agli agenti.

Entro il 2025, gli sviluppatori dovevano già gestire:

API LLM
Chiamate di funzione
Chiamate di strumenti
Framework per agenti
Server MCP
Pipeline RAG
Motori di flusso di lavoro
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. Proveneva da Google, il che ha fatto preoccupare alcuni sviluppatori riguardo all’impegno a lungo termine. È arrivato prima che la maggior parte dei team avesse risolto problemi di accesso agli strumenti, iniezione di prompt, osservabilità, controllo dei costi e sicurezza per 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 deployment in produzione in più settori.

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

Il segnale è importante, tuttavia, perché è più difficile da ignorare. 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 sugli SDK, attenzione delle piattaforme cloud e un ecosistema in crescita intorno 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’hype.

A2A vs MCP: La Confusione Che Non Moriva

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

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

In termini semplici:

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

Sembra pulito, ma il mondo reale è considerevolmente più caotico. Un server MCP può esporre qualcosa che sembra molto agentic — per esempio, uno strumento MCP chiamato research_company che internamente esegue ricerca, recupero, riassunto, 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à è esattamente il motivo per cui alcuni sviluppatori sostenevano che A2A fosse inutile: se un agente può essere rappresentato come uno strumento MCP, perché creare un protocollo separato?

La risposta è che A2A dà struttura di primo livello a cose che MCP tratta in modo più goffo:

Scoperta degli agenti
Capacità degli agenti
Ciclo di vita dei compiti
Lavoro a lungo termine
Stato del compito multi-turno
Messaggistica agente-agente
Artefatti
Collaborazione tra agenti opachi
Delega oltre i confini organizzativi

MCP può avvolgere molto, ma avvolgere tutto come strumento alla fine diventa una cattiva astrazione. A un certo punto, un sistema specializzato ha abbastanza stato, policy, ciclo di vita e autorità decisionale propria che modellarlo come strumento oscura l’architettura invece di 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 su dove cade il confine nella pratica, consulta 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["Altri 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 è la cornice sulla quale la maggior parte degli architetti di agenti seri si sta convergendo. A2A non dovrebbe sostituire MCP, e MCP non dovrebbe essere costretto a rappresentare ogni confine degli agenti — risolvono problemi diversi a diversi livelli dello stack. La cornice della “guerra dei protocolli” è per lo più un’analisi pigra che fa buoni titoli mentre non aiuta gli ingegneri a progettare sistemi migliori.

Dove A2A È Davvero 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 in modo indipendente
Posseduti da team diversi
Costruiti con framework diversi
Esposti da fornitori
In esecuzione con i propri strumenti e permessi
Responsabili di compiti a lungo termine
Restituiscono artefatti piuttosto che valori semplici
Parte di un flusso di lavoro multi-agente più ampio

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

Potrebbe delegare il lavoro a:

Un agente di procurement
Un agente di revisione legale
Un agente finanziario
Un agente di compliance
Un agente di ricerca di mercato
Un agente di scrittura di report

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

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

L’assistente principale non dovrebbe aver bisogno di accesso diretto a ogni database di procurement, archivio di policy legali, foglio di calcolo finanziario e flusso di lavoro di compliance. Dovrebbe chiedere all’agente responsabile di eseguire il compito.

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, strumentazione, routing e osservabilità — è coperto in Architettura degli Assistenti AI: LLM, Memoria, Strumenti, Routing, Osservabilità.

Dove A2A È Ancora Soffiatata

A2A è soffiato 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 codifica 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
Buoni schemi per gli strumenti
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 uno stato del compito indipendente
Non ci sono fornitori di agenti esterni
Un’API o una coda sarebbe più semplice
Il team non può gestire la complessità aggiuntiva

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

In molti sistemi piccoli, adottare A2A è cosplay architetturale — prendere in prestito 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. Il fatto che A2A diventi 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 da parte 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 ad avviare.

Questa è una lente più sana, ed è quella che rende più facile valutare i meriti tecnici di A2A sui propri termini piuttosto che attraverso il filtro della relazione storica di Google con gli ecosistemi degli sviluppatori.

Adozione: Segnale Forte, Ma Non La Storia Completa

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

All’estremità più debole c’è l’adozione del logo: un’azienda dice di supportare lo standard, il che potrebbe riflettere un’implementazione genuina, una posizione strategica, un prototipo o semplicemente un supporto pianificato che non si è materializzato. Leggermente più forte è l’adozione degli SDK, dove gli sviluppatori possono effettivamente costruire con librerie, esempi e documentazione disponibili — questo significa che il protocollo è passato dalle presentazioni a un’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 aziendali 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 trend di download — i dati di popolarità OpenClaw vs Hermes Agent mostrano quanto velocemente si costruisce e si plateau lo slancio una volta che l’energia dei primi adottatori subsiste.: 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 in più settori, che è un’evidenza 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 dei protocolli.

Il Test Reale: Ritenzione In Produzione

L’hype degli sviluppatori è economico, e la ritenzione in produzione è costosa. I due raramente sono 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 debug
Casi limite del ciclo di vita dei compiti
Fallimenti dello 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 una buona ragione per esistere, ma le buone ragioni non si traducono automaticamente in resilienza in produzione. Il protocollo deve sopravvivere alla realtà operativa che incontra nel passaggio 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 veri confini multi-agente.

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

La Sicurezza È La Più Grande Domanda 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 il 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 del compito?

Queste domande non sono opzionali negli ambienti aziendali.

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

Per esempio:

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

È per questo che i sistemi A2A seri hanno bisogno di più della conformità al protocollo.

Hanno bisogno di:

Identità agente forte
Autorizzazione con ambito limitato
Log di audit a livello di compito
Tracciamento della delega
Approvazione umana per azioni rischiose
Provenienza degli artefatti
Limiti di rateo
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 applicazione delle policy a ogni confine che attraversa. Sicurezza degli Agenti A2A e MCP: Identità, Delega e Trail di Audit espone quell’architettura circostante in dettaglio.

A2A E L’Idea Del Mercato Degli Agenti

Uno dei casi d’uso A2A a lungo termine più interessanti è quello dei mercati degli agenti.

Se gli agenti possono pubblicizzare le capacità tramite Agent Cards, allora altri agenti o piattaforme possono scoprirli, valutarli e inviare compiti.

Questo crea un futuro possibile 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 dei viaggi
Un agente di analisi della sicurezza
Un agente di procurement
Un agente di qualità dei dati

Ciascuno potrebbe esporre un’interfaccia standard per la collaborazione basata su compiti.

Sembra eccitante, ma è anche dove l’hype diventa pericoloso.

Un mercato aperto di agenti richiede più delle Agent Cards. Ha bisogno di identità, reputazione, fatturazione, compliance, sandboxing, responsabilità, versionamento e risoluzione delle controversie.

Senza questi, un mercato 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 compliance e risoluzione delle controversie prima che diventi un mercato sicuro in cui operare.

A2A Per Agenti Aziendali Interni

Il caso d’uso a breve termine più realistico non sono i mercati pubblici degli agenti.

Sono le reti interne di agenti aziendali.

Le grandi organizzazioni hanno già molti confini:

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

A2A si mappa naturalmente su questi confini, perché il protocollo è progettato intorno allo stesso bisogno fondamentale: comunicazione strutturata tra sistemi che hanno la propria proprietà e non condividono una codebase. Il cluster più ampio dei 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 Finanza
Agente Supporto
Agente DevOps
Agente Sicurezza
Agente Gestione della Conoscenza
Agente Piattaforma Dati

Ogni agente può possedere internamente i propri strumenti e policy. 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 dell’organizzazione, sia da una prospettiva di sicurezza che operativa. Ogni agente specializzato può essere posseduto, operato, auditato e protetto in modo indipendente, il che rende anche l’intero sistema più facile da analizzare 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
Compiti delegati a lungo termine
Requisiti di scoperta degli agenti
Requisiti di scambio di artefatti
Bisogni di interoperabilità cross-framework

La sequenza conta più dell’ambizione. Inizia con l’architettura più semplice che espone i reali punti di pressione, 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.

Nessun A2A quando il flusso di lavoro è locale. Evita A2A quando tutto viene eseguito all’interno di una singola applicazione e i componenti non sono distribuibili in modo indipendente. Una funzione Python, una classe, un servizio, una coda o un motore di flusso di lavoro sono probabilmente sufficienti.

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 offre 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 degli agenti del 2026, e l’architettura che si mappa più pulitamente su come i sistemi multi-agente di produzione sono effettivamente costruiti.

Errori Comuni Con A2A

Usare A2A perché suona strategico. Questo è il classico trabocchetto dell’architettura aziendale. 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 di database non ha bisogno di essere un agente. Molte cose sono strumenti straightforward, 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 dei compiti, memoria, policy, artefatti e comportamento di delega, potrebbe meritare di essere modellato come un agente piuttosto che essere costretto dietro un confine di chiamata di funzione.

Ignorare l’osservabilità. I sistemi multi-agente senza tracce sono dolorosi da debug e impossibili da auditare. Devi sapere quale agente ha ricevuto il compito, 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 debug diventa archeologia — ricostruire cosa è successo per inferenza piuttosto che per osservazione. Lo stack completo di osservabilità per sistemi basati su AI e LLM, inclusi metriche, tracce distribuite e SLO che attraversano i confini degli agenti, è coperto in Osservabilità per Sistemi LLM: Metriche, Tracce, Log e Testing In Produzione.

Quindi A2A È Soffiato?

Sì, in parte. A2A è soffiato 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 quello 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 fanno sembrare A2A più universale di quanto sia.

Ma soffiato non significa inutile. Molte tecnologie importanti sono soffiante prima di diventare infrastruttura noiosa, e l’hype arriva spesso ben prima che l’ecosistema sia maturo abbastanza per supportarlo. La vera domanda non è se il marketing sia eccessivo — chiaramente lo è a volte. La vera domanda è 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 allo slancio di MCP.

Nel 2026, quell’argomento è più debole.

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

Nessuna di queste cose rende A2A dominante, obbligatorio o universalmente amato dalla comunità degli sviluppatori — ma chiaramente non è morto. Una dichiarazione migliore è che A2A è vivo e sta ancora dimostrando il suo valore di produzione oltre gli ecosistemi aziendali e delle piattaforme, dove risiedono 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 veri confini degli agenti — 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 dei compiti
Messaggi
Artefatti
Lavoro a lungo termine
Confini di implementazione opachi
Interoperabilità cross-fornitore

È lì che A2A guadagna il suo posto, fornendo un contratto comune per la collaborazione che altrimenti richiederebbe lavoro di protocollo personalizzato a 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: collegare gli agenti a strumenti e contesto utili. A2A risolve un problema di fase successiva: collegare agenti indipendenti tra loro attraverso veri confini di deployment e proprietà. Questo rende MCP più utile oggi per la vasta maggioranza degli sviluppatori individuali e dei piccoli team.

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

Il mio consiglio pratico è iniziare con MCP, progettare confini degli agenti puliti fin dall’inizio, e aggiungere A2A solo quando quei confini diventano vincoli reali di deployment, proprietà o interoperabilità. Non adottare A2A per vibes. 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 aziendale multi-agente, un mercato di agenti, una rete di agenti neutrale rispetto ai fornitori o un set di agenti specializzati distribuiti in modo indipendente, A2A merita seria attenzione.

La cornice 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 agli ingegneri che devono prendere decisioni architetturali reali.