Cos'è il protocollo A2A? Agent Cards e Tasks spiegati

Il protocollo A2A, acronimo di Agent2Agent Protocol, è uno standard aperto per la comunicazione tra sistemi di agenti AI indipendenti.

Questa frase sembra semplice, ma implica qualcosa che la maggior parte delle dimostrazioni di agenti AI ignora completamente. La maggior parte delle demo presume ancora un singolo assistente, un singolo runtime, un unico ciclo di strumenti e un unico proprietario: l’agente può cercare, chiamare strumenti, scrivere codice, interrogare API, forse utilizzare server MCP e restituire una risposta.

A2A è progettato per un mondo diverso, in cui gli agenti possono essere costruiti da team diversi, framework, fornitori, linguaggi o organizzazioni. Presuppone che un agente possa dover scoprire un altro agente, comprendere cosa può fare, inviargli lavoro, scambiare messaggi, ricevere file o output strutturati e tracciare un compito fino al completamento, rendendolo non solo un altro formato per la chiamata di strumenti, ma un genuino tentativo di rendere gli agenti AI interoperabili come pari.

I concetti fondamentali sono:

• Agent Card (Schede Agente)
• Agenti e client
• Task (Compiti)
• Messaggi
• Parts (Parti)
• Artifacts (Artefatti)
• Stati del Task
• Streaming e aggiornamenti asincroni

Questo articolo spiega questi concetti in termini ingegneristici semplici, con sufficienti dettagli per comprendere dove A2A si inserisce nei veri sistemi multi-agente.

La Definizione Breve

A2A è un protocollo per la comunicazione agente-agente.

Permette a un agente o a un client di comunicare con un altro agente attraverso un modello comune. L’agente ricevente può descrivere le proprie capacità, accettare lavoro, gestire il ciclo di vita di tale lavoro, richiedere ulteriori input, trasmettere in streaming i progressi e restituire output concreti.

L’obiettivo non è standardizzare come un agente pensa internamente, ma standardizzare come gli agenti comunicano ai loro confini.

Un agente A2A internamente potrebbe utilizzare:

• Python
• Go
• JavaScript
• LangGraph
• CrewAI
• Semantic Kernel
• codice personalizzato
• server MCP
• API private
• database vettoriali
• motori di workflow

Il chiamante non ha bisogno di sapere nulla di tutto ciò. Ciò di cui il chiamante ha bisogno è sapere:

• Cosa può fare questo agente?
• Come comunico con esso?
• Quali input accetta?
• Quali output può produrre?
• Come traccio il lavoro?
• Come ricevo il risultato?

Queste sei domande definiscono il confine del protocollo che A2A sta cercando di stabilire tra agenti che operano in modo indipendente.

Perché Esiste A2A

I sistemi AI stanno passando da singoli assistenti a reti di agenti specialisti.

Un’azienda potrebbe avere:

• Un agente di supporto
• Un agente per la fatturazione
• Un agente per la revisione legale
• Un agente DevOps
• Un agente per l’analisi dei dati
• Un agente di ricerca
• Un agente per la documentazione
• Un agente per la revisione del codice

Ogni agente può avere i propri strumenti, permessi, conoscenza del dominio, prompt, memoria, sistema di recupero e regole di audit.

Senza un protocollo condiviso, ogni integrazione diventa personalizzata: l’agente di supporto ha bisogno di cablaggi su misura per l’agente di fatturazione, l’agente di fatturazione ha bisogno dei propri per l’agente legale e l’agente di ricerca ne ha bisogno di altri ancora per l’agente di documentazione. Questo sovraccarico combinatorio non scala bene man mano che la rete di agenti cresce.

A2A fornisce a questi agenti un modo comune di interagire, riducendo il problema di integrazione N×M a un singolo contratto condiviso. La promessa non è l’autonomia magica; la promessa è l’interoperabilità.

A2A Non È MCP

A2A viene spesso confrontato con MCP, ma risolvono problemi diversi.

MCP, o Model Context Protocol, riguarda principalmente la connessione di un’app o agente AI a strumenti, risorse e prompt, mentre A2A riguarda principalmente la connessione di agenti ad altri agenti.

Un modello mentale utile è:

MCP: agente verso strumento
A2A: agente verso agente

Ad esempio, un agente può utilizzare MCP per accedere a:

• GitHub
• un filesystem
• un database
• Slack
• un sistema di ricerca nella documentazione
• un’API cloud

Sono disponibili guide pratiche per costruire questi server MCP per Go e Python.

Lo stesso agente può utilizzare A2A per delegare il lavoro a:

• un agente di revisione della sicurezza
• un agente di ricerca
• un agente di pianificazione
• un agente di conformità
• un agente di coding

I due protocolli possono e spesso lavorano insieme. Un’architettura pulita è spesso:

A2A al di fuori del confine dell'agente.
MCP all'interno del confine dell'agente.

Ciò significa che altri agenti comunicano con il tuo agente utilizzando A2A, mentre il tuo agente internamente utilizza MCP per accedere agli strumenti, una separazione pulita delle responsabilità che mantiene stabile l’interfaccia esterna indipendentemente dai cambiamenti interni. Per un confronto dettagliato su come i due protocolli dividono la responsabilità architettonica e quando è necessario utilizzare entrambi, vedi A2A vs MCP: Gli Agenti AI Hanno Davvero Bisogno di Entrambi i Protocolli?

Ruoli Fondamentali in A2A

A2A utilizza un modello di ruoli semplice basato su due parti: un agente che espone capacità e un client che vuole utilizzarle.

Il client potrebbe essere:

• un altro agente
• un orchestratore
• un’applicazione assistente
• un sistema di workflow
• un gateway
• un banco di prova (test harness)
• un’applicazione front-end per l’utente

L’agente potrebbe essere:

• un servizio AI specializzato
• un assistente di dominio
• un agente proprietario di un workflow
• un agente vendor remoto
• un agente enterprise interno

La cosa importante è che l’agente non è solo una funzione. Possiede una certa capacità e la espone attraverso un’interfaccia agente.

Agent Card (Schede Agente)

La Agent Card è uno dei concetti più importanti in A2A.

Una Agent Card descrive un agente: è il documento di scoperta che dice ai client cosa è l’agente, cosa può fare, come comunicare con esso e quali vincoli si applicano.

Pensa alla Agent Card come a un mix di:

• metadati del servizio
• dichiarazione di capacità
• documento di scoperta API
• profilo dell’agente
• superficie del contratto

Una Agent Card tipica può descrivere cose come:

• nome dell’agente
• descrizione
• endpoint del servizio
• funzionalità del protocollo supportate
• modalità di input e output supportate
• competenze disponibili
• requisiti di autenticazione
• informazioni sul provider
• informazioni sulla versione
• link alla documentazione
• metadati opzionali

La Agent Card è importante perché gli agenti non dovrebbero aver bisogno di conoscenze hardcoded di ogni altro agente.

Un client può ispezionare la card e decidere:

• È questo l’agente giusto per il lavoro?
• Supporta il tipo di contenuto di cui ho bisogno?
• Supporta lo streaming?
• Richiede autenticazione?
• Quali competenze pubblicizza?
• Può restituire il tipo di artefatto di cui ho bisogno?

Nei sistemi pratici, le Agent Card diventano la base per registri di agenti, portali per sviluppatori e cataloghi interni di agenti — l’equivalente leggibile da macchina di un directory di servizi dove i client possono cercare cosa è disponibile prima di impegnarsi in un’integrazione.

Le Agent Card Sono Confini di Capacità

Una Agent Card non dovrebbe essere trattata come testo di marketing: è un confine di capacità su cui altri sistemi si baseranno in fase di esecuzione.

Se la tua scheda agente dice che il tuo agente può eseguire analisi finanziarie, i client potrebbero iniziare a delegargli lavoro di analisi finanziaria. Se dice che l’agente accetta file, i client potrebbero inviare file. Se dice che l’agente supporta lo streaming, i client potrebbero aspettarsi eventi di progresso.

Agent Card cattive creano sistemi cattivi perché le decisioni di routing e le assunzioni di capacità si propagano attraverso l’intera rete di agenti. Una Agent Card utile dovrebbe essere:

• specifica
• accurata
• stabile
• versionata
• consapevole della sicurezza
• onesta riguardo ai limiti

Una competenza vaga come “esegue attività aziendali” non è utile.

Una competenza migliore è:

Analizza i dati delle fatture SaaS e produce un riepilogo delle spese mensili.

Ancora meglio, includi le modalità di input e output attese.

Input: record di fatture CSV o JSON.
Output: riepilogo in Markdown e totali JSON strutturati.

Più precisa è la Agent Card, più facile è per altri agenti instradare i compiti correttamente.

Scoperta degli Agenti

La scoperta degli agenti è il processo di ricerca di una Agent Card.

Nei deployment semplici, la scoperta può essere statica. Un client già conosce l’URL di un agente specifico.

Nei deployment più grandi, la scoperta può coinvolgere:

• un registro
• un portale per sviluppatori
• un catalogo interno
• scoperta basata su DNS
• gestione della configurazione
• routing specifico per ambiente
• gateway consapevoli del tenant

La scelta di progettazione importante è se la scoperta sia pubblica, privata o autorizzata.

Non ogni agente dovrebbe essere scopribile da tutti: un agente di stipendio interno non dovrebbe esporre la stessa Agent Card a ogni chiamante, e un agente partner potrebbe vedere solo competenze sicure per i partner. La scoperta degli agenti non è solo una funzione di comodità; è parte del tuo modello di sicurezza e governance, e lo scoping della visibilità è una decisione di progettazione di primo livello.

Task (Compiti)

Un Task rappresenta il lavoro svolto da un agente.

È qui che A2A diventa più interessante delle semplici API di richiesta e risposta.

Alcune interazioni degli agenti sono rapide. Un client invia un messaggio e l’agente restituisce una risposta diretta.

Ma molti flussi di lavoro degli agenti reali non sono istantanei.

Un task potrebbe coinvolgere:

• la ricerca in più fonti
• la richiesta di chiarimenti
• la chiamata di strumenti
• la delega di lavoro
• l’attesa di approvazione
• la generazione di un report
• la produzione di file
• lo streaming dei progressi
• la gestione dei tentativi
• il ritorno di più artefatti

A2A modella questo tipo di lavoro come un Task, dando al lavoro un’identità e un ciclo di vita, il che è importante perché il lavoro degli agenti a lunga esecuzione deve essere tracciato, ispezionato e potenzialmente annullato o riprovato.

Ciclo di Vita del Task

Un task può passare attraverso diversi stati.

Il modello esatto dello stato dipende dalla versione del protocollo e dall’implementazione, ma l’idea di base è semplice:

• inviato (submitted)
• in lavorazione (working)
• input richiesto
• completato
• fallito
• annullato
• rifiutato

Il punto importante è che un task non è solo un payload di risposta: è un’unità di lavoro in corso con il proprio stato che un client può interrogare in qualsiasi momento. Un client può usare lo stato del task per capire cosa sta succedendo:

• L’agente ha accettato il task?
• Sta ancora lavorando?
• Ha bisogno di più input?
• Ha finito con successo?
• È fallito?
• È stato annullato?
• Ci sono artefatti disponibili?

Questo è particolarmente utile per flussi di lavoro che richiedono secondi, minuti o più.

Ad esempio, un agente di ricerca potrebbe restituire un task immediatamente, continuando poi a lavorare in background mentre trasmette eventi di progresso o rende il risultato disponibile in seguito.

Messaggio Stateless o Task Stateful

A2A supporta sia interazioni semplici che complesse.

Per un’interazione semplice, un agente può restituire un Messaggio diretto; per un’interazione complessa, può restituire un Task. Questa distinzione è importante perché non tutto ha bisogno del tracciamento dei task e l’eccedenza di progettazione di interazioni brevi in flussi di lavoro di task completi aggiunge un sovraccarico inutile.

Se un client chiede:

Riassumi questo unico paragrafo.

Una risposta diretta potrebbe essere sufficiente.

Se un client chiede:

Ricerca i primi cinque database vettoriali open source, confrontali e produce una raccomandazione di migrazione.

Un task è più appropriato.

La regola pratica è semplice: usa un Messaggio diretto per interazioni semplici e immediate e usa un Task per lavori a lunga esecuzione, con stato, auditabili o che producono artefatti.

Messaggi

I messaggi sono le unità di comunicazione scambiate tra client e agente.

Un messaggio può contenere una o più parti.

Un messaggio può rappresentare:

• una richiesta dell’utente
• una risposta dell’agente
• una domanda di chiarimento
• input aggiuntivo
• comunicazione relativa al task
• contesto dei progressi
• istruzioni strutturate

I messaggi non sono solo stringhe: la comunicazione degli agenti spesso ha bisogno di trasportare molto più del semplice testo e la struttura del messaggio è progettata per accommodate questo.

Un messaggio potrebbe includere:

• testo
• file
• JSON strutturato
• immagini
• riferimenti
• metadati

Il messaggio è la busta; le parti sono il contenuto tipizzato effettivo al suo interno.

Parts (Parti)

Una Part è un pezzo di contenuto all’interno di un messaggio o di un artefatto.

È così che A2A supporta la comunicazione multimodale e strutturata.

Una parte può contenere diversi tipi di contenuto, come:

• testo
• dati file
• dati strutturati
• contenuto binario per riferimento
• dati simili a JSON

Una parte può anche includere metadati come:

• tipo di media
• nome del file
• contesto aggiuntivo

Il tipo di media è importante perché dice all’agente ricevente come interpretare il contenuto.

Ad esempio:

text/plain
application/json
text/markdown
image/png
application/pdf
text/csv

Questo è uno degli aspetti sottovalutati di A2A. La comunicazione degli agenti non dovrebbe ridurre tutto a testo semplice: se un agente a valle ha bisogno di un foglio di calcolo, un’immagine, un payload JSON, un file di log o un PDF, il protocollo dovrebbe preservare quel contenuto come contenuto piuttosto che manipolarlo in un paragrafo. I buoni sistemi di agenti evitano questi colli di bottiglia testuali inutili permettendo a ogni parte di trasportare il suo tipo di media naturale fino al consumatore.

Artifacts (Artefatti)

Gli artefatti sono output concreti prodotti da un agente durante l’elaborazione del task.

Questo è diverso da un messaggio generale: un messaggio è una comunicazione tra agenti, mentre un artefatto è un deliverable concreto che il task ha prodotto.

Esempi di artefatti includono:

• un report in markdown
• un risultato di analisi JSON
• un export CSV
• un’immagine generata
• un documento PDF
• una patch di codice
• un file di risultato del test
• un piano di deployment
• un diagramma
• un estratto di dati

Questa distinzione è utile nella pratica. Quando un agente di ricerca dice “Ho trovato la risposta”, quello è un messaggio. Quando restituisce market-analysis.md, sources.json e risk-summary.csv, quelli sono artefatti: output concreti che rendono il lavoro del task ispezionabile, riutilizzabile e componibile. L’artefatto di un agente diventa l’input di un altro agente senza alcuna perdita di struttura.

Messaggi vs Artefatti

Un modo semplice per pensarci:

I messaggi sono conversazione.
Gli artefatti sono output.

I messaggi aiutano gli agenti a coordinarsi; gli artefatti sono ciò che il task ha effettivamente prodotto.

Ad esempio, in un flusso di lavoro di sviluppo software:

• Il client invia un messaggio chiedendo una correzione di bug.
• L’agente di coding invia messaggi con domande di chiarimento.
• L’agente di coding lavora sul task.
• L’agente restituisce artefatti come un file patch, l’output del test e una spiegazione.

Questa separazione è utile perché evita di mescolare il coordinamento del task con i deliverable, rendendo molto più facile registrare, auditare e passare gli output ai consumatori a valle.

Un Esempio Pratico

Immagina che un assistente primario abbia bisogno dell’aiuto di un agente di documentazione.

L’utente chiede:

Crea la documentazione per gli sviluppatori per la nostra nuova API webhook di fatturazione.

L’assistente primario controlla un registro degli agenti e trova un agente di documentazione.

L’agente di documentazione ha una Agent Card che dice che può:

• scrivere documentazione API
• accettare specifiche OpenAPI
• accettare guide di stile Markdown
• produrre documenti Markdown
• produrre esempi in Python e JavaScript
• supportare task a lunga esecuzione
• restituire artefatti

L’assistente primario invia un messaggio con:

• una breve istruzione
• un file OpenAPI
• una guida di stile
• metadati sul pubblico di destinazione

L’agente di documentazione crea un Task.

Il task entra in uno stato di lavorazione.

L’agente di documentazione può inviare messaggi come:

Sto estraendo le descrizioni degli endpoint.

Poi:

Ho bisogno di chiarimenti sugli esempi di autenticazione.

L’assistente primario fornisce l’input mancante.

Il task continua.

Infine, l’agente di documentazione restituisce artefatti:

billing-webhooks.md
billing-webhook-examples-python.md
billing-webhook-examples-javascript.md

Questo è il modello A2A in azione: non solo “chiama questa funzione” ma “delega questo task a un altro agente, comunica come necessario e traccia il risultato fino al completamento”.

Perché i Task Sono Importanti per i Sistemi Reali

I Task sono ciò che rende A2A adatto per flussi di lavoro seri.

Una normale chiamata API HTTP è spesso troppo sottile per il lavoro degli agenti. I task degli agenti possono coinvolgere incertezza, più passaggi, risultati intermedi e domande di follow-up.

Un Task ti dà un posto per allegare:

• stato
• cronologia
• messaggi
• artefatti
• errori
• metadati
• progresso
• cancellazione
• informazioni di audit

Questo è utile per:

• flussi di lavoro di ricerca
• generazione di codice
• analisi dei dati
• revisione della conformità
• produzione di documenti
• indagine sugli incidenti
• pianificazione in più fasi
• flussi di lavoro di approvazione umana

Senza un modello di task, gli sviluppatori di solito ricostruiscono questa logica personalmente con ID di lavoro personalizzati, code, endpoint di stato e callback webhook: A2A cerca di standardizzare la versione specifica degli agenti di questo schema in modo che tu non debba reinventarlo per ogni nuova integrazione degli agenti.

Streaming e Lavoro Asincrono

A2A supporta l’idea che il lavoro degli agenti possa essere in streaming o asincrono.

Lo streaming è utile quando il client vuole aggiornamenti in tempo reale.

Ad esempio:

• eventi di progresso
• risultati parziali
• stato intermedio
• testo generato
• aggiornamenti dei passaggi

I flussi di lavoro asincroni sono utili quando il task può richiedere molto tempo o il client non può mantenere una connessione aperta.

Ad esempio:

• ricerca in background
• generazione di documenti grandi
• revisione multi-agente
• elaborazione dei dati
• approvazione umana
• analisi batch

Nella pratica, un sistema A2A robusto dovrebbe essere progettato attorno a tre modalità: risposta immediata per il lavoro semplice, streaming per il lavoro interattivo a lunga esecuzione e asincrono per il lavoro di background durevole che può sopravvivere a qualsiasi singola connessione.

Agent Card e Supporto allo Streaming

Una Agent Card può pubblicizzare se un agente supporta lo streaming.

Questo è importante perché i client non possono assumere che ogni agente supporti lo streaming: alcuni agenti potrebbero supportare solo la semplice richiesta e risposta, alcuni potrebbero supportare il polling dei task e altri potrebbero supportare notifiche push o server-sent events. Un buon client ispeziona la Agent Card prima di scegliere un pattern di interazione, ecco perché le Agent Card non sono solo documentazione: influenzano direttamente il comportamento in fase di esecuzione.

A2A e Agenti Multimodali

A2A è progettato per supportare più del semplice testo.

Questo è importante perché i sistemi di agenti reali elaborano sempre più input e output misti:

• testo
• immagini
• audio
• video
• PDF
• fogli di calcolo
• JSON strutturato
• log
• codice
• diagrammi

Se ogni confine dell’agente converte tutto in testo, informazioni importanti possono andare perse.

Ad esempio, un agente di risoluzione dei problemi visivi dovrebbe ricevere un’immagine come immagine, non come una debole descrizione testuale. Un agente finanziario dovrebbe ricevere dati strutturati del foglio di calcolo, non un paragrafo copiato. Un agente di revisione del codice dovrebbe ricevere file sorgente o diff, non un riepilogo vago.

Le Parts e i tipi di media sono il modo in cui A2A preserva contenuti più ricchi attraverso i confini degli agenti — e questo è uno dei luoghi in cui il protocollo è più importante di quanto appaia a prima vista, perché la perdita di informazioni al confine si accumula attraverso ogni salto in una catena multi-agente.

A2A Non È un Framework per Agenti

A2A non ti dice come costruire un agente.

Non definisce:

• strategia di ragionamento
• algoritmo di pianificazione
• sistema di memoria
• database vettoriale
• template di prompt
• provider del modello
• framework degli strumenti
• runtime di orchestrazione
• metodo di valutazione

Questa è una caratteristica, non un bug. A2A è un protocollo di confine che permette a diverse implementazioni di agenti di comunicare senza richiedere loro di condividere la stessa architettura interna — proprio come HTTP non ti dice come costruire un’applicazione web, definisce solo come i sistemi comunicano. A2A dovrebbe essere compreso allo stesso modo.

A2A Non È una Sostituzione per le API

A2A non sostituisce nemmeno ogni API.

Se hai un servizio deterministico con un contratto stabile di richiesta e risposta, una normale API potrebbe essere migliore.

Ad esempio:

• conversione di valuta
• convalida dell’indirizzo
• ricerca fatture
• ridimensionamento immagini
• endpoint di ricerca
• lookup di feature flag
• servizio CRUD interno

Questi non diventano automaticamente agenti solo perché sono chiamati da un sistema AI. A2A ha senso quando il sistema remoto si comporta genuinamente come un agente:

• possiede un task
• può chiedere più input
• può utilizzare strumenti internamente
• può richiedere tempo
• può produrre artefatti
• ha capacità che vale la pena scoprire
• può operare come un pari in un flusso di lavoro più ampio

Non usare A2A solo perché è di moda: usalo quando l’astrazione si adatta genuinamente al problema.

Dove A2A Si Inserisce nell’Architettura dei Sistemi AI

A2A si adatta meglio al confine tra agenti deployabili in modo indipendente.

Un’architettura utile potrebbe essere così:

Utente
  |
  v
Assistente primario
  |
  |-- A2A --> Agente di ricerca
  |-- A2A --> Agente di coding
  |-- A2A --> Agente di conformità
  |-- A2A --> Agente di documentazione

Ogni agente specializzato può utilizzare internamente strumenti:

Agente di ricerca
  |
  |-- MCP --> ricerca web
  |-- MCP --> archivio documenti
  |-- MCP --> database vettoriale

Questo ti dà strati separati:

Strato dell'interfaccia utente
Strato di coordinamento degli agenti
Strato di integrazione degli strumenti
Strato di dati ed esecuzione

A2A vive nello strato di coordinamento degli agenti, MCP spesso vive nello strato di integrazione degli strumenti e normali API, code, database e sistemi di storage vivono sotto di essi — ogni strato con la propria astrazione e i propri modalità di fallimento. Per una mappa trasversale di come l’inferenza LLM, la memoria, il routing, gli strumenti e l’osservabilità si combinano all’interno degli assistenti di produzione, vedi Architettura degli Assistenti AI: LLM, Memoria, Strumenti, Routing, Osservabilità.

Pattern Architettonico: Orchestratore e Specialisti

Il pattern A2A più comune è probabilmente orchestratore più specialisti.

In questo pattern, un agente primario riceve la richiesta dell’utente e delega pezzi di lavoro a agenti specialisti.

Esempio:

Assistente primario
  |
  |-- A2A --> Agente legale
  |-- A2A --> Agente finanziario
  |-- A2A --> Agente di ricerca
  |-- A2A --> Agente di scrittura

Questo pattern è facile da capire: l’orchestratore possiede il flusso di lavoro generale e gli agenti specialisti possiedono il lavoro specifico del dominio. Lo svantaggio è che l’orchestratore può diventare un collo di bottiglia e ha bisogno di una solida strategia di routing per delegare efficacemente — la selezione del modello sottostante e i compromessi di orchestrazione sono trattati in Design del Sistema Multi-Modello: Quando un Modello Non Basta. Tuttavia, per la maggior parte dei team, questa è la migliore architettura multi-agente iniziale da raggiungere prima di esplorare topologie più complesse.

Pattern Architettonico: Agenti Pari

In un pattern peer-to-peer, gli agenti possono comunicare tra loro più direttamente.

Ad esempio:

Agente di ricerca --> Agente dei dati --> Agente di grafici --> Agente di scrittura

Questo può essere potente, ma è più difficile da controllare.

Hai bisogno di regole forti per:

• chi può chiamare chi
• quale contesto può essere condiviso
• come sono prevenuti i loop
• chi possiede l’output finale
• come è controllato il costo
• come è auditata la delega

Le reti di agenti pari suonano eleganti, ma possono diventare caotiche rapidamente: usale solo quando hai regole di governance forti e un chiaro controllo su ogni bordo nel grafo.

Pattern Architettonico: Gateway A2A

Un pattern più adatto alla produzione è un gateway A2A.

Invece che ogni agente chiami direttamente ogni altro agente, il traffico fluisce attraverso un gateway.

Il gateway può gestire:

• autenticazione
• autorizzazione
• routing
• mappatura del tenant
• logging
• limiti di frequenza
• controlli delle policy
• gestione della versione del protocollo
• osservabilità
• tracce di audit

Questo è particolarmente utile negli ambienti enterprise, dove il gateway diventa il piano di controllo per la comunicazione degli agenti — applicando la policy in un unico luogo invece di reimplementarla attraverso ogni agente. Nei sistemi più piccoli questo potrebbe essere eccessivo, ma nei sistemi più grandi con più team e fornitori spesso diventa necessario prima del previsto.

Considerazioni sulla Sicurezza

La sicurezza di A2A merita una seria attenzione.

La comunicazione agente-agente può spostare contesto sensibile attraverso i confini. Può anche delegare il lavoro a sistemi che possono avere i propri strumenti e permessi.

Le domande di sicurezza fondamentali sono:

• Quali agenti sono autorizzati a scoprire questo agente?
• Quali agenti sono autorizzati a inviargli task?
• Quale autenticazione è richiesta?
• Quali permessi sono associati al chiamante?
• Un agente può delegare l’autorità dell’utente a un altro?
• Quali dati possono essere inclusi nei messaggi?
• Quali artefatti possono essere restituiti?
• Come è auditato il task?
• L’agente ricevente può chiamare strumenti o altri agenti?
• Come sono protetti i segreti?

Le Agent Card non dovrebbero contenere segreti statici e le Agent Card sensibili dovrebbero essere protette dietro autenticazione piuttosto che pubblicate apertamente. Client diversi spesso hanno bisogno di viste diverse dello stesso agente: un chiamante interno potrebbe vedere più competenze di un partner esterno, mentre un client pubblico potrebbe vedere solo un set limitato di capacità sicure.

La sicurezza non dovrebbe essere aggiunta dopo che la rete di agenti è costruita; dovrebbe plasmare la rete dall’inizio, perché l’adattamento dei confini di aut e permessi attraverso una topologia di agenti live è significativamente più difficile che progettarli fin dall’inizio.

Considerazioni sull’Osservabilità

I sistemi A2A hanno bisogno di una forte osservabilità.

Quando un task attraversa i confini degli agenti, il debugging diventa sostanzialmente più difficile perché nessun singolo sistema detiene il quadro completo. Devi sapere:

• quale agente ha creato il task
• quale agente l’ha accettato
• quali messaggi sono stati scambiati
• quali cambiamenti di stato si sono verificati
• quali artefatti sono stati prodotti
• quali errori si sono verificati
• quanto tempo ha richiesto ogni passaggio
• quali strumenti sono stati usati internamente
• se è stato chiamato un altro agente
• chi ha approvato azioni rischiose

Una traccia utile dovrebbe seguire il lavoro attraverso l’intera catena.

Ad esempio:

richiesta utente
  -> task assistente primario
  -> task agente di ricerca
  -> chiamata allo strumento di ricerca documenti
  -> artefatto di sintesi
  -> risposta finale

Senza quella traccia end-to-end, i sistemi multi-agente diventano molto difficili da fidarsi in produzione: non puoi rispondere con fiducia perché il sistema ha prodotto un dato output, figuriamoci identificare dove è andato storto. Osservabilità per Sistemi LLM: Metriche, Tracce, Log e Test in Produzione copre il lato strumentazione e tooling di questo problema in profondità.

Errori Comuni

Errore 1: Chiamare Ogni Strumento un Agente

Non ogni strumento è un agente.

Una calcolatrice è uno strumento. Un lettore di file è uno strumento. Un endpoint di query del database è uno strumento.

Se non possiede un task, non chiede input, non produce artefatti o non si comporta come un pari indipendente, probabilmente non ha bisogno di A2A.

Errore 2: Rendere le Agent Card Troppo Vaghe

Una Agent Card non dovrebbe dire:

Questo agente aiuta con le attività aziendali.

Questo è inutile per qualsiasi agente che cerca di instradare il lavoro in modo intelligente. Una buona card dovrebbe dire cosa fa effettivamente l’agente, cosa accetta, cosa restituisce e quali vincoli si applicano.

Errore 3: Ignorare lo Stato del Task

Se usi A2A ma tratti ogni interazione come richiesta e risposta, stai perdendo gran parte del valore.

Il modello di task è uno dei motivi principali per usare A2A rispetto a una normale API — saltarlo significa ricostruire la stessa logica di tracciamento del ciclo di vita in ogni integrazione.

Errore 4: Restituire Tutto come Testo

A2A supporta contenuti strutturati e multimodali. Usalo.

Se l’output è un report, restituisci un artefatto report.

Se l’output è JSON, restituisci dati strutturati.

Se l’output è un file, restituisci un file.

Non appiattire tutto in testo semplice a meno che il testo semplice sia l’output giusto.

Errore 5: Nessun Modello di Permessi

Le reti di agenti senza confini di permessi sono rischiose.

Non ogni agente dovrebbe essere autorizzato a chiamare ogni altro agente con ogni tipo di dati: usa autenticazione, autorizzazione e tracce di audit per applicare il principio del privilegio minimo attraverso la rete di agenti.

Quando Dovresti Usare A2A?

Usa A2A quando hai veri confini di agente.

Buoni motivi includono:

• gli agenti sono posseduti da team diversi
• gli agenti sono deployati come servizi separati
• gli agenti sono costruiti con framework diversi
• gli agenti hanno bisogno di scoprirsi a vicenda
• gli agenti hanno bisogno di delegare task
• i task possono essere a lunga esecuzione
• i risultati possono includere artefatti
• i client non dovrebbero conoscere gli strumenti interni
• i metadati delle capacità degli agenti sono importanti

Motivi deboli includono:

• suona moderno
• vuoi chiamare una sola funzione
• hai un’app a singolo agente
• una normale API funzionerebbe
• MCP risolve già il tuo problema di integrazione degli strumenti

A2A è potente quando il sistema è effettivamente multi-agente; è una cerimonia inutile quando non lo è, e il costo di quella cerimonia — concetti aggiunti, infrastruttura, superficie di debugging e requisiti di sicurezza — è reale.

Un Modello Mentale Minimo

Se ricordi solo una cosa, ricorda questo:

Agent Card: cosa può fare l'agente.
Messaggio: cosa si dicono gli agenti tra loro.
Part: contenuto tipizzato all'interno di un messaggio o artefatto.
Task: lavoro che l'agente possiede.
Artefatto: output prodotto dal task.

Questo è il cuore di A2A — il resto è principalmente rendere questi cinque concetti affidabili, osservabili e sufficientemente sicuri per l’uso in sistemi di produzione reali.

Pensieri Finali

A2A non è solo un altro acronimo AI: è parte di un cambiamento più ampio dagli assistenti isolati ai sistemi di agenti interoperabili. Quel cambiamento non accadrà dappertutto tutto insieme, e molte applicazioni rimarranno sistemi a singolo agente con un buon accesso agli strumenti dove MCP e normali API sono interamente sufficienti.

Ma una volta che gli agenti diventano pari deployati separatamente, hai bisogno di confini più forti: scoperta, proprietà del task, messaggi che trasportano più del testo, artefatti come output di primo livello e sicurezza, stato e osservabilità che attraversano i confini degli agenti. Questo è lo spazio che A2A sta cercando di occupare ed è un problema genuinamente diverso dal problema di integrazione degli strumenti che MCP risolve.

Per una visione pratica su dove A2A ha effettivamente trazione di produzione nel 2026 — incluse le fasce di adozione, le preoccupazioni di sicurezza, il caso d’uso enterprise e un framework decisionale — vedi Protocollo A2A di Google nel 2026: Adozione, Hype e Realtà.

Il mio parere: non iniziare con A2A per piccoli progetti. Inizia con un agente utile, buoni strumenti e un’architettura chiara — il cluster Sistemi AI copre assistenti self-hosted, server MCP e memoria degli agenti come un set connesso se vuoi il contesto più ampio. Ma quando il tuo “strumento” inizia a sembrare un altro specialista autonomo con il proprio ciclo di vita del task, probabilmente non è più solo uno strumento — ed è quando A2A diventa interessante.

Sorgenti

• Specifica del Protocollo A2A: https://a2a-protocol.org/latest/specification/
• Concetti Chiave di A2A: https://a2a-protocol.org/latest/topics/key-concepts/
• Vita di un Task in A2A: https://a2a-protocol.org/latest/topics/life-of-a-task/
• Scoperta degli Agenti in A2A: https://a2a-protocol.org/latest/topics/agent-discovery/
• Streaming e Operazioni Asincrone in A2A: https://a2a-protocol.org/latest/topics/streaming-and-async/
• A2A e MCP: https://a2a-protocol.org/latest/topics/a2a-and-mcp/