Protocollo A2A: come far collaborare gli agenti e quando serve MCP

Il protocollo A2A serve quando un agente deve delegare un'attività a un altro agente gestito in modo indipendente. Model Context Protocol (MCP) serve invece per accedere a strumenti o dati. Con A2A v1.0 cambia il contratto di integrazione: la scelta dipende quindi sia dal confine tra i sistemi da collegare, sia dalle versioni supportate dagli endpoint.

MCP vs A2A: accesso agli strumenti o delega del lavoro?

MCP permette a un agente di accedere a funzionalità esterne. A2A gli permette di affidare a un altro agente la responsabilità di un'attività. I due protocolli possono convivere nello stesso sistema.

Model Context Protocol (MCP) standardizza il collegamento tra un'applicazione AI e sistemi esterni, compresi strumenti e fonti di dati. Agent2Agent (A2A) standardizza la comunicazione tra agenti indipendenti. La documentazione ufficiale li descrive come complementari. Introduzione a MCP, A2A e MCP.

Esempio con MCP: consultare un ordine

Immaginiamo un agente di assistenza clienti che deve rispondere a una domanda sulla consegna. Un server MCP espone uno strumento per consultare gli ordini. L'agente passa l'identificativo dell'ordine, ne riceve i dati e scrive la risposta al cliente.

Il vantaggio per l'azienda è un collegamento riutilizzabile al sistema degli ordini. Non occorre introdurre un altro agente solo per recuperare un record. La guida ai server MCP approfondisce questo aspetto della scelta: il collegamento agli strumenti.

Esempio con A2A: delegare la selezione dei fornitori

Immaginiamo un assistente agli acquisti che deve ottenere una rosa di fornitori adatti. Un agente separato, gestito da un altro fornitore di servizi, si occupa dell'intero processo di ricerca. L'assistente agli acquisti invia i requisiti, risponde a una richiesta di chiarimento sulle esigenze di consegna e riceve una lista strutturata di candidati.

L'assistente agli acquisti non deve sapere come l'agente specializzato svolge le ricerche, quale modello usa o come organizza i passaggi interni. Gli servono una richiesta concordata e un risultato utile. È questo il confine tra sistemi che A2A è progettato per gestire.

L'agente di ricerca potrebbe usare MCP al proprio interno per recuperare i dati dei cataloghi. In questa architettura, A2A veicola la delega; MCP fornisce l'accesso ai dati.

La distinzione riguarda l'interfaccia necessaria. Anche dietro uno strumento MCP può esserci una logica di implementazione sofisticata. A2A è la scelta adatta quando si vuole esporre l'altro sistema come un agente con competenze individuabili e un ciclo di vita del lavoro. La decisione non dovrebbe dipendere da quanto sembrano intelligenti i suoi meccanismi interni.

Che cos'è il protocollo A2A?

A2A è un contratto di comunicazione comune per agenti realizzati da fornitori diversi o con framework differenti. Permette a chi effettua la chiamata di interagire con un agente senza accedere alla sua memoria interna, ai suoi strumenti o alla sua logica decisionale. Il sito del protocollo definisce opachi questi elementi interni. Panoramica di A2A.

Chi effettua la chiamata è il client A2A; il sistema che riceve la richiesta è il server A2A, detto anche agente remoto. Per un fondatore che acquista un servizio specializzato, questo consente di concentrare l'integrazione sull'interfaccia del servizio, senza dover ricostruire l'implementazione dello specialista.

Chi ha sviluppato A2A e chi ne guida il progetto?

Il sito ufficiale usa una formulazione precisa: «A2A è stato sviluppato originariamente da Google e donato alla Linux Foundation». Specifica inoltre che la manutenzione del progetto è affidata a un Technical Steering Committee. Il progetto ha quindi una struttura di governance che va oltre il suo sviluppatore originario. Governance e open source.

Il repository a2aproject/A2A è il punto di partenza per trovare la specifica, i link agli SDK e gli esempi. A2A è un protocollo: resta da scegliere il software con cui costruire e gestire gli agenti.

Specifica A2A: i concetti da conoscere

La distinzione fondamentale è tra la conversazione, il lavoro di cui si segue l'avanzamento e il risultato da consegnare. Tenerli separati rende più semplice progettare un sistema basato sul protocollo.

Agent Card: come il client scopre cosa offre un agente

Una Agent Card è un documento di metadati JSON che descrive identità, competenze, funzionalità, informazioni di connessione e requisiti di autenticazione di un agente. Aiuta il client a stabilire se contattarlo e come farlo. Concetti fondamentali.

Nell'esempio degli acquisti, la scheda potrebbe dichiarare competenze nella ricerca di fornitori. È il punto di partenza dell'integrazione, ma non dimostra che la lista prodotta rispetterà i criteri di acquisto.

Il percorso well-known documentato per individuare la scheda è /.well-known/agent-card.json. Le schede si possono ottenere anche tramite configurazione diretta o un registro curato. A2A non prescrive un'API standard per questi registri. Individuazione degli agenti.

Task, messaggi, Part e artefatti

Un task è un'unità di lavoro che mantiene uno stato, con un identificativo e un ciclo di vita. Un messaggio è un turno di comunicazione. Una Part contiene il testo effettivo, il contenuto o il riferimento a un file, oppure dati strutturati. Un artefatto è un risultato concreto prodotto durante un task. Concetti fondamentali.

Nell'esempio dei fornitori, «In quale area devono avvenire le consegne?» è una comunicazione. L'incarico di ricerca di cui si segue l'avanzamento è il task. La lista finale dei candidati è un artefatto. Il processo di acquisto dovrebbe acquisire quella lista come risultato consegnato, senza cercare nella trascrizione della conversazione qualcosa che sembri definitivo.

Un agente può restituire un messaggio autonomo oppure creare un task. Le interazioni correlate vengono raggruppate tramite contextId. Quando un task raggiunge uno stato terminale, una richiesta di modifica avvia un nuovo task anziché riaprire quello precedente. Ciclo di vita di un task.

Questa distinzione conta quando chi acquista cambia i requisiti dopo la consegna. La lista originale deve restare identificabile e la sua revisione va trattata come un nuovo lavoro, così chi la usa nelle fasi successive può riconoscere il risultato che ha approvato.

Trasporti: come viaggia lo stesso contratto di comunicazione

Un trasporto, o binding del protocollo, definisce come le operazioni vengono trasmesse sulla connessione. La specifica definisce binding JSON-RPC, gRPC e HTTP+JSON/REST. Le interfacce dell'Agent Card indicano endpoint, binding e versione del protocollo. Specifica A2A.

Polling, streaming e notifiche push riguardano invece il modo in cui arrivano gli aggiornamenti dei task. È una scelta distinta da quella del binding. Per una dashboard degli acquisti può bastare il polling; per un'esperienza interattiva possono essere importanti gli aggiornamenti incrementali. Prima di progettare l'interfaccia attorno a queste funzionalità, occorre verificare quali supporta l'endpoint effettivamente utilizzato.

Cosa cambia con A2A v1.0?

Le integrazioni esistenti richiedono una verifica di compatibilità: cambiare la stringa della versione non basta. La pagina ufficiale dedicata alle novità descrive i seguenti cambiamenti nel passaggio dalla v0.3.0 alla v1.0:

• Una definizione condivisa: a2a.proto diventa la definizione di riferimento del protocollo, accompagnata da specifiche formali per i binding.
• Nuove strutture dei dati scambiati: una Part unificata sostituisce i tipi di contenuto separati; i nomi dei membri sostituiscono i discriminatori kind e i valori delle enumerazioni usano SCREAMING_SNAKE_CASE.
• Agent Card riorganizzate: supportedInterfaces raggruppa i dettagli di connessione, con la versione del protocollo dichiarata per ciascuna interfaccia.
• Operazioni aggiornate: message/send diventa SendMessage; ListTasks introduce elenchi filtrabili con paginazione a cursore.
• Cambiamenti per l'uso aziendale: i campi relativi ai tenant, le regole di verifica delle firme delle Agent Card e i flussi OAuth aggiornati incidono sulla progettazione dell'integrazione.

Questi cambiamenti sono stati verificati sulla pagina delle novità della v1.0 del progetto il 12 ottobre 2026.

Per un connettore esistente, vanno esaminati insieme le richieste serializzate, il parsing delle risposte, l'individuazione delle schede e le operazioni utilizzate. Il solo fatto che la connessione funzioni non dimostra che ogni interazione continui a comportarsi correttamente.

Quali framework e piattaforme supportano A2A?

Esistono implementazioni documentate, ma le versioni e le funzionalità supportate variano. La scelta deve partire dal comportamento richiesto dal proprio flusso di lavoro. Il supporto e i limiti descritti di seguito sono stati verificati nella documentazione pubblica dei rispettivi produttori il 12 ottobre 2026; non sono state eseguite prove dei prodotti con accesso autenticato.

Google Agent Development Kit

Google Agent Development Kit (ADK), un framework per costruire agenti, documenta to_a2a per esporre un agente e generarne l'Agent Card. La sua integrazione A2A in Python è contrassegnata come Experimental. La documentazione indica il supporto per a2a-sdk 0.3.x e 1.x.x e indirizza le nuove integrazioni verso la 1.x.x. Guida ADK all'esposizione di un agente.

ADK documenta anche RemoteA2aAgent per utilizzare un agente remoto. Chi sviluppa con ADK dispone quindi di punti di integrazione documentati su entrambi i lati della delega. Lo stato sperimentale va considerato nella decisione di messa in produzione, anche quando il wrapper risulta comodo. Guida ADK all'utilizzo di un agente remoto.

LangGraph tramite LangSmith Agent Server

LangSmith Agent Server, il livello di servizio documentato per i deployment di LangGraph, espone un endpoint A2A su /a2a/{assistant_id}. La documentazione specifica il binding JSON-RPC della v1.0 e l'accettazione dei nomi dei metodi della v0.3. Il grafo deve avere un campo messages nel proprio stato. Documentazione A2A di LangSmith.

La stessa pagina elenca alcuni limiti: gRPC e HTTP+JSON non sono implementati; inoltre, SubscribeToTask e la configurazione delle notifiche push non sono ancora supportati. È possibile trasmettere un messaggio in streaming, ma questo non implica che siano disponibili tutte le operazioni di sottoscrizione o notifica. È un motivo concreto per verificare la copertura delle operazioni prima di scegliere come gestire le attività in background.

CrewAI e CrewAI AMP

CrewAI, un framework per coordinare agenti, documenta A2AClientConfig per delegare attività a distanza e A2AServerConfig per esporre agenti. Un agente può essere configurato per entrambi i ruoli. Documentazione CrewAI sulla delega.

CrewAI AMP, la piattaforma di deployment di CrewAI, contrassegna gli agenti server A2A come early release e indica le versioni 0.2 e 0.3 del protocollo. Descrive inoltre uno storage distribuito persistente al posto dello stato in memoria dell'implementazione open source. Il supporto A2A di CrewAI non basta quindi a presumere che un endpoint AMP supporti la v1.0. A2A su AMP.

Microsoft Foundry Agent Service

Microsoft Foundry Agent Service, una piattaforma gestita per agenti, documenta un tipo di strumento a2a in disponibilità generale per il protocollo 1.0. Il precedente tipo di strumento a2a_preview supporta la versione 0.3 e rimane in anteprima. Microsoft consiglia il tipo in disponibilità generale per le nuove integrazioni. Documentazione A2A di Foundry.

La pagina precisa anche che gli agenti Foundry di destinazione supportano solo testo e non supportano risposte in streaming. Un flusso di lavoro che richiede un risultato multimediale trasmesso in streaming deve tenere conto di questo limite. I tipi di contenuto previsti da un protocollo non garantiscono che ogni piattaforma di hosting li implementi.

Per scegliere il framework nel suo complesso, è disponibile il confronto tra framework per agenti AI. Queste note di integrazione rispondono a una domanda più circoscritta: quale interfaccia A2A documenta il sistema che espone il servizio?

Cosa cambia per chi sviluppa, gestisce e acquista

Il vantaggio è un'interfaccia di integrazione più riutilizzabile, a patto che valga la pena gestire il servizio aggiuntivo. Le conseguenze cambiano a seconda di chi prende la decisione.

Chi sviluppa: prima di aggiungere un trasporto, occorre definire cosa delegare. «Produci una rosa di candidati con fonti e motivazioni» definisce il perimetro di un servizio. «Esegui questa ricerca nel database» definisce quello di uno strumento. La distinzione va mantenuta anche se entrambi, alla fine, attivano chiamate a un modello.

Chi gestisce il sistema: il task deve avere un responsabile anche dopo il passaggio di consegne. Nell'esempio degli acquisti, qualcuno deve decidere cosa succede se l'agente di ricerca chiede altre informazioni, smette di rispondere o restituisce una lista che non supera i criteri di accettazione. Un formato di messaggio condiviso non risolve queste responsabilità.

Chi acquista e chi fonda un'azienda: bisogna chiedere quali versioni del protocollo, binding, operazioni e tipi di contenuto sono supportati, e qual è lo stato di rilascio della soluzione. Questi dettagli vanno confrontati con i requisiti del proprio flusso di lavoro. Una dichiarazione di compatibilità priva di tali informazioni non basta per impegnarsi in un'integrazione.

Come stimare il budget di un'implementazione A2A

A2A non ha un'unica configurazione di distribuzione da cui ricavare una spesa mensile. Un servizio specializzato ospitato da terzi e un servizio gestito in proprio hanno voci di costo differenti; la documentazione del protocollo non stabilisce un prezzo universale della piattaforma.

Per pianificare il budget, si può usare questa equazione riferendo tutte le voci allo stesso periodo:

Beneficio netto dell'integrazione = costi dei connettori evitati meno costi di migrazione, costi infrastrutturali aggiuntivi e costi operativi ricorrenti.

Tra le voci operative vanno considerati l'uso dei modelli, l'hosting, lo storage dei task, il monitoraggio e la responsabilità della gestione degli incidenti. Ogni termine va calcolato con i propri costi. A2A si giustifica quando elimina abbastanza lavoro ripetitivo di integrazione da compensare la nuova interfaccia di servizio da mantenere.

Quali promesse su A2A sono esagerate?

Un protocollo comune non rende affidabili agenti sconosciuti e non garantisce automaticamente l'affidabilità del lavoro distribuito. La standardizzazione è utile, ma le decisioni applicative restano a chi costruisce il sistema.

Un'Agent Card dichiara cosa offre un servizio. Spetta comunque a chi lo usa decidere se fidarsi del gestore e accettarne i risultati. Le indicazioni A2A per l'uso aziendale affidano all'implementazione l'applicazione dei controlli di autenticazione e autorizzazione, comprese le autorizzazioni sulle azioni sottostanti. Indicazioni per le implementazioni aziendali.

Nel processo di ricerca dei fornitori, autorizzare la ricerca non deve comportare implicitamente il potere di acquistare. Restituire una raccomandazione e inoltrare un ordine devono richiedere permessi distinti nell'applicazione.

L'artefatto restituito, lo stato del task e la registrazione dell'accettazione nell'applicazione vanno gestiti come elementi distinti. Prima di consentire a un flusso delegato di creare un ordine di acquisto, occorre stabilire come l'applicazione riconoscerà le azioni aziendali ripetute e gestirà un esito incerto.

Un altro eccesso è introdurre A2A in ogni chiamata interna a un sottoagente. Il progetto esclude esplicitamente dal proprio ambito la definizione delle chiamate interne di un agente ai suoi sottoagenti o strumenti. Se i componenti condividono lo stesso contratto applicativo, le funzioni di composizione native del framework potrebbero già bastare. Ambito di A2A.

Serve A2A, MCP o servono entrambi?

Il punto di partenza è il confine tra sistemi già presente nel prodotto.

Conviene scegliere MCP quando un agente deve accedere a sistemi aziendali, file o API tramite interfacce riutilizzabili per gli strumenti. Per esporre una propria funzionalità, si può seguire la guida alla creazione di un server MCP in Python. Quando il problema diventa governare l'accesso attraverso questi collegamenti, la guida ai gateway MCP affronta quel livello.

Conviene scegliere A2A quando un altro agente, gestito in modo indipendente, è responsabile di un incarico sostanziale e serve un metodo comune per individuarne l'interfaccia, scambiare istruzioni e seguire il lavoro che ne deriva. È il momento di adottarlo se questa esigenza di integrazione esiste già e gli endpoint documentano funzionalità compatibili.

Conviene scegliere entrambi quando il proprio agente delega a uno specialista che ha bisogno anche di strumenti e dati. È il caso dell'esempio sui fornitori: A2A per delegare la ricerca, MCP per accedere ai cataloghi all'interno di un agente.

Meglio rimandare A2A se lo specialista esterno è ancora solo un'ipotesi. Un agente che funziona adeguatamente con gli strumenti attuali non deve cambiare per il solo fatto che esista un nuovo protocollo tra agenti. Nessuno dei due standard, inoltre, è necessario per ogni chiamata a una funzione interna. Va adottato il contratto di connessione che risolve un problema di integrazione reale.

Da dove iniziare lo sviluppo

Prima di migrare il resto dello stack, occorre scrivere il contratto di delega per un risultato aziendale ben circoscritto. Per un assistente agli acquisti, si può partire da una rosa di fornitori, lasciando l'esecuzione degli acquisti fuori dall'ambito iniziale.

1. 1

   Definire i criteri di accettazione dell'artefatto

   Specificare quali informazioni deve contenere la lista, quali condizioni la rendono inaccettabile e quale applicazione registra il risultato accettato. Affidare all'agente remoto una responsabilità delimitata.

2. 2

   Verificare la compatibilità delle interfacce documentate

   Annotare le versioni del protocollo di client e server, il binding, i requisiti di autenticazione e le operazioni necessarie. Verificare se il flusso di lavoro richiede streaming o invio tramite push e se entrambi gli endpoint li supportano.

3. 3

   Progettare la gestione degli esiti non conclusivi

   Decidere chi gestisce richieste di chiarimento, timeout, rifiuti e risposte incerte dopo un nuovo tentativo. Definire cosa vede l'utente mentre il lavoro è in sospeso e come un artefatto rivisto sostituisce quello precedente.

Questo contratto offre una base concreta per introdurre A2A. Se, nello scriverlo, emerge che il presunto specialista si limita a recuperare un record, conviene implementare prima il collegamento allo strumento.

Le domande da porsi prima di adottare A2A

Si può usare A2A senza MCP?

Sì. A2A non prescrive come l'agente remoto debba accedere ai propri strumenti e dati. MCP è utile quando servono anche collegamenti standardizzati agli strumenti. Come funzionano insieme.

I due agenti devono usare lo stesso framework?

No. L'interoperabilità tra framework è uno degli obiettivi centrali di A2A. Devono essere compatibili l'interfaccia esposta e le funzionalità richieste dall'interazione, non l'implementazione interna degli agenti. Panoramica di A2A.

Per ricevere guide pratiche alla costruzione di sistemi di agenti utili, iscriviti alla newsletter.