A un anno dalla nascita del protocollo Agent-to-Agent, l’ecosistema conta 150 organizzazioni aderenti, oltre 22.000 stelle GitHub e adozione in produzione su AWS, Microsoft, Google, Salesforce, SAP e ServiceNow.
La specifica v1.0 ha portato Signed Agent Cards, multi-tenancy e binding multi-protocollo. Combinato con MCP, oggi A2A definisce cinque pattern architetturali che permettono agli agenti aziendali di superare i confini di team, vendor e organizzazione.
Il 9 aprile 2026 la Linux Foundation ha annunciato il primo anniversario di A2A con numeri che vanno letti con attenzione. Da 50 organizzazioni aderenti al lancio di aprile 2025, il protocollo è salito a oltre 150 in dodici mesi, con SDK production-ready in cinque linguaggi (Python, JavaScript, Java, Go, .NET) e adozione attiva in supply chain, financial services, insurance e IT operations. Microsoft, AWS, Salesforce, SAP, ServiceNow e Cisco stanno facendo girare agenti A2A in produzione, non in proof-of-concept. Per chi sta progettando l’architettura agentica aziendale in questo trimestre, A2A ha cambiato status, da specifica emergente a infrastruttura su cui contare.
Vale la pena fissare subito un punto che troppi piani enterprise continuano a trattare come scelta binaria. A2A non compete con Model Context Protocol di Anthropic, lo completa. MCP standardizza l’asse verticale, il modo in cui un singolo agente accede a strumenti, database e API. A2A standardizza l’asse orizzontale, il modo in cui agenti diversi, costruiti da team diversi su framework diversi, si parlano tra di loro. La metafora che gira nella documentazione è quella del meccanico in un’officina: gli strumenti che ogni meccanico usa per la diagnosi sono il layer MCP, il modo in cui i meccanici si coordinano per lavorare insieme su un’auto è il layer A2A. Una volta capita questa separazione, i cinque pattern di integrazione che descrivo sotto smettono di sembrare un menù di opzioni e diventano una grammatica di composizione.
Indice degli argomenti
Agent Card Discovery: il primo strato di interoperabilità
Il primo pattern, Agent Card Discovery, è quello su cui poggia tutto il resto. Ogni agente A2A espone un Agent Card, un documento strutturato che dichiara cosa l’agente sa fare, quali skill offre, su quali endpoint risponde, quale autenticazione richiede e quali modalità di interazione supporta (sincrono, streaming SSE, push asincrono). L’Agent Card vive a un URL pubblico ben noto, il well-known URI, ed è il punto di ingresso per qualunque altro agente che voglia capire se delegare un task a quel servizio fa senso.
Nella versione 1.0 della specifica, rilasciata all’inizio del 2026, i Signed Agent Cards sono il cambio più importante. Aggiungono una firma crittografica al card, in modo che un agente ricevente possa verificare che il documento sia stato effettivamente emesso dal dominio proprietario. Senza questa verifica, un attaccante poteva esporre un Agent Card falso e dirottare altri agenti verso un endpoint malevolo, con un attacco di card forgery. Per le aziende che stanno disegnando l’architettura agentica come asset critico, i Signed Agent Cards sono la differenza tra discovery decentralizzata teorica e discovery decentralizzata effettivamente sicura.
Delegated Specialization: dividere il lavoro tra agenti specializzati
Il secondo pattern è quello che mette al centro la specializzazione. In una banca, un agente di customer service riceve una richiesta complessa che riguarda un mutuo, una posizione contabile e una richiesta di documentazione fiscale. Invece di tentare di rispondere da solo a tutte e tre le verticali, l’agente delega tre task distinti a tre agenti specializzati: uno sul prodotto mutuo, uno sulla posizione contabile, uno sulla fiscalità. Ogni delega usa il modello task di A2A, dove il client invia un task identificato da un task_id e riceve aggiornamenti via Server-Sent Events fino al completamento, con artifact tangibili come deliverable.
Il valore del pattern è doppio. Riduce la complessità di ogni singolo agente, che resta competente nel proprio dominio invece di gonfiarsi cercando di coprire tutto, e abilita la riusabilità trasversale, perché lo stesso agente specializzato può servire team diversi senza essere reintegrato ogni volta. Il rischio da governare è che senza una buona strategia di task contract, gli agenti deleganti finiscano per usare gli agenti specializzati come tool, banalizzando il protocollo. Ne riparlo nell’ultimo paragrafo.
Tool Bridge con MCP: dove i due protocolli si incontrano
Il terzo pattern è quello che mostra concretamente come MCP e A2A lavorano insieme. Un agente A2A che riceve un task ha bisogno di accedere a dati e strumenti per portarlo a termine, e per farlo usa MCP. L’agente espone all’esterno la propria capability via Agent Card, ma all’interno chiama tool MCP per interrogare il database aziendale, leggere un documento, eseguire una query, generare un report. Il Tool Bridge è esattamente questo: l’agente A2A diventa un ponte tra il mondo orizzontale della collaborazione e il mondo verticale dell’accesso ai dati.
Microsoft Copilot Studio è arrivato a formalizzare la pratica come pattern enterprise consigliato: usare MCP per l’accesso a dati e tool, in particolare ai servizi Microsoft 365, e usare A2A per il messaggistica cross-platform tra agenti. Google nel dicembre 2025 ha adottato MCP per i propri servizi, lanciando server MCP gestiti per Maps, BigQuery, Compute Engine, Kubernetes Engine, Cloud Run, Cloud Storage, AlloyDB, Cloud SQL, Spanner, Looker e Pub/Sub. La convergenza dei due big tech sulla stessa coppia di protocolli è un segnale strategico più forte di qualunque whitepaper di analyst.
Cross-Organization Federation: agenti che parlano tra aziende diverse
Il quarto pattern è quello che apre la dimensione interorganizzativa, e secondo me è il più sottovalutato dei cinque. Fino al 2025, la collaborazione tra agenti era pensata dentro un singolo perimetro aziendale, con autenticazione e identity gestite centralmente. A2A v1.0 introduce primitive per gestire cross-organization federation: due agenti che appartengono a organizzazioni diverse, senza authority server condivisa e senza relazione preesistente, possono scoprirsi, autenticarsi e delegare task in modo verificabile. Il progetto OBO On-Behalf-Of sta lavorando sul gap residuo, ovvero la principal authority chain, cioè chi ha delegato l’autorità all’agente chiamante, sotto quale framework di governance.
Casi reali iniziano a esserci. Tyson Foods e Gordon Food Service stanno costruendo sistemi collaborativi A2A per condividere dati di prodotto e lead lungo la supply chain alimentare. S&P Global Market Intelligence ha attivato la federazione A2A per integrare i propri agenti analitici con quelli dei clienti enterprise. Adobe ha esposto la propria flotta di agenti generativi su A2A per renderla interoperabile con l’ecosistema Google Cloud. Per chi sta pensando a partnership che vivono ai bordi delle proprie API, A2A federation è il primo standard credibile per costruirle senza integrazioni custom una a una.
Ambient Event Mesh: agenti che reagiscono a eventi in tempo reale
Il quinto pattern è quello che sposta il modello da request-response a event-driven, e prende forma in framework come Solace Agent Mesh. Invece di un agente che chiama esplicitamente un altro agente con un task, abbiamo un bus di eventi su cui ogni agente è sottoscritto ai topic che gli interessano. Quando un evento di business viene pubblicato sul bus, gli agenti interessati lo intercettano e reagiscono, eventualmente generando altri eventi che attivano altri agenti, in cascata.
Il vantaggio del modello è la resilienza. Un agente che non risponde non blocca il flusso, perché gli altri continuano a operare sui propri topic. Il routing topic-based abilita asincronia, scalabilità e disaccoppiamento. Per le aziende che già operano su architetture event-driven con Kafka, RabbitMQ o servizi cloud equivalenti, integrare gli agenti come consumer e producer di eventi richiede meno fatica di quanto sembri, perché la mesh che già esiste può fare da spina dorsale anche per il layer agentico. Il prezzo da pagare è la disciplina sulla semantica dei topic e sulla governance degli schemi, che diventano l’asset critico di lungo periodo.
Le tre trappole da evitare e come riconoscerle in tempo
Tre cose vanno chiamate per nome adesso, prima che diventino tecnical debt irreversibile nei prossimi due trimestri. Prima trappola, usare gli agenti A2A come fossero tool MCP. Quando un orchestratore tratta gli agenti specializzati come endpoint funzionali invece che come peer collaborativi, si perde il valore del protocollo, ovvero l’autonomia, la delega pulita, il progress reporting standardizzato e la gestione del ciclo di vita del task. È un anti-pattern che codilime ha documentato come “agents as tools” e che produce sistemi più semplici da debuggare nel breve e meno scalabili nel lungo.
Seconda trappola, non allineare i permessi A2A e MCP. Una volta che si combinano i due protocolli, la skill di un agente A2A può richiedere l’accesso a un tool MCP che la policy aziendale non consente. Bisogna decidere se le permission le decide chi chiama l’agente o chi opera l’agente, e farlo in modo esplicito con delegated token, policy decision point e audit trail che colleghino “task A2A richiesto” a “tool MCP eseguito”. Le aziende che oggi separano IAM agentico da IAM utente stanno costruendo un debito di governance che esploderà tra dodici mesi.
Terza trappola, sottovalutare gli Agent Card non firmati. Per le proof-of-concept va bene, per la produzione no. Senza Signed Agent Cards, un’azienda che apre la propria architettura agentica alla federazione sta esponendo un vettore di attacco non banale. Il momento giusto per imporre la firma è all’inizio, quando l’ecosistema interno è ancora piccolo, perché aggiungerla dopo significa rinegoziare contratti con ogni partner che ha già integrato.
L’ecosistema agentico sta consolidando standard a una velocità che non si vedeva dai primi anni di Kubernetes, e la finestra in cui orientare la propria architettura senza dover ricostruire è di sei-dodici mesi al massimo. Chi sta scegliendo adesso i pattern di integrazione ha ancora margine per disegnare un sistema che scala, chi rimanda al 2027 si troverà a integrare uno standard de facto deciso dagli altri. Senza dubbio l’analisi competitiva pesa più della perfezione tecnica, perché un protocollo subottimo adottato da 150 organizzazioni vale più di un protocollo elegante adottato da nessuno.
