IBM Research e Google hanno annunciato che l’Agent Communication Protocol (ACP) confluirà ufficialmente nell’Agent-to-Agent Protocol (A2A) sotto l’ombrello della Linux Foundation. La decisione nasce dalla volontà di consolidare gli sforzi della comunità in un unico standard, evitando duplicazioni e accelerando l’adozione industriale.
Nato in IBM Research per supportare la piattaforma BeeAI, ACP ha rappresentato fin dall’inizio un tentativo di rendere interpretabile e trasparente l’interazione tra agenti software. La convergenza con A2A, promosso da Google e sostenuto da un ecosistema ampio che include Microsoft, AWS, Cisco, Salesforce, ServiceNow e SAP, segna il passaggio da iniziative parallele a una governance condivisa.
“Unire ACP e A2A significa creare un linguaggio comune per gli agenti AI”, ha dichiarato Kate Blair, direttrice dell’incubazione in IBM Research. Todd Segal di Google ha aggiunto che la convergenza consentirà di costruire un ecosistema interoperabile, in grado di favorire collaborazioni cross-vendor e cross-framework.
Il protocollo A2A si propone come standard universale per consentire ad agenti eterogenei — sviluppati con framework diversi e ospitati in ambienti distribuiti — di comunicare e collaborare in modo sicuro, scalabile e interoperabile.
A2A non dipende dal linguaggio di programmazione o dal runtime adottato dagli agenti, è stato concepito per supportare architetture multi-cloud e scenari di federation, in cui agenti sviluppati da diversi vendor interagiscono senza attriti; le specifiche A2A prevedono inoltre meccanismi di estensione che permettono di introdurre nuove tipologie di messaggi, protocolli di sicurezza o schemi di autenticazione senza rompere la compatibilità.
Con l’integrazione di ACP, A2A eredita anche il focus di IBM sulla trasparenza e interpretabilità, elementi cruciali per la compliance normativa e per la fiducia degli utenti nei sistemi basati su agenti autonomi.
Il ruolo di BeeAI e la migrazione da ACP
Per gli sviluppatori e le aziende che avevano adottato ACP tramite la piattaforma BeeAI, la transizione è stata progettata per essere graduale, grazie a strumenti e documentazione a supporto. L’A2AServer adapter consente agli agenti già sviluppati in BeeAI di diventare conformi ad A2A; L’A2AAgent abilita l’integrazione di agenti esterni, indipendentemente dalla tecnologia con cui sono stati costruiti, all’interno di applicazioni BeeAI. La Linux Foundation, in collaborazione con IBM e Google, mette a disposizione percorsi guidati per portare in A2A gli sviluppi basati su ACP.
Questa compatibilità garantisce che gli investimenti realizzati non vadano persi, e al tempo stesso apre BeeAI a un ecosistema più vasto di agenti e framework.
Governance e comunità open-source
Il futuro di A2A sarà definito dalla Technical Steering Committee (TSC), che ora include Kate Blair di IBM insieme a rappresentanti di Google, Microsoft, AWS, Cisco, Salesforce, ServiceNow e SAP. Questa pluralità di attori garantisce un equilibrio tra interessi industriali e comunità open-source, con l’obiettivo di costruire uno standard realmente condiviso.
Gli sviluppi saranno coordinati su GitHub, dove sono già presenti le prime istruzioni per integrare le funzionalità ACP nel codice A2A. La documentazione verrà aggiornata progressivamente, con un’attenzione particolare alle esigenze degli sviluppatori che devono mantenere compatibilità con sistemi in produzione.
L’unificazione sotto A2A non è solo un fatto tecnico, ed è positivo che sia avvenuta in una fase iniziale dello sviluppo dell’ecosistema di agenti che interagiscono, evitando la frammentazione, che era uno dei rischi principali per la crescita dell’ecosistema agentico e favorendo una più ampia adozione grazie uno standard unico, interoperabile cross-vendor. Un protocollo standard aiuta anche regolatori e policy maker a definire linee guida più chiare in materia di sicurezza, trasparenza e responsabilità degli agenti AI.
Come funziona A2A
A2A funziona come un protocollo di messaggistica strutturata. Non definisce solo la trasmissione dei dati, ma anche il formato semantico con cui gli agenti comunicano.
Un messaggio A2A contiene tipicamente:
- Header: con informazioni su chi invia, chi riceve, identificativi di sessione e timestamp.
- Payload: la parte principale del messaggio, che può contenere:
- Intent (es. “richiesta dati”, “esegui azione”, “fornisci spiegazione”)
- Dati strutturati (in JSON o altri formati serializzati)
- Metadati di contesto (ad esempio, stato della conversazione o policy di sicurezza).
- Security Layer: firme digitali e token di autenticazione per garantire integrità e provenienza.
Il protocollo supporta diversi pattern di comunicazione, tra cui:
- Request/Response: un agente chiede informazioni a un altro, che risponde.
- Event Notification: un agente invia notifiche di cambiamento di stato.
- Collaboration/Workflow: più agenti si coordinano per portare a termine un compito complesso (es. prenotare un volo, gestire una supply chain, automatizzare un processo IT).
Un ipotetico ma realistico workflow aziendale basato sulla comunicazione tra agenti
- Un agente HR (ServiceNow) deve programmare un colloquio.
- Invia un messaggio A2A a un agente calendario (Google).
- L’agente calendario risponde con gli slot disponibili.
- L’agente HR invia un’istruzione a un agente di comunicazione (Microsoft Teams o Slack) per fissare la call.
Tutti gli scambi avvengono tramite messaggi A2A, indipendentemente da chi abbia sviluppato gli agenti o su quale cloud siano ospitati.
Questo workflow e altri simili potrebbero essere facilmente implementati – si potrebbe obiettare – utilizzando le API messe a disposizione dai vari sistemi. Ma la differenza tra una chiamata API classica e una comunicazione Agent-to-Agent (A2A) non è banale, perché entrambe si basano su messaggi strutturati, ma hanno obiettivi e semantiche diverse.
Nel primo caso l’interazione è del tipo client-server: il client chiama un endpoint predefinito, riceve una risposta e le interazioni sono rigide e predeterminate (ad es. /users/{id} → restituisce sempre i dati utente).
A2A è peer-to-peer: entrambi gli agenti possono iniziare e rispondere; le interazioni sono semantiche: non “dammi il record X”, ma “esegui un’azione”, “notificami un evento”, “collabora a un workflow” ed è supportato il workflow multi-turn: un messaggio può generare risposte, eventi, negoziazioni tra più agenti.
La struttura dei messaggi A2A è standardizzata con header, payload e security. Ogni messaggio ha elementi nativi per tracciare flussi conversazionali e garantire consistenza. Gli intent (Request, Response, Event, Workflow) sono parte dello standard, non invenzioni del singolo sviluppatore. Così come la sicurezza, fondamentale per l’interazione tra sistemi autonomi, è parte del messaggio stesso (firma digitale, token, autenticazione).
