Glue code, ovunque.
Se provi a far parlare due agenti AI costruiti con framework diversi, la prima cosa che scrivi non è logica di business. È colla.
Adapter, wrapper, mapping di payload. Stati che non combaciano, formati che non avevi previsto. Ogni integrazione diventa un pezzo di infrastruttura in più da mantenere, e ogni pezzo è anche un nuovo punto fragile.
Ho scritto glue code più volte di quanto vorrei ammettere. Un agente che raccoglie dati, un altro che li elabora, un terzo che fa altro. Ognuno ha il suo modello di stato e aspettative su cosa riceve. Il codice che li tiene insieme non fa altro che tradurre. Ed è sempre quello che si rompe per primo.
È la dinamica normale di un ecosistema in piena evoluzione: tutti costruiscono agenti, ognuno parla il proprio dialetto. CrewAI, LangGraph, Autogen. E nel frattempo, dentro le aziende, i sistemi esistenti fanno quello che hanno sempre fatto: API, webhook, queue, bus di eventi.
Funziona? Sì. Scala quando gli agenti diventano dieci, venti, cinquanta? Mmm…
Mentre tutti correvano ad aggiungere "agentic" al readme della repo Github, è uscito Agent2Agent (A2A) Protocol. Un tentativo di mettere ordine su come gli agenti si parlano.
L'idea di base
A2A vuole diventare una lingua franca. Non vuole essere un orchestratore, non vuole sostituire i framework esistenti. Vuole solo standardizzare il layer di comunicazione tra agenti diversi.
Due agenti che collaborano non dovrebbero dover conoscere la logica interna l'uno dell'altro. Dovrebbero solo condividere un modo comune di comunicare.
È un po' come MCP, ma su un piano diverso. MCP standardizza come un agente parla con i suoi strumenti. A2A prova a fare lo stesso per come gli agenti parlano tra loro. Stesso principio, problema diverso. Partendo dal fatto che sono sistemi opachi, con logiche proprietarie che non puoi standardizzare dall'interno.
Quello che puoi standardizzare è il perimetro: come un agente si presenta, come riceve un lavoro, come dichiara il proprio stato, come chiede input, come restituisce un risultato.
A2A non ti dà agenti migliori. Ti risparmia il costo di integrarli tra loro.
Cosa c'è sotto
La prima scelta interessante è l' Agent Card: una dichiarazione strutturata di capacità. Non è un concetto nuovo, il mondo delle API vive di discovery document da anni. La differenza è che qui il consumatore non è uno sviluppatore, ma un altro agente.
Il punto che cambia davvero la prospettiva sono i task stateful. In un'API classica mandi una richiesta e ricevi una risposta. Con A2A il lavoro ha un ciclo di vita: può essere in corso, può richiedere input intermedi, può produrre risultati parziali. Riflette molto meglio la realtà dei flussi agentici, che raramente sono call & response pulite.
L'interazione non viene trattata come una chiamata RPC ma come un processo. Message e Artifact separano conversazione e risultato. Le Extensions permettono di estendere il protocollo senza appesantire il core.
Fin qui funziona. Anzi, forse è troppo pulito per essere vero.
Il lato meno comodo
Standardizzare significa anche aumentare la superficie d'attacco.
Le Agent Card sono input esterni. Le descrizioni delle skill sono testo. E in un contesto LLM-driven, il testo non è mai solo testo: prompt injection, SSRF, recupero automatico di URL sono rischi concreti, non teorici.
Il protocollo spinge verso OAuth2, TLS, mTLS, firme JWS. Ma la sicurezza è sempre nell'implementazione, non nella specifica. Quando entrano in gioco webhook e flussi asincroni, servono idempotenza, autenticazione robusta, gestione delle retry, cose che la documentazione cita ma che tocca a te costruire bene.
Quanto è maturo?
Ci sono segnali incoraggianti: altri protocolli convergono ( ACP), il mercato sente il bisogno di uno standard comune. Ma siamo ancora in fase di consolidamento. Versioni in movimento, SDK che evolvono rapidamente, nessuna metrica pubblica seria su adozioni enterprise.
Per il momento stiamo a guardare.