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 salta completamente. La maggior parte delle demo presuppone ancora un singolo assistente, un singolo runtime, un singolo ciclo di strumenti e un unico proprietario: l’agente può cercare, chiamare strumenti, scrivere codice, interrogare API, forse usare server MCP e restituire una risposta.

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

I concetti fondamentali sono:

• Schede Agente (Agent Cards)
• Agenti e client
• Task (Compiti)
• Messaggi
• Parti (Parts)
• 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 sistemi multi-agente reali.

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 sue capacità, accettare lavoro, gestire il ciclo di vita di tale lavoro, chiedere 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 potrebbe utilizzare internamente:

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

Il chiamante non ha bisogno di conoscere nessuno di questi dettagli. Ciò che il chiamante deve sapere è:

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

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

Perché esiste A2A

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

Un’azienda potrebbe avere:

• Un agente di supporto
• Un agente di fatturazione
• Un agente di revisione legale
• Un agente DevOps
• Un agente di analisi dati
• Un agente di ricerca
• Un agente di documentazione
• Un agente di revisione del codice

Ogni agente può avere i propri strumenti, permessi, conoscenze di 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 un cablaggio su misura per l’agente di fatturazione, l’agente di fatturazione ha bisogno del suo collegamento con l’agente legale, e l’agente di ricerca ne richiede un altro ancora per l’agente di documentazione. Questo sovraccarico combinatorio non scala bene man mano che la rete di agenti cresce.

A2A offre a questi agenti un modo comune di interagire, riducendo il problema di integrazione N×M a un unico 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’applicazione 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 a strumento
A2A: agente ad agente

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

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

Sono disponibili guide pratiche per la costruzione di 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 codifica

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 utilizza internamente 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à architetturale e quando hai effettivamente bisogno di entrambi, vedi A2A vs MCP: AI Agents Really Need Both Protocols?

Ruoli principali 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 framework di test
• un’app per utenti umani

L’agente potrebbe essere:

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

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

Schede Agente (Agent Cards)

La Scheda Agente è uno dei concetti più importanti in A2A.

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

Pensa a una Scheda Agente come a una combinazione di:

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

Una Scheda Agente 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 fornitore
• informazioni sulla versione
• link alla documentazione
• metadati opzionali

La Scheda Agente è importante perché gli agenti non dovrebbero avere bisogno di una conoscenza hardcoded di ogni altro agente.

Un client può ispezionare la scheda 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 Schede Agente diventano la base per registri di agenti, portali per sviluppatori e cataloghi interni di agenti, l’equivalente leggibile da macchina di un elenco di servizi dove i client possono cercare cosa è disponibile prima di impegnarsi in un’integrazione.

Le Schede Agente sono confini di capacità

Una Scheda Agente non dovrebbe essere trattata come testo pubblicitario: è un confine di capacità su cui altri sistemi faranno affidamento in fase di esecuzione.

Se la tua scheda agente dice che il tuo agente può eseguire analisi finanziarie, i client potrebbero iniziare a delegargli lavori 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.

Le Schede Agente scadenti creano sistemi scadenti perché le decisioni di instradamento e le assunzioni sulle capacità si propagano in cascata in tutta la rete di agenti. Una Scheda Agente 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 produci 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 Scheda Agente, più facile è per altri agenti instradare correttamente i task.

Scoperta degli agenti (Agent Discovery)

La scoperta degli agenti è il processo di ricerca di una Scheda Agente.

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
• instradamento specifico per ambiente
• gateway consapevoli del tenant

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

Non ogni agente dovrebbe essere scopribile da tutti: un agente di stipendi interno non dovrebbe esporre la stessa Scheda Agente a ogni chiamante, e un agente partner potrebbe vedere solo competenze sicure per i partner. La scoperta degli agenti non è solo una funzionalità di convenienza; è parte del tuo modello di sicurezza e governance, e delimitare la visibilità è una decisione di progettazione di primo livello.

Task (Compiti)

Un Task rappresenta il lavoro eseguito da un agente.

Qui 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 workflow reali degli agenti 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
• la trasmissione in 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 esecuzione lunga deve essere monitorato, ispezionato e potenzialmente annullato o ritentato.

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 (input required)
• completato (completed)
• fallito (failed)
• annullato (canceled)
• rifiutato (rejected)

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?

Ciò è particolarmente utile per i workflow che richiedono secondi, minuti o più.

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

Messaggio senza stato o Task con stato

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 monitoraggio dei task e l’eccedenza di progettazione delle interazioni brevi in workflow di task completi aggiunge sovraccarico inutile.

Se un client chiede:

Riassumi questo paragrafo.

Una risposta diretta potrebbe essere sufficiente.

Se un client chiede:

Ricerca i primi cinque database vettoriali open source, confrontali e produci 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 esecuzione lunga, con stato, verificabili 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 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 deve trasportare molto più del semplice testo e la struttura del messaggio è progettata per accogliere questo aspetto.

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.

Parti (Parts)

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

Questo è il modo in cui A2A supporta la comunicazione multimodale e strutturata.

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

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

Una parte può anche includere metadati come:

• tipo multimediale (media type)
• nome del file
• contesto aggiuntivo

Il tipo multimediale è 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 al 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 anziché deformarlo in un paragrafo. I buoni sistemi di agenti evitano questi colli di bottiglia testuali inutili consentendo a ciascuna parte di trasportare il suo tipo multimediale naturale fino al consumatore.

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.

Gli 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 dei 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”, è 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 workflow di sviluppo software:

• Il client invia un messaggio chiedendo una correzione di bug.
• L’agente di codifica invia messaggi con domande di chiarimento.
• L’agente di codifica lavora sul task.
• L’agente restituisce artefatti come un file di patch, output dei test e 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 Scheda Agente 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 esecuzione lunga
• 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 monitora il risultato fino al completamento”.

Perché i Task sono importanti per i sistemi reali

I Task sono ciò che rende A2A adatto per workflow 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
• progressi
• annullamento
• informazioni di audit

Ciò è utile per:

• workflow di ricerca
• generazione di codice
• analisi dei dati
• revisione della conformità
• produzione di documenti
• indagine sugli incidenti
• pianificazione a più fasi
• workflow 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 da non doverla reinventare per ogni nuova integrazione di 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 workflow 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 grandi documenti
• 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 esecuzione lunga e asincrono per il lavoro di background durevole che può sopravvivere a qualsiasi connessione singola. Per SSE, webhook push, nuova sottoscrizione, HITL tramite input_required, gestione degli errori e checklist di produzione, vedi A2A Streaming and Async Tasks for Long-Running Agent Workflows.

Schede Agente e supporto allo streaming

Una Scheda Agente può pubblicizzare se un agente supporta lo streaming.

Questo è importante perché i client non possono presumere che ogni agente supporti lo streaming: alcuni agenti potrebbero supportare solo semplici richieste e risposte, alcuni potrebbero supportare il polling dei task e altri potrebbero supportare notifiche push o eventi server-sent. Un buon client ispeziona la Scheda Agente prima di scegliere un modello di interazione, motivo per cui le Schede Agente non sono solo documentazione: modellano direttamente il comportamento in fase di esecuzione.

A2A e agenti multimodali

A2A è progettato per supportare più del semplice testo.

Questo è importante perché i sistemi reali degli agenti processano 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 un’immagine, non come una descrizione debole di testo. Un agente finanziario dovrebbe ricevere dati strutturati di fogli di calcolo, non un paragrafo copiato. Un agente di revisione del codice dovrebbe ricevere file sorgente o diff, non un riassunto vago.

Le Parti e i tipi multimediali 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 in ogni passaggio di 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 dei prompt
• fornitore 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 che condividano 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 è un sostituto per le API

A2A non sostituisce nemmeno ogni API.

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

Ad esempio:

• conversione di valuta
• convalida dell’indirizzo
• ricerca delle fatture
• ridimensionamento delle immagini
• endpoint di ricerca
• ricerca dei flag delle funzionalità
• 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ò usare strumenti internamente
• può richiedere tempo
• può produrre artefatti
• ha capacità che vale la pena scoprire
• può operare come pari in un workflow più ampio

Non usare A2A solo perché è alla 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 distribuiti in modo indipendente.

Un’architettura utile potrebbe essere simile a questa:

Utente
  |
  v
Assistente primario
  |
  |-- A2A --> Agente di ricerca
  |-- A2A --> Agente di codifica
  |-- 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 le normali API, code, database e sistemi di archiviazione vivono sotto di esso, ciascuno strato con la propria astrazione e i propri modi di fallimento. Per una mappa trasversale di come l’inferenza LLM, la memoria, l’instradamento, gli strumenti e l’osservabilità si integrano all’interno degli assistenti di produzione, vedi AI Assistant Architecture: LLM, Memory, Tools, Routing, Observability.

Pattern architetturale: 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 parti del lavoro agli 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 workflow 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 instradamento per delegare in modo efficace: la selezione del modello sottostante e i compromessi di orchestrazione sono trattati in Multi-Model System Design: When One Model Isn’t Enough. Tuttavia, per la maggior parte dei team, questa è la migliore architettura multi-agente iniziale da adottare prima di esplorare topologie più complesse.

Pattern architetturale: Agenti tra pari

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

Ad esempio:

Agente di ricerca --> Agente 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 vengono prevenuti i loop
• chi possiede l’output finale
• come viene controllato il costo
• come viene auditata la delega

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

Pattern architetturale: 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
• instradamento
• mappatura dei tenant
• registrazione (logging)
• limiti di frequenza
• controlli delle policy
• gestione delle versioni del protocollo
• osservabilità
• tracce di audit

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

Considerazioni sulla sicurezza

La sicurezza A2A merita seria attenzione.

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

Le domande fondamentali sulla sicurezza sono:

• Quali agenti sono autorizzati a scoprire questo agente?
• Quali agenti sono autorizzati a inviargli task?
• Quale autenticazione è richiesta?
• Quali permessi sono allegati 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 viene auditato il task?
• L’agente ricevente può chiamare strumenti o altri agenti?
• Come vengono protetti i segreti?

Le Schede Agente non dovrebbero contenere segreti statici e le Schede Agente sensibili dovrebbero essere protette dietro autenticazione anziché pubblicate apertamente. Client diversi spesso hanno bisogno di diverse visualizzazioni dello stesso agente: un chiamante interno potrebbe vedere più competenze di un partner esterno, mentre un client pubblico potrebbe vedere solo un insieme limitato di capacità sicure.

La sicurezza non dovrebbe essere aggiunta dopo che la rete di agenti è costruita; dovrebbe modellare la rete fin dall’inizio, perché il retrofitting dei confini di autenticazione e permessi attraverso una topologia di agenti live è significativamente più difficile che progettarli direttamente. Per il trattamento completo — modello di minaccia, livelli di identità, piano di controllo del gateway, ambito di delega e tracce di audit — vedi A2A and MCP Agent Security: Identity, Delegation, and Audit Trails.

Considerazioni sull’osservabilità

I sistemi A2A hanno bisogno di una forte osservabilità.

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

• quale agente ha creato il task
• quale agente lo 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 tutta la 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 certo output, tanto meno identificare dove ha sbagliato. Observability for LLM Systems: Metrics, Traces, Logs, and Testing in Production copre l’aspetto dell’istruzionamento e degli strumenti 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 peer indipendente, probabilmente non ha bisogno di A2A.

Errore 2: Rendere le Schede Agente troppo vaghe

Una Scheda Agente non dovrebbe dire:

Questo agente aiuta con le attività aziendali.

Ciò è inutile per qualsiasi agente che cerca di instradare il lavoro in modo intelligente. Una buona scheda 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 non sia l’output corretto.

Errore 5: Nessun modello di permessi

Le reti di agenti senza confini di permessi sono rischiose.

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

Quando dovresti usare A2A?

Usa A2A quando hai veri confini di agenti.

Buoni motivi includono:

• gli agenti sono posseduti da team diversi
• gli agenti sono distribuiti 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 esecuzione lunga
• i risultati possono includere artefatti
• i client non dovrebbero conoscere gli strumenti interni
• i metadati delle capacità degli agenti sono importanti

Motivi deboli includono:

• sembra moderno
• vuoi chiamare una sola funzione
• hai un’applicazione a agente singolo
• 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 il sistema non lo è, e il costo di quella cerimonia — concetti aggiunti, infrastruttura, superficie di debug e requisiti di sicurezza — è reale.

Un modello mentale minimo

Se ricordi solo una cosa, ricorda questa:

Scheda Agente: cosa può fare l'agente.
Messaggio: cosa si dicono gli agenti tra loro.
Parte: contenuto tipizzato all'interno di un messaggio o artefatto.
Task: lavoro posseduto dall'agente.
Artefatto: output prodotto dal task.

Questo è il nucleo di A2A — il resto riguarda principalmente il 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à ovunque contemporaneamente e molte applicazioni rimarranno sistemi a agente singolo con un buon accesso agli strumenti dove MCP e le normali API sono interamente sufficienti.

Ma una volta che gli agenti diventano pari distribuiti 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 un approccio pratico su dove A2A ha effettivamente trazione di produzione nel 2026 — inclusi livelli di adozione, preoccupazioni di sicurezza, il caso d’uso aziendale e un framework decisionale — vedi Google A2A Protocol in 2026: Adoption, Hype, and Reality.

Il mio parere: non iniziare con A2A per progetti piccoli. Inizia con un agente utile, buoni strumenti e un’architettura chiara — il cluster AI Systems copre assistenti self-hosted, server MCP e memoria degli agenti come un insieme 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.

Fonti

• Specifica del protocollo A2A: https://a2a-protocol.org/latest/specification/
• Concetti chiave A2A: https://a2a-protocol.org/latest/topics/key-concepts/
• Vita di un Task A2A: https://a2a-protocol.org/latest/topics/life-of-a-task/
• Scoperta degli agenti A2A: https://a2a-protocol.org/latest/topics/agent-discovery/
• Streaming e operazioni asincrone A2A: https://a2a-protocol.org/latest/topics/streaming-and-async/
• A2A e MCP: https://a2a-protocol.org/latest/topics/a2a-and-mcp/