- Cosa sono MCP e A2A?
- Come collaborano gli agenti AI nel Service Desk?
- Quali rischi introduce la delega tra agenti?
Dall’assistente isolato alla rete operativa
Il prossimo salto dell’AI nel Service Desk non riguarda soltanto modelli più capaci. Riguarda la possibilità di far collaborare agenti costruiti da fornitori diversi e di collegarli agli strumenti aziendali senza riscrivere ogni integrazione da zero. È qui che stanno convergendo due standard aperti: Model Context Protocol, o MCP, per collegare applicazioni AI a dati, strumenti e workflow; Agent2Agent, o A2A, per consentire ad agenti indipendenti di scoprirsi, scambiarsi messaggi e coordinare attività.
Il segnale di mercato è ormai concreto. Il 9 aprile 2026 la Linux Foundation ha comunicato che A2A aveva superato 150 organizzazioni sostenitrici, con integrazioni nelle principali piattaforme cloud e primi impieghi produttivi anche nell’IT operations. Il dato proviene dall’organizzazione che ospita il progetto e descrive il relativo ecosistema, non l’adozione globale delle imprese; indica però che l’interoperabilità sta passando dalla discussione tecnica alla roadmap dei vendor.
Per un responsabile Service Desk la domanda utile non è quindi se adottare un nuovo acronimo. È capire come cambia il modello operativo quando il portale, l’agente di supporto, l’identity platform, l’endpoint management e un fornitore esterno possono diventare partecipanti attivi dello stesso flusso.
MCP porta gli strumenti all’agente; A2A porta gli agenti nel processo
La distinzione è importante. MCP standardizza il modo in cui un’applicazione AI accede a risorse e strumenti: consultare una knowledge base, leggere lo stato di un dispositivo, interrogare il catalogo oppure avviare un workflow autorizzato. A2A affronta invece la collaborazione tra sistemi agentici: un agente può pubblicare le proprie capacità, ricevere un compito, gestirne lo stato e restituire risultati o artefatti.
La specifica A2A descrive agenti potenzialmente opachi e realizzati con linguaggi, framework o vendor diversi. Le Agent Card ne espongono capacità e schemi di autenticazione. Questo riduce la necessità di conoscere l’implementazione interna, ma non rende automaticamente affidabile ciò che si trova dietro l’interfaccia. Un protocollo comune facilita la connessione; non certifica qualità, autorizzazione o correttezza dell’azione.
Nel Service Desk la combinazione può essere potente. L’agente che conversa con l’utente usa MCP per ottenere contesto da knowledge e asset management; delega via A2A la verifica dell’identità a un agente specializzato; invoca poi un workflow di remediation e aspetta una prova tecnica del ripristino. È una possibile architettura, non una funzionalità garantita dagli standard: la responsabilità di progettarne controlli e confini resta dell’organizzazione.
Il vantaggio non è connettere tutto, ma governare ogni delega
Una rete di agenti aumenta il numero di confini attraversati da una singola richiesta. Identità dell’utente, identità del client, agente chiamante, strumento invocato e sistema che esegue l’azione non sono necessariamente la stessa cosa. La documentazione enterprise di A2A chiarisce che l’identità non viaggia nel payload del protocollo: viene stabilita a livello di trasporto e autenticazione HTTP. La documentazione MCP, a sua volta, basa l’autorizzazione su OAuth 2.1 e pubblica pratiche specifiche contro rischi come confused deputy, token passthrough e session hijacking.
La conseguenza manageriale è netta: non basta una service account condivisa. Ogni delega deve conservare chi ha chiesto cosa, quale agente ha deciso, quale strumento ha agito, con quale autorizzazione e quale evidenza ha prodotto. Per azioni ad alto impatto servono least privilege, separazione degli ambienti, approvazione umana quando prevista e un percorso di rollback realmente testato.
Il controllo va progettato per livello di autonomia. Cercare una procedura richiede cautele diverse dal resettare credenziali, distribuire software o modificare un gruppo privilegiato. Una matrice semplice può incrociare reversibilità, sensibilità dei dati, impatto sul servizio e necessità di conferma. Lo standard rende interoperabile il canale; la matrice rende governabile la decisione.
Osservabilità: dal ticket alla catena delle decisioni
Il ticket tradizionale registra assegnazioni, note e tempi. In un flusso multi-agente questo non basta: una risposta può dipendere da più chiamate, contesti recuperati, deleghe e tentativi. Senza una correlazione end-to-end, il Service Desk vede l’esito finale ma non sa dove sono nati latenza, costo o errore.
La nuova unità di osservazione dovrebbe essere la catena di servizio. Per ogni richiesta servono un correlation ID, la sequenza delle deleghe, le versioni degli agenti, gli strumenti utilizzati, le policy applicate, il consumo, gli interventi umani e la prova dell’outcome. Non occorre riversare dati sensibili nei log: occorre progettare una traccia sufficiente a ricostruire la decisione rispettando minimizzazione e retention.
Le metriche cambiano di conseguenza. Oltre a tempo di risoluzione e first contact resolution diventano utili: percentuale di deleghe riuscite, tempo per handoff, tasso di fallback umano, azioni annullate, errori per agente o strumento, costo per outcome verificato e incidenti ricorrenti dopo una remediation automatica. L’obiettivo non è premiare l’agente più autonomo, ma il servizio che restituisce capacità con rischio e costo sostenibili.
Sourcing: meno lock-in tecnico, più responsabilità contrattuale
Gli standard aperti possono ridurre il costo delle integrazioni proprietarie e rendere sostituibile un componente. Non eliminano però il lock-in da dati, prompt, policy, telemetria o modelli operativi. Un fornitore può supportare A2A o MCP e lasciare comunque all’organizzazione costi elevati di migrazione, osservabilità incompleta o responsabilità poco chiare in caso di azione errata.
La supplier governance dovrebbe quindi chiedere evidenze verificabili: versione e conformità del protocollo, modalità di autenticazione, granularità delle autorizzazioni, tracciabilità, limiti di utilizzo, portabilità dei log, gestione delle vulnerabilità, compatibilità all’indietro e tempi di revoca. Servono anche scenari di uscita: cosa accade se un agente viene disattivato, il relativo endpoint cambia oppure una capacità dichiarata non è più disponibile?
La crescente implementazione nei prodotti ITSM conferma la direzione, ma le affermazioni dei vendor restano dichiarazioni commerciali. ServiceNow, per esempio, descrive MCP e A2A come elementi del proprio Action Fabric; Microsoft ha documentato nel 2026 connessioni A2A in Foundry e gestione di agent API. Sono fatti utili per valutare maturità e opzioni, non prove indipendenti di beneficio economico.
Partire da un journey, non da una rete completa
La scelta prudente è iniziare con un journey delimitato, reversibile e misurabile. Un esempio è il recupero di un account bloccato: raccolta del contesto, verifica delle condizioni, delega a un agente identity, esecuzione controllata, conferma all’utente e verifica che l’accesso sia stato ripristinato. Prima di automatizzare si definiscono baseline, ruoli, autorizzazioni, eccezioni e fallback.
La prova dovrebbe rispondere a sei domande: l’agente giusto è stato scoperto? La delega ha mantenuto identità e contesto necessari? Le autorizzazioni erano minime? L’azione è stata tracciata? L’outcome è verificabile? Costo, latenza e rilavorazioni migliorano rispetto al percorso precedente? Se una risposta manca, aumentare il numero di agenti amplia soprattutto l’incertezza.
La mia interpretazione è che MCP e A2A non sostituiranno l’ITSM: ne renderanno più importante la disciplina. Catalogo, ownership, change, incident, knowledge, supplier management e continual improvement diventano il sistema di governo della nuova forza lavoro digitale. Il Service Desk può essere la regia di questa rete, a condizione di misurare non quante azioni compiono gli agenti, ma quanto lavoro affidabile restituiscono alle persone.
Fonti e approfondimenti
- Linux Foundation — A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms and Sees Enterprise Production Use in First Year — 9 aprile 2026 ↗
- A2A Protocol Project — Agent2Agent Protocol Specification — consultata il 20 agosto 2026 ↗
- A2A Protocol Project — Enterprise Features — consultata il 20 agosto 2026 ↗
- Model Context Protocol — Security Best Practices — 28 luglio 2026 ↗
- Microsoft Learn — Connect to an A2A agent endpoint from Foundry Agent Service — 5 agosto 2026 ↗
- ServiceNow — Action Fabric: MCP, A2A e workflow governati — consultata il 20 agosto 2026 ↗
Analisi e interpretazioni sono personali e non rappresentano le posizioni delle organizzazioni citate o del mio datore di lavoro.