Agent2Agent (A2A), il protocollo aperto creato da Google per la comunicazione tra agenti AI, entra nella Agentic AI Foundation come hosted project. Google aveva presentato A2A il 9 aprile 2025 insieme a più di 50 partner tecnologici e il 23 giugno dello stesso anno lo aveva trasferito alla Linux Foundation, portandone lo sviluppo sotto una governance aperta e indipendente da un singolo vendor. L’ingresso nella AAIF colloca ora A2A accanto a MCP, che standardizza il collegamento degli agenti a strumenti e fonti dati, AGENTS.md, che fornisce istruzioni operative ai coding agent, goose, runtime open source per l’esecuzione degli agenti, e agentgateway, componente per routing, policy e osservabilità del traffico agentico.
A2A definisce come agenti realizzati con framework differenti e distribuiti da vendor diversi possano scoprirsi, dichiarare le proprie capacità, delegarsi attività e scambiarsi risultati attraverso un’interfaccia comune. Nell’aprile 2026 l’ecosistema aveva superato 150 organizzazioni aderenti, tra cui AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP e ServiceNow, mentre il protocollo aveva raggiunto implementazioni in produzione nella supply chain, nei servizi finanziari, nelle assicurazioni, nelle piattaforme mobili e nelle IT operations.
Un’interfaccia comune tra agenti costruiti su stack diversi
Nei sistemi multi-agent la complessità aumenta quando agenti costruiti con framework, runtime e infrastrutture differenti devono collaborare. In assenza di un protocollo comune, ogni nuova relazione tra due sistemi richiede un’integrazione specifica che deve gestire discovery, autenticazione, scambio dei messaggi, stato delle attività, errori e risultati. Con l’aumento del numero di agenti e vendor coinvolti crescono quindi anche il codice di integrazione, i test, i controlli di sicurezza e le attività di manutenzione.
A2A standardizza questa comunicazione mantenendo indipendente l’implementazione interna degli agenti. I sistemi che partecipano a un workflow possono utilizzare modelli differenti, essere eseguiti su runtime diversi e appartenere a framework concorrenti, purché espongano le interfacce previste dal protocollo. L’agente che delega un’attività non deve conoscere il modello utilizzato dal sistema remoto, gli strumenti ai quali accede o la logica con cui decide come eseguire il lavoro.
Il discovery ruota attorno all’Agent Card, un documento strutturato attraverso il quale un agente pubblica le informazioni necessarie per essere individuato e contattato, comprese capacità, skill, endpoint, interfacce supportate e requisiti di sicurezza. Un altro agente può leggere queste informazioni, verificare se il sistema remoto dispone delle capacità necessarie e affidargli un’attività senza una configurazione costruita specificamente per quella coppia di sistemi.
Un esempio concreto di Agent Card
{
"name": "Order Management Agent",
"description": "Gestisce stato, modifica e cancellazione degli ordini",
"supportedInterfaces": [
{
"url": "https://example.com/a2a",
"protocolBinding": "JSONRPC",
"protocolVersion": "1.0"
}
],
"capabilities": {
"streaming": true
},
"skills": [
{
"id": "check-order-status",
"name": "Controllo stato ordine",
"description": "Restituisce lo stato corrente di un ordine"
},
{
"id": "cancel-order",
"name": "Cancellazione ordine",
"description": "Gestisce la richiesta di cancellazione di un ordine"
}
]
}In questo esempio, name e description identificano l’agente e ne sintetizzano la funzione; supportedInterfaces specifica dove può essere raggiunto, quale binding utilizza e quale versione di A2A supporta. capabilities dichiara proprietà generali del servizio, come la possibilità di restituire aggiornamenti in streaming, mentre skills elenca le capacità operative che altri agenti possono individuare prima di delegare un Task.
La comunicazione utilizza il concetto di Task, che rappresenta un’unità di lavoro dotata di un proprio ciclo di vita e permette di gestire anche attività lunghe o articolate. L’agente remoto può aggiornare progressivamente lo stato dell’esecuzione, richiedere ulteriori informazioni e produrre risultati intermedi prima del completamento. Gli output vengono rappresentati come Artifact, oggetti che possono contenere testo, dati strutturati, file o altri risultati destinati ai passaggi successivi del workflow.
Questo modello preserva l’autonomia del sistema remoto: il chiamante delega un compito e ne segue l’esecuzione attraverso un contratto condiviso, mentre l’agente che riceve il Task mantiene il controllo sugli strumenti, sul modello e sulla logica utilizzati per produrre il risultato.
A2A 1.0 introduce stabilità, multi-protocollo e identità verificabili
La pubblicazione di A2A 1.0 nel marzo 2026 ha segnato il passaggio alla prima specifica stabile del protocollo e ha consolidato le funzioni necessarie per utilizzarlo in ambienti enterprise distribuiti, dove compatibilità tra implementazioni, sicurezza e gestione di infrastrutture condivise diventano requisiti strutturali.
I binding multi-protocollo permettono allo stesso modello A2A di funzionare attraverso HTTP+JSON, JSON-RPC e gRPC, consentendo alle organizzazioni di adottare lo standard senza uniformare l’intera infrastruttura a un unico meccanismo di trasporto. In ambienti nei quali coesistono servizi legacy, applicazioni cloud-native, microservizi e piattaforme SaaS, questa possibilità riduce il numero di adattamenti necessari per esporre gli agenti attraverso un’interfaccia comune.
La versione 1.0 introduce inoltre la negoziazione delle versioni. Un’Agent Card può dichiarare per ogni interfaccia endpoint, binding e versione A2A supportata, permettendo allo stesso agente di mantenere contemporaneamente compatibilità con generazioni differenti del protocollo. Client e server possono così individuare una versione comune senza richiedere aggiornamenti simultanei di tutti i componenti coinvolti.
Il supporto alla multi-tenancy permette allo stesso servizio A2A di operare per tenant differenti mantenendo separati identità, richieste e contesti operativi. La funzione è particolarmente rilevante per piattaforme SaaS e infrastrutture condivise, nelle quali uno stesso endpoint deve servire organizzazioni differenti senza perdere isolamento e tracciabilità.
Le Agent Card firmate aggiungono invece un meccanismo crittografico per verificare origine e integrità delle informazioni pubblicate dall’agente. Quando discovery e delega attraversano confini organizzativi, il client può quindi controllare che identità, capacità ed endpoint dichiarati provengano dalla fonte prevista e non siano stati modificati.
A2A 1.0 rafforza anche la definizione di tipi, errori e risorse e formalizza i meccanismi necessari per far evolvere il protocollo mantenendo compatibilità tra implementazioni sviluppate e aggiornate in modo indipendente.
IBM fa convergere Agent Communication Protocol in A2A
La frammentazione degli standard di comunicazione agent-to-agent si è ridotta nell’agosto 2025, quando l’Agent Communication Protocol di IBM Research è confluito in A2A. ACP affrontava la stessa esigenza di interoperabilità, permettendo ad agenti costruiti con framework, linguaggi e runtime differenti di comunicare attraverso un’interfaccia condivisa.
La convergenza ha concentrato su A2A contributi, implementazioni ed esperienza maturati nei due progetti e ha evitato che protocolli progettati per superare le integrazioni proprietarie introducessero a loro volta due ecosistemi incompatibili. La scelta di IBM ha contribuito a rafforzare A2A come punto di convergenza per il livello di comunicazione tra agenti.
HarmonyOS utilizza A2A tra assistente e applicazioni
A2A è già utilizzato anche a livello di sistema operativo. Huawei ha integrato il protocollo nell’Agent Framework Kit di HarmonyOS, permettendo agli agenti delle applicazioni di comunicare con l’assistente e con gli altri componenti agentici della piattaforma attraverso un modello condiviso.
L’implementazione comprende Agent Card, messaggi, Task, Artifact e gestione dello stato dell’esecuzione, consentendo alle applicazioni di esporre un server A2A capace di ricevere richieste, attivare la logica dell’agente e restituire progressivamente risultati. La struttura mantiene quindi nel dispositivo gli stessi concetti utilizzati nelle implementazioni backend e cloud del protocollo.
Nell’integrazione con Celia, l’assistente AI di Huawei, A2A consente di delegare a un agente applicativo attività di lunga durata, interagire con l’interfaccia dell’applicazione e richiedere raccomandazioni contestuali. L’assistente di sistema può individuare le capacità esposte dall’app e affidarle un Task senza richiedere un meccanismo proprietario differente per ciascuna applicazione.
WeChat figura tra le prime grandi applicazioni utilizzate in questo modello insieme agli assistenti di Huawei e di altri produttori Android. Gli scenari comprendono l’avvio tramite assistente AI di messaggi, chiamate vocali e videochiamate, con un flusso che mantiene le autorizzazioni necessarie tra il sistema operativo e l’applicazione.
L’impiego su HarmonyOS porta quindi A2A oltre i tradizionali servizi backend: il sistema operativo può assumere un ruolo di orchestrazione, mentre le applicazioni espongono capacità attraverso agenti che mantengono autonomia sulla propria logica e sui propri controlli di accesso.
Google Cloud, Microsoft e AWS integrano A2A nei rispettivi runtime
I principali hyperscaler hanno integrato A2A nelle piattaforme utilizzate per sviluppare e distribuire agenti, rendendo possibile mantenere la stessa interfaccia di comunicazione anche quando i sistemi vengono eseguiti su infrastrutture cloud differenti.
Su Google Cloud, A2A può essere utilizzato con Cloud Run, Agent Development Kit e gli altri servizi dell’ecosistema Vertex AI. Gli agenti possono esporre una Agent Card, ricevere Task e utilizzare sistemi persistenti per conservare lo stato delle attività. Le funzioni A2A specifiche di Cloud Run risultano ancora classificate come Preview, una condizione distinta dalla stabilità raggiunta dalla specifica A2A 1.0.
Microsoft Foundry supporta endpoint A2A attraverso i quali un agente può pubblicare la propria Agent Card ed essere individuato da sistemi esterni. La piattaforma supporta A2A 0.3 e 1.0 e permette anche agli agenti gestiti nell’ambiente Microsoft di collegarsi a endpoint A2A remoti, con autenticazione basata su Microsoft Entra ID.
Su Amazon Bedrock AgentCore Runtime, AWS permette di eseguire server A2A mantenendo visibili le primitive standard del protocollo attraverso un proxy trasparente. Il runtime aggiunge isolamento delle sessioni, autenticazione, scalabilità e gestione dell’ambiente di esecuzione, mentre discovery e scambio dei messaggi continuano a seguire il modello A2A.
Il supporto nei tre principali cloud pubblici consente quindi a un agente ospitato su una piattaforma di comunicare con sistemi residenti altrove mantenendo discovery, delega e scambio dei risultati su un protocollo comune.
A2A e AP2 estendono il modello al commercio agentico
La comunicazione tra agenti entra anche nei workflow di agentic commerce, nei quali un sistema può cercare un prodotto, interagire con un merchant, confrontare offerte e arrivare fino alla fase di pagamento.
Google ha sviluppato Agent Payments Protocol (AP2) insieme a più di 60 organizzazioni del settore tecnologico e dei pagamenti per aggiungere al commercio agentico un livello dedicato all’autorizzazione e alla verificabilità delle transazioni.
I ruoli dei protocolli rimangono distinti: A2A gestisce la comunicazione e il coordinamento tra gli agenti, mentre AP2 rappresenta il mandato economico dell’utente e consente di verificare che l’operazione eseguita dall’agente corrisponda all’autorizzazione ricevuta.
La collaborazione tra Google Cloud e PayPal applica questa separazione a un workflow nel quale l’agente PayPal può comunicare con quello del merchant attraverso A2A, mentre AP2 gestisce i controlli necessari per autorizzare e verificare la transazione. L’interoperabilità tra agenti diventa così uno dei livelli di un processo più ampio nel quale identità, intenzione dell’utente e pagamento rimangono affidati a protocolli specializzati.
A2A e MCP coprono due livelli complementari
MCP e A2A sono protocolli complementari e intervengono in punti differenti dello stack agentico.
MCP, Model Context Protocol, standardizza il collegamento tra un agente e strumenti, applicazioni e fonti dati. Un agente può utilizzarlo per interrogare un database, accedere a documenti, richiamare una API o invocare una funzione esposta da un server compatibile.
A2A gestisce invece la relazione tra agenti autonomi. Un agente può individuare un secondo sistema specializzato, affidargli un Task e riceverne il risultato senza conoscere il modello, gli strumenti o il processo interno utilizzato per svolgere il lavoro.
Le due funzioni possono quindi convivere nello stesso workflow. Un agente dedicato alla gestione degli ordini può ricevere attraverso A2A una richiesta proveniente da un agente commerciale e utilizzare MCP internamente per interrogare ERP, database e servizi logistici. MCP collega ciascun agente alle risorse necessarie per operare; A2A coordina il lavoro tra agenti indipendenti.
Dove si colloca A2A nello stack della Agentic AI Foundation
Con l’ingresso di Agent2Agent, la Agentic AI Foundation riunisce progetti che coprono livelli differenti dell’infrastruttura agentica aperta e che possono essere adottati separatamente o combinati all’interno della stessa architettura.
AGENTS.md standardizza un file Markdown attraverso il quale un progetto può fornire ai coding agent istruzioni operative, convenzioni, comandi e indicazioni sull’ambiente nel quale devono lavorare. goose è un runtime open source nel quale un agente può pianificare, utilizzare strumenti ed eseguire attività. MCP standardizza il collegamento dell’agente con applicazioni, servizi e fonti dati.
agentgateway opera invece sul traffico generato dai sistemi agentici, applicando routing, policy e osservabilità tra agenti, modelli, strumenti e infrastruttura. A2A aggiunge il livello agent-to-agent, definendo discovery, comunicazione, delega dei Task e scambio dei risultati quando i sistemi coinvolti appartengono a framework, vendor o organizzazioni differenti.
La separazione tra questi livelli consente di comporre architetture nelle quali un agente può ricevere istruzioni attraverso AGENTS.md, essere eseguito in un runtime come goose, raggiungere strumenti e dati attraverso MCP, attraversare agentgateway per l’applicazione delle policy e collaborare con altri agenti utilizzando A2A. Ogni componente mantiene una funzione distinta e non richiede l’adozione di un unico framework agentico.
Una governance condivisa tra vendor concorrenti
L’ecosistema A2A comprende oltre 150 organizzazioni, comprese aziende che competono direttamente nei mercati del cloud, del software enterprise e delle piattaforme AI. Per un protocollo destinato a collegare sistemi sviluppati da questi stessi vendor, la governance incide direttamente su compatibilità, sicurezza ed evoluzione dello standard, perché ogni modifica può coinvolgere implementazioni appartenenti a organizzazioni differenti.
Il trasferimento da Google alla Linux Foundation nel giugno 2025 aveva già separato A2A dal controllo diretto della società che lo aveva creato. L’ingresso nella Agentic AI Foundation porta ora il protocollo nello stesso ambiente di governance dei progetti che coprono gli altri livelli dell’infrastruttura agentica aperta.
Manik Surtani, CTO della Agentic AI Foundation, definisce A2A “un passo importante verso un futuro aperto e interoperabile per gli agenti AI” e collega l’ingresso nella fondazione alla creazione di “una sede neutrale nella quale la comunità possa collaborare agli standard che consentiranno agli agenti di vendor, framework e organizzazioni differenti di lavorare insieme”.
Rao Surapaneni, Vice President e General Manager, Business Application Platforms di Google Cloud, collega l’interoperabilità alla messa in produzione dei sistemi multi-agent: “Con il trasferimento in produzione dei sistemi agentici multipiattaforma, l’interoperabilità sta diventando essenziale. A2A permette agli agenti di scoprirsi, delegare e collaborare fra framework e piattaforme isolate senza integrazioni personalizzate”.
Il percorso iniziato con il lancio di Google nell’aprile 2025 segue così una sequenza definita: creazione del protocollo, trasferimento alla Linux Foundation per una governance vendor-neutral e ingresso nella Agentic AI Foundation come progetto dedicato all’interoperabilità agent-to-agent. La versione 1.0, la convergenza con ACP e le implementazioni su Google Cloud, Microsoft, AWS e HarmonyOS mostrano che A2A sta passando dalla definizione dello standard alla costruzione di un livello operativo comune per sistemi agentici distribuiti tra piattaforme diverse.
