Fondamenti di IA
Che cos’è Agent2Agent (A2A)? Come gli agenti IA comunicano e collaborano
Agent2Agent è un protocollo aperto per consentire agli agenti di scoprirsi reciprocamente, scambiare messaggi e coordinare il lavoro tra sistemi. Scopri come A2A differisce da MCP e perché gli agenti interoperabili sono importanti.

Agent2Agent (A2A) è un protocollo aperto che consente agli agenti IA di scoprirsi a vicenda, scambiare messaggi, delegare compiti, segnalare i progressi e restituire risultati oltre i confini dei sistemi. È progettato per situazioni in cui un agente ha bisogno di assistenza da parte di un altro senza richiedere a nessuna delle due parti di esporre il proprio ragionamento interno, la memoria o l’implementazione.
Man mano che le organizzazioni implementano agenti specializzati, la comunicazione diventa un problema di infrastruttura. Un agente di approvvigionamento può aver bisogno di informazioni da un agente di conformità; un agente di assistenza clienti può aver bisogno di un agente logistico per indagare su una spedizione. A2A fornisce un modo comune per coordinare quel lavoro anche quando gli agenti utilizzano framework, fornitori o modelli diversi.
Perché gli agenti hanno bisogno di uno standard di comunicazione
Le API tradizionali espongono funzioni e dati, ma un’interazione agente‑a‑agente può essere più aperta. L’agente ricevente potrebbe dover interpretare un obiettivo, decidere come risolverlo, porre domande di approfondimento, lavorare per minuti o ore, trasmettere aggiornamenti in tempo reale e restituire diversi artefatti.
Senza un protocollo condiviso, ogni piattaforma definirebbe i propri formati per identità, scoperta delle capacità, compiti, messaggi, stato ed errori. Tale frammentazione rende difficile la delega cross‑platform e vincola gli agenti utili all’interno di prodotti individuali.
A2A standardizza lo strato di comunicazione consentendo a ciascun agente di rimanere una scatola nera. L’attuale specifica A2A definisce gli oggetti e le interazioni principali del protocollo.
I ruoli chiave in A2A
Questa separazione è ciò che rende A2A diverso da una semplice chiamata di funzione. Il partecipante remoto può gestire un compito a lungo termine, richiedere informazioni aggiuntive, negoziare i tipi di contenuto supportati e restituire uno o più artefatti. L’agente client tiene traccia di quel compito preservando l’identità e l’autorità dell’utente o dell’applicazione che lo ha avviato.
Un’interazione A2A di solito coinvolge due ruoli logici:
- Client agent: l’agente o l’applicazione che richiede il lavoro.
- Remote agent: l’agente che riceve la richiesta e svolge o coordina il lavoro.
Le parole “client” e “remote” descrivono l’interazione corrente, non una gerarchia permanente. Lo stesso agente può richiedere lavoro in un contesto e servire un altro agente in un contesto diverso.
Card degli agenti: scoperta delle capacità
Prima di delegare un compito, un client deve sapere cosa può fare un agente remoto e come comunicare con lui. A2A utilizza una Card dell’agente per pubblicare metadati descrittivi e operativi.
Una Card dell’agente può descrivere il nome dell’agente, l’endpoint, le funzionalità del protocollo supportate, le aspettative di autenticazione, le competenze e i tipi di contenuto accettati. Una competenza è un’area di capacità dichiarata, ad esempio tradurre un documento, verificare un contratto o ricercare un mercato.
La scoperta non dimostra qualità o affidabilità. Una Card dell’agente è una dichiarazione di capacità, non una certificazione indipendente. I sistemi di produzione hanno comunque bisogno di controlli di identità, autorizzazione, politiche, reputazione e valutazione.
Messaggi, compiti e artefatti
A2A rappresenta la collaborazione attraverso diversi oggetti principali.
Messaggi
I messaggi trasportano la comunicazione tra gli agenti. Possono contenere testo e altre parti strutturate, consentendo agli agenti di scambiare istruzioni, chiarimenti o materiale contestuale.
Compiti
Un compito rappresenta un’unità di lavoro il cui stato può cambiare nel tempo. Un agente remoto può accettare il lavoro, continuare l’elaborazione, richiedere ulteriori input, completarlo, fallire o annullarlo. Un’identità di compito persistente è utile per operazioni a lungo termine perché il client può fare riferimento allo stesso lavoro durante gli aggiornamenti.
Artefatti
Gli artefatti sono i risultati prodotti dal lavoro, come un rapporto, un set di dati, un’immagine, una patch di codice o una raccomandazione strutturata. Separare gli artefatti dai messaggi conversazionali facilita al client l’identificazione e il consumo delle consegne finali.
Come funziona un’interazione A2A
| A2A | Coordina il lavoro e i messaggi tra agenti autonomi. |
|---|---|
| MCP | Connette un host AI a strumenti, risorse e prompt. |
| Esigenza condivisa | Identità, autorizzazione limitata, messaggi strutturati e risultati verificabili. |
| Fallimento | Un agente ricevente si fida di una richiesta o di un artefatto senza verificarne l’autorità o le evidenze. |
Supponiamo che un agente di pianificazione viaggi abbia bisogno di uno specialista per verificare i requisiti di ingresso.
- Il cliente scopre un agente remoto e legge la sua Scheda Agente.
- Verifica che l’agente offra la capacità pertinente e un metodo di interazione compatibile.
- Il cliente si autentica e invia un messaggio descrivendo il compito, i viaggiatori, le date e l’output richiesto.
- L’agente remoto crea o aggiorna un compito e inizia a lavorare.
- L’agente remoto può trasmettere i progressi o richiedere un dettaglio mancante.
- Il cliente fornisce la chiarificazione preservando il contesto del compito.
- L’agente remoto completa il compito e restituisce un artefatto strutturato con il risultato.
- Il cliente valuta quel risultato prima di usarlo nel piano di viaggio più ampio.
L’agente remoto decide come svolgere il suo incarico. Può chiamare i propri strumenti, consultare dati privati o coordinare agenti aggiuntivi. A2A non richiede che tali passaggi interni siano rivelati.
A2A vs. MCP
I protocolli possono trovarsi a diversi livelli della stessa architettura. Un agente di pianificazione viaggi potrebbe delegare un compito specialistico di ricerca dei visti tramite A2A. Quell’agente specialista potrebbe quindi utilizzare le connessioni MCP per cercare nei database approvati e recuperare i documenti di politica. A2A coordina la responsabilità tra gli agenti; MCP standardizza l’accesso tra un host AI e le capacità.
A2A e il Model Context Protocol risolvono diversi problemi di integrazione.
- MCP collega un’applicazione AI a strumenti e contesto. Un cliente scopre capacità come funzioni, risorse e prompt da un server MCP.
- A2A collega agenti ad agenti. Un cliente delega un compito orientato al risultato a un agente remoto che può gestire il proprio processo e restituire un risultato.
La differenza è simile all’uso di uno strumento rispetto all’assunzione di uno specialista. Un calcolatore espone un’operazione; un analista accetta un obiettivo e decide quali operazioni sono necessarie. Nei sistemi reali, un agente remoto A2A può utilizzare MCP internamente per accedere ai propri strumenti e dati.
A2A vs. API ordinarie
Un’API convenzionale è ideale quando il chiamante conosce l’operazione esatta e il formato di input: recuperare un record, calcolare un preventivo o aggiornare un campo. A2A è utile quando la richiesta è conversazionale, con stato, asincrona o orientata al risultato.
A2A non sostituisce tutte le API. Gli agenti remoti spesso chiamano API ordinarie per svolgere il loro lavoro, e le organizzazioni possono esporre servizi deterministici direttamente quando la discrezione dell’agente non aggiunge valore.
Perché l’interoperabilità è importante
Gli ecosistemi di agenti saranno eterogenei. Team diversi ottimizzeranno per domini, modelli, confini di sicurezza e ambienti di distribuzione differenti. Un protocollo condiviso consente alle organizzazioni di preservare tale specializzazione favorendo al contempo la collaborazione.
L’interoperabilità può anche ridurre l’accoppiamento dell’integrazione. Un client può fare affidamento su una competenza dichiarata e sul comportamento del protocollo invece di importare il framework dell’agente remoto o duplicare la sua logica interna. La panoramica del progetto A2A descrive questo obiettivo come la capacità di consentire a agenti costruiti su stack diversi di comunicare come pari; l’aggiornamento del progetto del 2026 sull’adesione alla Agentic AI Foundation riflette la spinta verso una governance neutrale e intersettoriale.
Sfide di sicurezza e fiducia
La delega crea una catena di responsabilità. Il client deve verificare l’identità dell’agente remoto e la capacità pubblicizzata, ridurre al minimo il contesto condiviso e preservare l’autorizzazione dell’utente che avvia l’operazione. L’agente remoto non dovrebbe ereditare privilegi ampi solo perché un altro agente ha richiesto il compito. Ogni salto richiede autenticazione, credenziali limitate, tracciabilità e una regola chiara su cosa accade quando i requisiti sono in conflitto o la fiducia è bassa.
La delega agente‑a‑agente crea una catena di autorità. Un client può condividere accidentalmente contesto sensibile, concedere a un agente remoto più discrezione del previsto o agire su un artefatto inaffidabile. L’agente remoto può anche ricevere istruzioni o file dannosi da un client non affidabile.
Le implementazioni robuste necessitano di controlli a più livelli:
- Identità e autenticazione: verifica quale agente e organizzazione stanno partecipando.
- Autorizzazione: limita le competenze, i dati, le azioni e l’ambito del compito disponibili per ogni chiamante.
- Minimizzazione dei dati: condividi solo il contesto di cui l’agente remoto ha bisogno.
- Provenienza: registra chi ha richiesto il lavoro, quale agente lo ha prodotto e quali fonti lo supportano.
- Validazione dell’output: tratta gli artefatti remoti come non attendibili finché non superano i controlli pertinenti.
- Limiti di delega: controlla se un agente remoto può coinvolgere agenti o servizi aggiuntivi.
- Approvazione umana: metti in pausa prima di azioni finanziarie, legali, esterne, distruttive o comunque con conseguenze.
La compatibilità del protocollo non implica fiducia organizzativa. Un agente può parlare correttamente A2A e comunque risultare inappropriato per un compito specifico.
Quando i team dovrebbero usare A2A?
A2A è più interessante quando agenti indipendenti devono collaborare attraverso confini di prodotto, fornitore o organizzazione; quando il lavoro è di lunga durata; o quando il sistema ricevente deve mantenere la libertà su come produce il risultato.
Potrebbe non essere necessario per una funzione semplice, un flusso di lavoro interno fisso o componenti strettamente accoppiati all’interno di un’unica applicazione. In tali casi, un’API ordinaria, un bus di eventi o una chiamata diretta a uno strumento può essere più facile da gestire e valutare.
Cosa ricordare su cos’è Agent2Agent (A2A)
A2A fornisce un linguaggio comune per consentire agli agenti di scoprire capacità e coordinare lavori orientati agli obiettivi senza condividere la loro struttura interna. Il suo valore fondamentale non è che più agenti siano automaticamente migliori di uno solo, ma che specialisti costruiti in modo indipendente possano collaborare attraverso un confine stabile.
Quel confine deve trasportare più dei messaggi. Richiede identità, stato del compito, artefatti, autorizzazioni, provenienza e gestione dei fallimenti. A2A fornisce la base del protocollo; le organizzazioni forniscono comunque il modello di fiducia.












