Ad aprile 2026 il Model Context Protocol (MCP) risultava implementato su oltre 10.000 server enterprise, con più di 97 milioni di download dei kit di sviluppo e l’adozione di Anthropic, OpenAI, Google, Microsoft e AWS. Dietro questi numeri c’è uno spostamento di architettura: dall’unico grande modello che fa tutto al sistema di agenti che si dividono il lavoro.
L’idea è semplice da enunciare e difficile da realizzare bene. Invece di chiedere a un solo modello di pianificare, cercare, eseguire e controllare, si compone una squadra di agenti, ognuno con un compito e dei limiti precisi.
Il motivo per cui questa architettura si è imposta merita una spiegazione, perché non è ovvia.
Orchestratore e specialisti
Il pattern dominante prevede un agente orchestratore che coordina e un insieme di agenti specializzati che eseguono.
L’orchestratore riceve l’obiettivo, lo scompone, decide a chi affidare ogni pezzo e ricompone i risultati. Non fa il lavoro: lo distribuisce. È il direttore d’orchestra che non suona nessuno strumento ma tiene insieme l’esecuzione.
Sotto di lui operano gli specialisti. Un agente researcher raccoglie informazioni da fonti interne ed esterne. Un planner trasforma l’obiettivo in una sequenza ordinata di passi. Un executor compie le azioni concrete, dall’aprire un ticket all’aggiornare un record. Un agente di quality assurance verifica che il risultato regga prima di consegnarlo, controllando che non ci siano errori o incongruenze.
La divisione dei ruoli non è eleganza architetturale fine a se stessa. Ha un rationale operativo: un agente con un compito stretto è più facile da controllare, da testare e da correggere di un agente tuttofare. Quando qualcosa va storto, si sa dove guardare, perché ogni agente ha una responsabilità delimitata.
È lo stesso principio per cui un’azienda non assume una sola persona che fa contabilità, vendite, sviluppo e controllo qualità. La specializzazione riduce gli errori e rende il sistema verificabile.
C’è anche una ragione tecnica. Un agente con un compito ristretto può lavorare con istruzioni più precise e un contesto più pulito, mentre un agente che deve fare tutto si carica di istruzioni contraddittorie e perde affidabilità man mano che il compito si complica.
Il minimo privilegio come regola di sicurezza
Il principio che tiene insieme un sistema multi-agente sicuro si chiama minimo privilegio, ed è preso in prestito dalla sicurezza informatica, dove regola da decenni l’assegnazione dei permessi.
Ogni agente riceve accesso solo agli strumenti e ai dati strettamente necessari al suo compito. Il researcher legge fonti, ma non scrive sul gestionale. L’executor può aprire un ticket, ma non può cancellare un database. L’agente che interroga il sistema di gestione dei clienti non vede il sistema delle paghe.
La logica è difensiva. Se un agente viene compromesso o sbaglia, il danno resta confinato al perimetro dei suoi permessi. Un sistema dove ogni agente può fare tutto è un sistema dove un solo errore, o una sola compromissione, può fare qualsiasi danno.
Questo significa che l’accesso ai sistemi aziendali, dal CRM all’ERP, dalla gestione dei ticket alle pipeline di sviluppo e integrazione continua, va concesso in modo permissionato e puntuale per ogni agente. Non un’unica chiave che apre tutte le porte, ma un mazzo di chiavi tagliate sul ruolo, con ciascuna chiave che apre solo ciò che serve.
Il principio sembra elementare, eppure è la prima cosa che si tende a violare quando si ha fretta di mettere un sistema in produzione. Dare a un agente permessi ampi è più rapido che ritagliarli. Ed è anche il modo più sicuro per trasformare un piccolo errore in un grande danno.
L’applicazione pratica del principio richiede un lavoro di mappatura. Per ogni agente bisogna elencare cosa deve leggere, cosa deve scrivere e su quali sistemi, e poi negare tutto il resto per impostazione predefinita. È l’opposto dell’approccio comodo, che concede ampi permessi e li restringe solo dopo un incidente.
Questa mappatura è anche un esercizio di chiarezza organizzativa. Costringe a definire con precisione cosa fa ogni agente, e spesso rivela sovrapposizioni e ridondanze che, una volta esplicitate, si possono eliminare. Il minimo privilegio, oltre a proteggere, mette ordine.
Vale anche per gli strumenti esterni a cui gli agenti si collegano. Un agente che parla con un servizio di terze parti dovrebbe poter fare solo ciò che quel compito richiede, mai disporre di un accesso completo che, se dirottato, aprirebbe la porta a tutto il resto.
La memoria persistente che dà continuità
Un sistema multi-agente serio mantiene uno stato tra i compiti. Senza memoria persistente, ogni richiesta riparte da zero e gli agenti dimenticano il contesto del progetto o del cliente.
La memoria permette all’orchestratore di sapere cosa è già stato fatto, agli specialisti di non ripetere lavoro e al sistema nel suo insieme di accumulare conoscenza su un dossier che si protrae nel tempo. È la differenza tra una squadra che ogni mattina riparte ignara di cosa ha fatto il giorno prima e una che riprende il lavoro esattamente dove l’ha lasciato.
Per un’impresa, la continuità è ciò che trasforma un insieme di automazioni in un collaboratore. Un sistema che ricorda lo storico di un cliente può gestirne la pratica in modo coerente nel tempo, invece di trattarlo come uno sconosciuto a ogni interazione.
Il controllo umano sulle azioni che pesano
Nessun sistema multi-agente maturo lascia gli agenti liberi su tutto.
Il modello che si è affermato inserisce il controllo umano sui passaggi ad alto rischio: un pagamento oltre una soglia, una comunicazione verso l’esterno, una modifica irreversibile a dati di produzione. L’agente prepara l’azione, l’umano la approva. Sui passi a basso rischio l’agente procede da solo, senza interruzioni.
Trovare il punto giusto è un esercizio di disegno organizzativo, non di programmazione. Troppi controlli umani annullano il vantaggio dell’automazione, perché se una persona deve approvare ogni singolo passo tanto vale che lo faccia da sé. Troppo pochi espongono l’azienda ad azioni che nessuno ha vagliato, con il rischio di danni irreversibili.
La soglia tra ciò che l’agente decide da solo e ciò che richiede un’approvazione umana dipende dal settore, dai rischi e dalle regole. Non esiste una risposta universale, esiste una decisione da prendere consapevolmente per ogni processo.
MCP, A2A e perché l’integrazione conta più del modello
Gli agenti devono parlare con gli strumenti e tra di loro. Qui entrano i protocolli.
Il Model Context Protocol funziona come un adattatore universale: standardizza il modo in cui un agente si collega a strumenti, API e fonti di dati, evitando di reinventare ogni connessione da capo. Prima di uno standard, ogni integrazione tra un agente e uno strumento richiedeva un lavoro su misura, fragile e costoso da mantenere. Un protocollo comune trasforma quel lavoro in una connessione ripetibile.
Accanto a MCP si è diffuso un secondo protocollo, A2A, pensato per la comunicazione strutturata e la delega tra agenti autonomi. Se MCP collega l’agente agli strumenti, A2A collega gli agenti tra loro, permettendo all’orchestratore di delegare in modo ordinato e agli specialisti di scambiarsi risultati. Molti sistemi su larga scala usano entrambi: MCP per l’integrazione con strumenti e contesto, A2A per il coordinamento tra agenti.
È qui che si annida la lezione contraria all’intuizione. Il modello sottostante, quello che fa notizia nei comunicati, conta meno dell’integrazione che lo circonda.
Un modello eccellente collegato male produce un sistema mediocre. Un modello discreto integrato bene, con permessi puliti, memoria affidabile e protocolli solidi, produce un sistema che lavora. Il valore, in altre parole, si è spostato dal modello all’architettura, e questo cambia su cosa un’impresa dovrebbe concentrare le proprie risorse.
La conseguenza pratica è controintuitiva per chi insegue l’ultimo modello annunciato. Investire nell’integrazione, nei permessi, nella memoria e nella tracciabilità rende di più che cambiare modello a ogni nuova uscita. Il modello è un componente sostituibile, l’architettura è il patrimonio che resta.
Le imprese che lo hanno capito trattano la scelta del modello come una decisione reversibile, da rivedere quando conviene, e l’architettura del sistema come l’investimento stabile su cui costruire. È un ribaltamento di priorità rispetto al clamore che accompagna ogni nuovo modello di frontiera.
Un esempio concreto: la gestione di una richiesta complessa
Per capire come lavora un sistema multi-agente conviene seguirlo su un compito reale.
Arriva la richiesta di un cliente che segnala un problema su un ordine e chiede un rimborso parziale. L’orchestratore la riceve e la scompone. Manda il researcher a recuperare lo storico dell’ordine dal gestionale e le condizioni contrattuali applicabili. Il planner, con quelle informazioni, definisce i passi: verificare l’idoneità al rimborso, calcolarne l’importo, predisporre la comunicazione al cliente.
L’executor esegue i passi a basso rischio, recupera i dati e prepara la bozza di risposta. Ma il rimborso supera la soglia oltre la quale serve un’approvazione: qui il sistema si ferma e chiama un operatore umano, che vaglia e autorizza. L’agente di quality assurance, prima della chiusura, controlla che la risposta sia coerente con le condizioni recuperate e che non contenga errori.
Ogni passaggio resta a registro. Se in seguito il cliente contesta, l’azienda può ricostruire chi ha fatto cosa, su quali dati e con quale autorizzazione.
È un flusso ordinario, e proprio per questo istruttivo. Nessun agente fa tutto, ciascuno ha permessi limitati, l’umano interviene solo dove serve, e tutto lascia traccia. La somma di queste scelte, non la brillantezza del singolo modello, è ciò che rende il sistema affidabile.
Lo stesso flusso, affidato a un unico modello senza divisione di ruoli né permessi differenziati, sarebbe più rapido da costruire e molto più rischioso da gestire. Un solo errore di interpretazione potrebbe far partire un rimborso non dovuto, senza che nessuno se ne accorga prima dell’esecuzione. La struttura multi-agente è meno elegante e più lenta da progettare, ma è ciò che permette di dormire la notte.
Tracciabilità: la condizione che il protocollo non dà
Le imprese che hanno provato a portare MCP in produzione hanno scoperto un bisogno che la specifica di base non copre: la tracciabilità completa. Ogni chiamata, ogni payload di contesto, ogni risposta deve essere registrata, per ragioni di sicurezza, di debug e di conformità legale.
A questo si aggiungono altre esigenze che le aziende incontrano e che lo standard nudo non risolve: l’integrazione con i sistemi di autenticazione aziendali, il passaggio attraverso gateway che controllano il traffico, la portabilità delle configurazioni tra ambienti diversi.
Un audit log che ricostruisce cosa ha fatto ogni agente e perché non è un lusso. È la condizione per rispondere a un’autorità di controllo, per ricostruire un incidente, per dimostrare che il sistema rispetta gli obblighi del Regolamento UE 2024/1689 (AI Act). Senza tracciabilità, un sistema multi-agente è una scatola nera: funziona finché funziona, e quando qualcosa va storto nessuno sa dire cosa è successo.
Costruire queste competenze è il vero collo di bottiglia per le imprese italiane. AIPIA le affronta nei percorsi formativi sull’intelligenza artificiale e nella formazione aziendale, dove il disegno di sistemi multi-agente viene trattato come una disciplina che unisce sicurezza, organizzazione e tecnica. Per gli obblighi normativi resta il riferimento la guida operativa all’AI Act.
Un sistema multi-agente ben costruito non si distingue per la potenza del modello che usa. Si distingue per la disciplina con cui distribuisce permessi, traccia azioni e decide dove un umano deve ancora dire di sì.
