A2A: Il Protocollo Google per Far Parlare gli Agenti

Hai un agente che scrive codice. Un altro che gestisce il deploy. Un terzo che monitora la produzione. Tutti funzionano — ma ognuno per conto suo.

Se l'agente di deploy ha bisogno di sapere cosa ha cambiato l'agente di coding, oggi la soluzione è: un'integrazione custom, un webhook fatto a mano, o — più realisticamente — tu che copi-incolli il contesto da una finestra all'altra.

A2A (Agent-to-Agent) è il tentativo di Google di risolvere questo problema con un protocollo aperto. Annunciato ad aprile 2025, donato alla Linux Foundation a giugno, con oltre 200 partner tra cui Microsoft, AWS, SAP e Salesforce. L'obiettivo: permettere a qualsiasi agente AI di scoprire, comunicare e collaborare con qualsiasi altro agente, indipendentemente dal framework o dal vendor.

Se MCP è l'USB-C che connette gli agenti al mondo esterno (database, API, file), A2A è il protocollo di rete che connette gli agenti tra loro.

Il Problema: M × N di Nuovo

Abbiamo già visto il problema M × N parlando di MCP: senza uno standard, M agenti che devono accedere a N tool richiedono M × N integrazioni custom. MCP lo ha risolto per i tool.

Ma c'è un secondo livello dello stesso problema. In un sistema multi-agente, gli agenti stessi devono collaborare. Un agente costruito con LangChain non sa parlare con uno costruito con Google ADK, che non sa parlare con uno costruito con CrewAI.

Il risultato:

Ogni coppia di agenti richiede un'integrazione dedicata
Con 5 agenti servono 10 connessioni bidirezionali, con 10 ne servono 45, con 50 ne servono 1.225
Vendor lock-in: gli agenti funzionano solo dentro il proprio ecosistema
Nessun meccanismo di discovery: come fa un agente a trovare un altro agente che sa fare quello che gli serve?

A2A propone uno standard che risolve tutti questi punti con un protocollo basato su tecnologie web esistenti: HTTP, JSON-RPC 2.0, Server-Sent Events, gRPC.

Come Funziona: I Concetti Chiave

Agent Card: Il Biglietto da Visita

Ogni agente A2A pubblica un documento JSON chiamato Agent Card a un URL standard:

https://agente-esempio.com/.well-known/agent-card.json

È il biglietto da visita dell'agente — dice chi è, cosa sa fare e come comunicarci:

name, description — identità dell'agente
url — endpoint del servizio
capabilities — supporta streaming? Push notification?
skills — array delle competenze (cosa sa fare concretamente)
security — come autenticarsi

Quando un agente deve trovare un collaboratore, recupera le Agent Card disponibili, legge le skills, e decide se quell'agente è quello giusto per il task. È un meccanismo di discovery automatico — l'equivalente di un DNS per agenti AI.

Dalla versione 0.3, le Agent Card possono essere firmate crittograficamente per prevenire spoofing — un dettaglio non banale in un mondo dove gli agenti agiscono con autonomia.

Task: L'Unità di Lavoro

Il Task è il cuore del protocollo. Quando un agente chiede a un altro di fare qualcosa, crea un Task con un ciclo di vita ben definito:

SUBMITTED → WORKING → COMPLETED
                |
                ↓
         INPUT_REQUIRED → WORKING (il client fornisce info aggiuntive)
                |
                ↓
         AUTH_REQUIRED → WORKING (credenziali fornite)

Gli stati terminali sono: COMPLETED, FAILED, CANCELED, REJECTED.

Il dettaglio più interessante è INPUT_REQUIRED: se l'agente remoto ha bisogno di informazioni aggiuntive per completare il task, può "mettere in pausa" e chiedere. È una conversazione, non una chiamata a funzione one-shot. Questo è fondamentalmente diverso da come funzionano i tool in MCP.

Messages, Parts e Artifacts

I Messages sono l'unità di comunicazione — contengono Parts (testo, file binari, URL, dati JSON strutturati). Il ruolo è "user" (dal client) o "agent" (dal server).

Gli Artifacts sono gli output concreti del task — il deliverable effettivo. Un agente di coding potrebbe restituire un Artifact con il codice generato, un agente di analisi un report in PDF.

La distinzione Messages/Artifacts è importante: i messaggi sono la conversazione, gli artifacts sono il risultato.

L'Architettura: Chi Parla con Chi

I Tre Attori

User — l'utente finale che inizia la richiesta
A2A Client — l'agente che agisce per conto dell'utente, avvia la comunicazione
A2A Server — l'agente remoto che espone un endpoint A2A-compliant

Il punto chiave: gli agenti A2A sono opachi. Il client non sa (e non deve sapere) come funziona internamente il server. Non conosce il modello AI, la logica, la memoria. Vede solo l'Agent Card e i risultati. Questo protegge la proprietà intellettuale e migliora la sicurezza.

Il Flusso Tipico

Discovery — Il client recupera l'Agent Card del server
Skill Matching — Analizza le skills per capire se l'agente può aiutare
Invio Messaggio — Il client manda la richiesta (SendMessage)
Task Creato — Il server crea un Task (stato: SUBMITTED → WORKING)
Elaborazione — L'agente lavora, eventualmente chiede input aggiuntivi
Risultato — Il server produce Artifacts, il task va in COMPLETED
Ricezione — Il client riceve il risultato via polling, streaming SSE, o webhook

Tre Modi di Ricevere i Risultati

Polling: il client chiede periodicamente lo stato (GetTask)
Streaming SSE: connessione HTTP aperta, eventi in tempo reale — ideale per task che producono output incrementale
Push Notification (Webhook): il server notifica il client quando il task è completato — ideale per task che durano ore o giorni

A2A e MCP: Complementari, Non Competitivi

La documentazione ufficiale di A2A lo dice esplicitamente: "A2A loves MCP".

Aspetto	MCP	A2A
Connette	Agente ↔ Tool/Risorse	Agente ↔ Agente
Tipo di interazione	Chiamate a funzione stateless	Dialoghi multi-turn stateful
Target	Operazioni discrete con I/O definito	Collaborazione tra sistemi autonomi
Stato	Stateless	Stateful (Task con ciclo di vita)
Creato da	Anthropic	Google

La distinzione è chiara:

MCP risponde a: "Come fa un agente a usare un tool esterno?"
A2A risponde a: "Come fanno due agenti a collaborare su un task complesso?"

L'Analogia dell'Officina

La documentazione ufficiale usa un'analogia efficace:

Layer A2A: Il cliente parla con l'agente manager dell'officina. Il manager collabora con agenti meccanici specializzati. I meccanici collaborano con agenti fornitori di ricambi. Ogni scambio è una conversazione multi-turn.

Layer MCP: Il singolo agente meccanico usa scanner diagnostici, manuali di riparazione e il ponte sollevatore tramite MCP. Ogni uso è una chiamata a funzione specifica.

In un sistema reale, entrambi i protocolli coesistono: A2A per la comunicazione tra agenti, MCP per l'accesso ai tool di ciascun agente.

Chi Supporta A2A: 200+ Partner

A2A è partito ad aprile 2025 con 50 partner e a luglio ne aveva 200+. La lista include praticamente tutti:

Big Tech: Google, AWS, Microsoft, Oracle, IBM, Adobe, Cisco

Enterprise Software: SAP, Salesforce, ServiceNow, Workday, UiPath, JetBrains, Datadog

AI/ML: Cohere, LangChain, LlamaIndex, Weights & Biases, DataRobot

System Integrator: Accenture, Deloitte, McKinsey, KPMG, PwC, Capgemini, Cognizant

Telco: Deutsche Telekom, Telefónica, SoftBank

Il fatto che Microsoft supporti A2A è significativo — considerando che A2A è un progetto Google. Lo hanno integrato in Azure AI Foundry e Copilot Studio. Indica che il problema dell'interoperabilità multi-agente è abbastanza sentito da superare le rivalità tra vendor.

Il progetto è stato donato alla Linux Foundation il 23 giugno 2025, garantendo governance neutrale e open source (licenza Apache 2.0).

Lo Stato Attuale: Versioni e Maturità

Versione	Data	Novità principali
v0.1.0	Aprile 2025	Lancio al Cloud Next
v0.3.0	Luglio 2025	gRPC, Agent Card firmate, Python SDK
RC v1.0	In sviluppo	Release Candidate della specifica stabile

SDK disponibili: Python (pip install a2a-sdk), Go, JavaScript (npm install @a2a-js/sdk), Java, .NET/C#.

Il repository GitHub ha circa 22.000 star, 2.200 fork e 141 contributori.

Cosa è Cambiato nella v0.3

La versione 0.3 (luglio 2025) ha aggiunto i pezzi mancanti per l'uso enterprise:

gRPC come binding nativo — performance più alte per ambienti di produzione
Agent Card firmate — verifica crittografica dell'identità degli agenti
Breaking change: il path dell'Agent Card è cambiato da /.well-known/agent.json a /.well-known/agent-card.json

I Problemi (Perché Non È Ancora Ovunque)

A2A ha un design solido ma non è esente da critiche. Alcune sono tecniche, altre sono di ecosistema.

Sicurezza: Buona ma Non Abbastanza

Semgrep ha pubblicato un'analisi di sicurezza dettagliata che identifica diversi rischi:

Le Agent Card non sono obbligatoriamente firmate. Senza un registro centrale, lo spoofing è un attacco a basso costo
Stream hijacking: stream concorrenti senza terminazione obbligatoria. Un token compromesso potrebbe intercettare silenziosamente una conversazione
Prompt injection: un attaccante può identificare endpoint A2A e manipolare il comportamento degli agenti

Scalabilità: Il Punto-a-Punto Ha Limiti

Le connessioni HTTP dirette tra agenti creano complessità quadratica O(n²). Con pochi agenti funziona, con centinaia diventa insostenibile. HiveMQ ha analizzato questo problema: un singolo fallimento può causare effetti a cascata nell'intera rete di agenti.

Adozione: L'Ombra di MCP

Ecco il punto più delicato. Un'analisi di settembre 2025 ha evidenziato che:

A2A richiede comprensione di discovery, negoziazione capability e security card anche per task semplici — curva di apprendimento alta
L'approccio top-down (focus enterprise) ha alienato gli sviluppatori individuali
Quando la v0.3 è diventata usabile, MCP aveva già catturato il mindshare della community
Google stessa ha aggiunto compatibilità MCP ai propri servizi — un riconoscimento implicito

A2A non è tecnicamente inferiore a MCP. Risolve un problema diverso (agent-to-agent vs agent-to-tool). Ma MCP ha vinto la battaglia dell'adozione grassroots perché era più semplice da usare e immediatamente utile con Claude. A2A risolve un problema che molti sviluppatori non hanno ancora: orchestrare decine di agenti autonomi.

Quando Ti Serve A2A (e Quando No)

Ti Serve A2A se:

Stai costruendo un sistema multi-agente dove agenti di vendor/framework diversi devono collaborare
I tuoi agenti hanno task di lunga durata (ore, giorni) con necessità di human-in-the-loop
Lavori in un contesto enterprise dove l'interoperabilità cross-vendor è un requisito
Hai bisogno di discovery automatico — i tuoi agenti devono trovarsi a vicenda

Non Ti Serve A2A se:

Hai un singolo agente che usa tool esterni — MCP basta
I tuoi agenti sono tutti nello stesso framework — LangChain, CrewAI o Google ADK hanno già meccanismi interni
Stai facendo prototyping — la complessità di A2A non si giustifica in fase esplorativa
Il tuo caso d'uso è chiamate a funzione semplici — MCP è progettato per quello

La Sintesi

A2A e MCP non competono. Risolvono due problemi diversi a due livelli diversi dello stack. In un sistema maturo, probabilmente li userai entrambi: MCP per dare ai tuoi agenti accesso a tool e risorse, A2A per far collaborare i tuoi agenti tra loro e con agenti esterni.

Il protocollo è solido ma giovane. La v1.0 è in arrivo, la governance è nella Linux Foundation, i partner sono 200+. Se stai costruendo sistemi multi-agente oggi, vale la pena capirlo. Se stai usando un singolo agente per il coding quotidiano, puoi aspettare — ma tienilo d'occhio.

Il futuro del software non è un agente che fa tutto. È un team di agenti che collaborano. A2A è il protocollo che vuole rendere possibile quella collaborazione.