Benvenuti a un'altra pillola di conoscenza. Immaginate di gestire un'azienda e di assumere un team di specialisti, brillanti, un travel planner di classe mondiale, un esperto di onboarding e un addetto al supporto IT, ma nessuno di loro parla con gli altri. Ogni volta che un compito richiede due di loro, dovete camminare tra le scrivanie e trasportare le informazioni voi stessi. Esattamente così che funzionano la maggior parte degli agenti EU. Operano in isolamento anche quando il problema richiede chiaramente un lavoro di squadra. Quindi oggi parliamo di come gli agenti possono comunicare, derivare il lavoro e agire come veri team. Sono Mirko Peter, non si tratta di un concetto futuristico. L'orchestrazione multiagente è già realtà ed è alimentata da un protocollo chiamato A2A. Partiremo dal problema, analizzeremo quel protocollo pezzo per pezzo, vedremo come Microsoft lo utilizza IncoPilot Studio e Azure AI.

Prendete un caffè e iniziamo. Allora, qual è il vero problema? Gli agenti A di oggi sono esattamente come quegli specialisti isolati. Ognuno ha le proprie conoscenze, i propri strumenti e i propri obiettivi. Un agente meteorologico conosce le brevissime. Un agente alberghiero conosce la disponibilità delle camere, ma non condividono nulla. Ora immaginate un utente che chiede un viaggio a Seattle la prossima settimana con un hotel vicino all'ufficio. Un singolo agente dovrebbe essere esperto di meteo, viaggi e affari locali tutto in una volta. Ciò significa prompt enormi e gonfi, che stipano ogni possibile capacità in un unico sistema e quei prompt si rompono costantemente. La vecchia soluzione è il codice personalizzato. Scrivevi un ponte tra l'agente meteo e quello alberghiero, poi un altro tra quello alberghiero e quello per i voli e un altro ancora per il calendario. Funziona all'inizio, ma ogni volta che aggiungi un nuovo agente devi costruire un'altra integrazione.

Ben presto ti ritrovi con un incubo di connessioni punto a punto dove una singola modifica rompe tutto. I guadagni di produttività che la tua IA doveva offrire vengono divorati dal lavoro di manutenzione. Guardiamo il vero problema aziendale. La tua organizzazione ha già processi con dei passaggi di consegne. Viene creato un ticket, qualcuno lo smista, qualcuno lo risolve, qualcuno lo registra e ogni fase è un passaggio. Nel vecchio mondo automatizzi ogni fase con un agente separato e poi passi settimane a collegarli tra loro. Ma se esistesse un protocollo che permettesse agli agenti di scoprirsi e collaborare senza ponti personalizzati, è esattamente quello che fa A2A. In parole semplici A2A è un metodo standard per far parlare gli agenti tra loro, passarsi il lavoro, passarsi il lavoro come un team. Cos'è A2A? La definizione è semplice. A2A sta per Agent to Agent ed Agent ad. È un protocollo aperto che permette agli agenti AI di comunicare direttamente tra loro, indipendentemente da chi li abbia creato.

Si può pensare come un HTTP per agenti. HTTP è il linguaggio che browser e server usano per comunicare e A2A fa la stessa cosa per gli agenti. Un agente creato dal vostro team IT su Microsoft Copilot Studio può parlare con un agente creato da un'altra azienda su Google Cloud, purché entrambi parlino A2A. Non si tratta di un piccolo progetto. A2A è sponsorizzato da otto grandi aziende, tra cui Google, Microsoft, Cisco, Salesforce, SAP e altre, ed è ospitato dalla Linux Foundation. La versione 1.0 è stabile, pronta per l'uso reale, che significa che nessun singolo fornitore controlla il protocollo. Non è una cosa di Google o di Microsoft, è una cosa di intero settore. Intenzionalmente semplice. A2A si basa su standard web esistenti come HTTP e JSON-RPC, cose che ogni sviluppatore già conosce. Niente di esotico proprietario. Questo rende facile per le aziende adottarlo senza dover stravolgere l'infrastruttura esistente.

Ora, potreste aver sentito parlare di un altro protocollo chiamato MCP o Model Context Protocol. Ecco la differenza. MCP è da agente a strumento, il che significa che connette un agente a fonti di dati esterne e API. A2A è da agente ad agente, collegando gli agenti direttamente tra loro. Non sono concorrenti, sono complementari. Pensate a MCP come alla connessione verticale dall'agente ai suoi strumenti e ad A2A come alla connessione orizzontale tra agenti affiancati. Un'altra scelta di progettazione. A2A tratta gli agenti come opaco. Quindi, quando un agente parla con un altro, non vede i ragionamenti interni, gli strumenti, i dati privati dell'altro agente. Vede solo il compito che ha inviato e il risultato che riceve. Questo preserva la privacy intellettuale. Un agente meteo non ha bisogno di sapere come l'agente di un hotel prenoti le stanze, deve solo fornire le previsioni. Ora, esaminiamo il primo pezzo del puzzle.

L'agent card. L'agent card, il curriculum. Ogni agente compatibile con A2A pubblica qualcosa chiamato agent card. Quella scheda è un documento leggibile dalle macchine che risiede in un URL standard sul dominio dell'agente, specificamente al percorso well-known agent card json. Se sai dove risiede un agente, puoi recuperare la sua scheda e imparare tutto ciò che ti serve per lavorarci. Pensa all'agent card come un curriculum o un biglietto da visita. Dice agli altri agenti chi sei e cosa puoi fare. La scheda contiene il nome dell'agente, una descrizione testuale delle sue capacità e tag di competenza che aiutano a scoprirlo. Elenca inoltre l'URL dell'endpoint in cui accetta le richieste, i requisiti di autenticazione, i formati di input e output accettati. Ecco un esempio concreto. Supponiamo che tu abbia un agente specializzato nel me. La sua scheda agente dice posso fornire meteo attuale e le previsioni a 5 giorni per qualsiasi città.

Elenca i suoi endpoint API, accetta il nome di una città e restituisce temperature e condizioni in formato json. Tutto qui. È solo una chiara dichiarazione di ciò che può fare, senza segreti o logiche interne esposte. La scoperta funziona così. Un agente orchestratore possiede un elenco di URL di agenti noti oppure puoi configurarlo con essi. Quando arriva un'attività, l'orchestratore recupera le schede, legge le descrizioni e decide qual è l'agente più adatto. La scheda meteo indica meteo, quindi le attività sul meteo vanno lì. La scheda hotel indica hotel, quindi le attività sugli hotel vanno lì. Nota che non è richiesto alcun registro centrale. Gli agenti non devono registrarsi in una directory globale. Pubblicano semplicemente una posizione nota e qualsiasi altro agente che ne conosca l'URL può trovarli. È una scelta di design deliberata che mantiene il sistema decentralizzato e flessibile.

Puoi aggiungere un nuovo specialista alla rete fornendo all'orchestratore il suo URL e la scoperta avviene automaticamente. Quindi l'orchestratore sa chi è disponibile. Ma come fanno effettivamente a trasferirsi da VOO? Come funziona la comunicazione a 2A? Dunque, l'orchestratore sa quali agenti sono disponibili tramite la scheda JET. Ma come fanno questi agenti a passarsi il lavoro l'un l'altro? La risposta è semplice. Ogni comunicazione avviene via HTTP utilizzando messaggi JSON-RPC e lo stesso protocollo che alimenta la maggior parte dei servizi web odierni. Niente di personalizzato e complicato solo traffico web standard che scorre tra 2A. Ecco il punto. Non tutte le attività sono uguali. A2A supporta 3 diversi modelli di interazione a seconda delle tue esigenze. La risposta istantanea gestisce le ricerche rapide in cui l'agente remoto può rispondere immediatamente. Invii una richiesta, risponde subito e hai finito.

Chiedere a un agente metto le previsioni di oggi funziona esattamente così. Risposta sincrona dentro e fuori. Streaming gestisce le attività più lunghe. Forse l'agente specializzato deve consultare più database o eseguire un'analisi complessa. Invece di farti attendere una singola risposta l'agente invia aggiornamenti di stato mentre lavora usando eventi inviati dal server. Ottieni rapporti sui progressi lungo il percorso e poi il risultato finale arriva alla fine. Monitorare la consegna di un pacco funziona allo stesso modo. Vedi ogni fase mentre accade. La notifica sincrona gestisce le attività a lunga durata in cui l'agente remoto potrebbe impiegare minuti, ore o persino giorni. L'inserimento di un dipendente è un buon esempio. Uno specialista predispone gli account IT mentre un altro gestisce l'iscrizione ai benefit per più giorni. L'agente client invia una richiesta, riceve un ID attività e prosegue con il proprio lavoro.

In seguito l'agente remoto invia risultato tramite un webbook. Il client può anche verificare l'avanzamento in qualsiasi momento interrogando quelle di attività. Ogni interazione segue la stessa struttura tutta organizzata come un'attività. Quando il client invia una richiesta l'agente remoto crea un'attività e restituisce un ID attività. Quell'ID diventa riferimento di tracciamento per tutto ciò che segue. I messaggi all'interno di quell'attività hanno un ruolo che indica chi li ha inviati e delle parti che possono essere testo semplice, dati binari come immagini o documenti, payload JSON o URL che puntano a file archiviati altrove. Autenticazione segue le convenzioni web standard o out chiavi API token bearer. I soliti noti, nulla di nuovo da imparare qui. La scheda dell'agente indica al client quale metodo di autenticazione utilizzare. Il client lo gestisce esattamente come farebbe per qualsiasi altra chiamata IP.

Ecco come appare nella pratica. Supponiamo che l'orchestratore abbia bisogno di dati meteo per un viaggio. Invia un'attività allo specialista meteo. Lo specialista meteo prende in carico la richiesta avvia l'elaborazione e trasmette gli aggiornamenti sull'avanzamento. Recupero dati. Analisi dei risultati. Va. Poi invia la previsione finale. L'orchestratore non vede mai gli strumenti interni dell'agente meteo, le sue chiavi API più il suo processo di ragionamento. Vede solo l'output. Questo è il principio di progettazione chiave. Confini netti tra gli agenti e nessuno stato interno che trapela. Ma la 2A da solo non basta. Serve un capo intelligente per coordinare tutti questi specialisti. Questo ci porta al modello orchestratore specialista. Il modello orchestratore specialista. E' qui che tutto si collega. Modello orchestratore specialista è l'architettura più comune nei sistemi multiagente in produzione oggi.

Pensalo come un'azienda con diversi dipartimenti. IT, HR, finanza, ognuno che gestisce la propria area. Hai un decisore centrale che indirizza il lavoro a team specializzati e ogni team si concentra su ciò che sa fare meglio. L'orchestratore ha la visione di insieme. Riceve la richiesta dell'utente, capisce cosa deve accadere e decide quale specialista può gestire ogni parte. Se un utente chiede, pianifica un viaggio a Seattle la prossima settimana. L'orchestratore non prenota voli né controllo hotel. Sa che esiste uno specialista per i voli, uno per gli hotel e uno per il meteo. Suddivide la richiesta in quelle parti e delega ciascuna di esse. Ogni specialista ha un focus ristretto. Un agente gestisce la prenotazione dei voli, un altro la ricerca di hotel e un terzo gestisce il triaggio incidente. Non hanno bisogno di conoscere i domini l'uno dell'altro. Lo specialista dei voli conosce compagnie aeree, rotte e prezzi.

Non deve sapere nulla di tipi di camera d'albergo o politiche di cancellazione. Questo focus ristretto mantiene ogni agente semplice e facile da gestire e da testare. Ma la parte importante, L'orchestratore non esegue i compiti. In strada e lavoro unisce risultati. Questo è il suo unico compito. Il ruolo dell'orchestratore è essere un dispatcher intelligente che cerca di fare tutto. Quando lasci che l'orchestratore inizia a fare il lavoro dello specialista, perdi l'intero vantaggio del modello. Diventa di nuovo un disastro monolito. Attenzione a un errore comune. Alcuni team creano domini specialistici sovrapposti. Due agenti dichiarano entrambi di poter gestire il supporto clienti o la ricerca dati, creando confusione nell'estradamento. L'orchestratore non sa quale scegliere e gli utenti ottengono risultati incoerenti. La soluzione è semplice. Ogni specialista possiede un dominio chiaramente delimitato senza sovrapposizione.

Se due agenti possono fare la stessa cosa, unisceli o dividi i domini in modo più netto. Copilot Studio di Microsoft utilizza questo modello nativamente. Il tuo copilot principale funge da orchestratore, mentre gli agenti secondari e connessi agiscono da specialisti. Quando un utente chiede qualcosa che abbraccia più domini, il copilot principale delega gli specialisti giusti tramite A2A. È integrato nella piattaforma, quindi non devi scrivere la logica di orchestrazione da zero. Il grande vantaggio qui è la modularità. Devi cambiare il tuo fornitore di prenotazione alberghia. Sostituisci lo specialista hotel senza toccare l'orchestratore o qualsiasi altro agente. Vuoi aggiungere una nuova funzionalità? Crea un nuovo specialista, registralo con l'orchestratore e è finito. Ogni agente rimane piccolo, gestibile e in modo indipendente. Questo è l'intero punto del passaggio ad agenti monolitici a un sistema multiagente.

Quindi abbiamo il protocollo, le schede agente e il modello. Vediamo le nazioni con scenari reali. Esempri reali di A2A in azione. Allora, che aspetto all'A2A nel mondo reale? Iniziamo con un esempio semplice. Dice al tuo assistente IA, pianifica, un viaggio a Seattle la prossima settimana. Nel vecchio modo di fare le cose, quel singolo assistente dovrebbe sapere tutto. Meteo, voli, hotel, ristoranti, tutto insieme. È molto da chiedere a un singolo promo. Con l'A2A l'orchestratore suddivide il compito. Invia un compito a uno specialista meteo chiedendo le previsioni per quei giorni specifici. Allo stesso tempo chiede a uno specialista di voli di trovare voli in arrivo martedì mattina e ritorno giovedì sera. È uno specialista di hotel di cercare strutture vicino al centro di Seattle per tre notti. Ogni specialista lavora in modo indipendente e non ha bisogno di comunicare con gli altri agenti poiché ognuno dispone delle proprie fonti di dati, strumenti e competenze.

L'orchestratore raccoglie tutti i risultati e li unisce in un'unica risposta. L'utente vede una risposta singola. Ecco le previsioni meteo. Queste sono le opzioni di volo e qui ci sono tre hotel vicino all'ufficio. Dietro le quinte tre agenti distinti hanno collaborato senza alcun codice di integrazione personalizzato. Ora uno scenario aziendale. Supponiamo che arrivi un ticket, il mio portatile non si connette alla VPN. L'orchestratore capisce che si tratta di un problema di rete. Passa il ticket a uno specialista di runbook che conosce le procedure standard. Controllare lo stato del client VPN, verificare le credenziali di rete, riavviare il servizio. Quello specialista restituisce passaggi da seguire. Quindi l'orchestratore passa il risultato a uno specialista di scrittura ticket che registra la risoluzione nel sistema. Tutto questo avviene in pochi secondi senza intervento umano. E il team IT viene coinvolto solo se le procedure automatizzate non risolvono il problema.

L'onboarding dei dipendenti è un altro esempio, ma questo richiede giorni, non secondo. Una nuova risorsa internaziana. L'orchestratore attiva uno specialista IT per creare gli account e assegnare l'hardware operazione che potrebbe richiedere alcune ore. Allo stesso tempo attiva uno specialista HR per i moduli di benefit e, successivamente, uno specialista di struttura per la scrivania e l'accesso con badge. Ogni specialista esegue il proprio compito a lungo termine in modo indipendente e l'orchestratore ne traccia i progressi usandogli di attività di cui abbiamo parlato prima. Quindi se lo specialista IT finisce, l'orchestratore lo sa, e se lo specialista di struttura è in ritardo, può fare un sollecito. L'utente vede un flusso di onboarding fluido, ma dietro le quinte si tratta di un team coordinato che lavora per più giorni. E non è solo teoria. Coca-Cola beve raggi e savrica. Sta già utilizzando gli agenti di Copilot Studio con Dynamics 365 per automatizzare i cicli di pianificazione.

I loro pianificatori spendevano fino a un'ora e mezza ogni giorno in compiti ripetitivi. Con l'orchestrazione multiagente, quei cicli vengono eseguiti automaticamente. L'orchestratore delega gli specialisti che gestiscono diverse parti del processo di pianificazione della catena di distribuzione. Il risultato è un risparmio di oltre un'ora al giorno per persona, semplicemente lasciando che gli agenti comunichino tra loro invece di far spostare manualmente le informazioni tra i sistemi. Dunque, lo schema è lo stesso in tutti questi esempi. Ogni agente è un esperto autonomo che conosce il proprio dominio e possiede i propri strumenti senza bisogno di sapere nulla sugli altri agenti. A2A fornisce un semplice livello di comunicazione che permette loro di collaborare senza codice personalizzato. Si ottiene un protocollo standard e un orchestratore intelligente, senza bridge, integrazioni punto a punto, problemi di manutenzione.

Microsoft ha puntato tutto su questo. Vediamo dove si collocano Copilot Studio e Azure AI. L'ecosistema Microsoft Copilot Studio e Azure AI? Quindi, dove si possiede Microsoft in tutto? Esattamente al centro. Copilot Studio supporta ora A2A nativamente ed è disponibile a livello generale dall'aprile 2026. Non si tratta di un anteprimo di una versione bella. È pronto per la produzione e qualsiasi cliente idone può utilizzarlo a gi stesso. Ecco il punto. Puoi connettere agenti esterni al tuo orchestratore di Copilot Studio. Quando dico esterni, intendo veramente esterni. Agenti creati su Google Cloud, AWS o qualsiasi altra piattaforma che supporti il protocollo A2A. All'orchestratore non importa dove li sia dall'agente o con quale framework sia stato creato. Finché parla A2A può unirsi al team. La configurazione è semplice. In Copilot Studio crei quello che viene chiamato agente connesso. Incolli l'URL dell'endpoint dell'agente.

Copilot Studio recupera automaticamente la scheda dell'agente da quell'URL, ovvero il noto file JSON della scheda agente di cui abbiamo parlato. Legge le capacità dell'agente, i requisiti di autenticazione e i formati di input e output. Poi crea un connettore personalizzato dietro le quinte e il tuo orchestratore può iniziare subito a delegare le attività. Non serve lavoro di integrazione manuale o codice personalizzato. Basta incollare l'URL e gioca i fatti. Sul versante Azure anche Azure AI Foundry Agent Service supporta A2A. Dispone di un endpoint API A2A dedicato che consente agli orchestratori open source come Autogen, Langchain e Semantic Kernel di invocare gli agenti Foundry. Quindi se hai creato agenti utilizzando quei framework puoi collegarli all'ecosistema Microsoft senza riscrivere nulla. È una strada più sena. Microsoft segue lo stesso modello orchestratore specialista che abbiamo descritto.

L'agente principale in Copilot Studio agisce da orchestratore, mentre gli agenti secondari e connessi sono gli specialisti. Ognuno gestisce il proprio dominio mentre l'orchestratore in strada unifica i risultati. È la stessa architettura solo eseguita sulla piattaforma Microsoft. Ma attenzione, ci sono alcune limitazioni che devi conoscere. Primo, ogni passaggio di orchestrazione aggiuntivo aggiunge la terza. Se il tuo agente principale chiama un agente connesso e questo chiama un altro specialista, ogni passaggio aggiunge tempo di rete. Per le conversazioni in tempo reale troppi passaggi possono rendere l'esperienza lenta. Secondo, una delega eccessiva crea caos nell'istradamento. Se hai troppi specialisti con domini sovrapposti, l'orchestratore inizia a prendere decisioni di istradamento errate. Quindi mantieni il numero dei tuoi specialisti gestibile e i domini chiaramente separati. Terzo, c'è una limitazione specifica con gli agenti dati di Fabric.

Non funzionano quando l'agente principale viene distribuito su Microsoft 365 Copilot. Se la tua implementazione è punta M365, pianifica di conseguenza. Questi vincoli sono reali ma gestibili. La piattaforma è abbastanza matura per l'uso in produzione e Microsoft sta lavorando attivamente per colmare queste lacune. Ora, uniamo i puntini e guardiamo il quadro generale. Sezione di connessione, come si incastra tutto. Facciamo un passo indietro e vediamo come si collegano questi pezzi. A2A è il sistema telefonico che gli agenti usano per chiamarsi a vicenda. Le schede agente sono la tua rubrica telefoni. Ti mostrano chi chiamare e cosa gestisce ogni agente. L'orchestratore e il centralinista che in strada ha ogni chiamata al dipartimento giusto. Nessuno di questi elementi funziona da solo. Hai bisogno di tutti e tre. Senza una rubrica non sai chi chiamare. Senza un centralinista nessuno dirige il traffico.

E senza un sistema telefonico il centralinista non può collegare nessuno. Funzionano solo come una squadra. È qui che entra in gioco la modularità. Quando i tuoi specialisti sono modulari puoi aggiungere nuove funzionalità senza rompere ciò che già funziona. Supponiamo che tu voglia aggiungere uno specialista per il noleggio auto al tuo assistente di viaggio. Lo costruisci, pubblichi la sua scheda agente e dai all'orchestratore e il suo ragente. Lo specialista dei voli e quello degli hotel rimangono esattamente gli stesi. Anche l'orchestratore non cambia. Inserisci semplicemente un nuovo pezzo e il sistema è sedato. Poiché il protocollo è aperto non rimarrai mai bloccato con un unico fornito. Il tuo orchestratore può girare su Copilot Studio. Il tuo agente meteo può risiedere su Google Cloud. Quello per gli hotel su AWS e i tuoi sistemi interni su Azure. Parlano tutti la stessa lingua. Questa è la bellezza di un standard aperto.

Evita il vendor lock-in e ti permette di scegliere lo strumento migliore per ogni compito. A2A non riguarda la creazione di un super agente intelligente che sa tutto. Riguarda la costruzione di una forza lavoro flessibile di specialisti che puoi riorganizzare e variare delle tue esiste. Non sostituisci i tuoi agenti, li riorganizzi. Ne aggiungi di modo. Sostituisci quelli vecchi. Il sistema cresce con te invece di diventare un collo di bottiglie. Quindi cosa puoi fare con questa conoscenza oggi? Punti chiave pratici. Inizia in P. Scegli un processo ripetitivo nella tua organizzazione che coinvolga più sistemi. Resoluzione di ticket, inserimento di dipendenti o rendicontazione spese, per esempio. Qualcosa con chiari passaggi di consegne tra le varie fasi. Poi costruisci un prototipo con un orchestratore e due specialisti. Non ti serve una grande architettura. Ti serve solo un esempio funzionante da cui poter imparare.

Usa gli strumenti che lo supportano già. Coppile lo studio e il supporto A2A integrato e anche Azure AI Foundry. Non devi creare il protocollo da zero o scrivere codici di integrazione. Incolla un URL, configura i tuoi agenti e inizia a delegare. Fai attenzione nei siti comuni. Evita che le aree specializzazioni si sovrapponga. Se due agenti possono fare la stessa cosa, uniscili o separa meglio i domini. Lascia che l'orchestratore gestisca l'instradamento, non l'esecuzione. E tieni d'occhio all'attenza dovuta ai passaggi dell'orchestrazione. Se i tempi di risposta aumentano, potresti avere troppi livelli di delega. Il miglior primo passo è semplice. Mappa i passaggi di consegne nel tuo flusso di lavoro A2A. Dove vengono scambiate le informazioni tra persone o sistemi? Quelli sono i punti in cui gli agenti possono subentrare. Ogni passaggio di consegne ha un'opportunità. Quindi questo è il sistema A2A in sintesi.

Tre semplici componenti che lavorano insieme. Gli agenti smettono di essere isolati e iniziano ad agire come un vero T. Scegli un flusso di lavoro con passaggi chiari e costruisci da lì. Iscriviti per altre analisi semplici e lascia un commento se qualcosa ti è stato utile. Grazie.