Architetture multiagente: perché l'infrastruttura conta più del modello

Un agente risponde. Una squadra di agenti lavora. In mezzo a queste due frasi c'è il passaggio più importante che l'AI aziendale sta compiendo in questi mesi: dal chatbot al processo.

Si chiamano architetture multiagente: sistemi in cui più agenti specializzati si coordinano per completare un lavoro, ognuno con il proprio ruolo, la propria conoscenza e le proprie regole. Non è un tema da laboratorio. Secondo Gartner, le richieste delle aziende sui sistemi multiagente sono cresciute del 1.445% in poco più di un anno, e la stessa Gartner avverte che oltre il 40% dei progetti di AI agentica verrà cancellato entro il 2027 per costi fuori controllo e valore poco chiaro ("Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027", Gartner, https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027).

I due numeri insieme raccontano tutto: la domanda esplode, ma la maggior parte dei progetti fallisce. E fallisce quasi sempre per lo stesso motivo. Non per il modello. Per l'assenza di infrastruttura.

Cosa sono le architetture multiagente, senza gergo

Immaginate un ufficio. C'è chi accoglie le richieste, chi conosce i listini, chi verifica le norme, chi firma. Nessuno di loro, da solo, "è" l'ufficio: l'ufficio è l'organizzazione che li tiene insieme. Le architetture multiagente applicano lo stesso principio agli agenti AI. La letteratura tecnica ha dato nomi ai pattern ricorrenti: il supervisore che riceve la richiesta e la smista allo specialista giusto, la catena in cui ogni agente lavora sull'output del precedente, il loop agentico in cui un agente esegue, valuta il risultato, corregge e ricomincia. Anche i laboratori che sviluppano i modelli usano questi schemi per i propri prodotti: Anthropic ha raccontato come il suo sistema di ricerca sia costruito proprio su un orchestratore che coordina sotto-agenti specializzati ("How we built our multi-agent research system", Anthropic, https://www.anthropic.com/engineering/multi-agent-research-system).

La differenza, per un'azienda, è tra comprare un'intelligenza e organizzare una squadra. E una squadra si può disegnare.

Le tre architetture che si costruiscono su AIsuru

Su AIsuru le architetture multiagente si costruiscono senza scrivere codice. Tre tipologie, in ordine di complessità.

1. Board of Experts: la chat di gruppo con gli agenti

Si crea un agente "stanza", si invitano dentro gli esperti già costruiti, e la stanza sceglie da sola quale esperto deve rispondere a ogni domanda. La può costruire chiunque, in pochi minuti.

Qualche esempio concreto. Uno sportello clienti unico che smista tra l'esperto di prodotto, l'amministrazione e l'assistenza tecnica: il cliente fa una domanda sola, la stanza capisce se riguarda una fattura o un'installazione. Un comitato interno per le policy aziendali, dove convivono l'esperto HR, quello legale e quello della sicurezza: il dipendente chiede "posso lavorare dall'estero per due settimane?" e risponde chi deve rispondere. Un tutor formativo che coordina i docenti digitali delle diverse materie di un corso: lo studente parla con un solo interlocutore, ma dietro lavora il docente giusto per ogni argomento. Un ufficio gare virtuale in cui l'esperto tecnico, quello economico e quello legale contribuiscono ciascuno alla propria sezione del capitolato.

Il punto non è la spettacolarità: è che ogni esperto mantiene la propria conoscenza separata, il proprio tono e le proprie regole, e la stanza li governa.

2. Agente che chiama agente: la conoscenza che nessun umano interroga

Guida all'uso del connettore MCP «Aisuru MCP Server» su AIsuru.

Tramite il server MCP di AIsuru, un utente più esperto può descrivere nel prompt le variabili di configurazione di un altro agente e far sì che i due si parlino: uno diventa la fonte di conoscenza dell'altro.

Perché farlo, invece di mettere tutta la conoscenza in un agente solo? Per la governance. Ci sono conoscenze che non devono mai essere esposte direttamente a un umano, ma solo a un'altra AI con regole più restrittive. Il listino riservato che l'agente commerciale pubblico consulta per costruire una proposta, senza che nessun visitatore possa mai interrogarlo direttamente. L'archivio delle procedure interne che risponde solo all'agente qualità, con il vincolo di citare sempre la revisione del documento. La conoscenza "madre" mantenuta in una sola lingua, che alimenta gli agenti clienti in tutte le altre: si aggiorna un punto solo, si distribuisce ovunque. Il fascicolo tecnico completo che l'agente di primo livello può consultare solo per estratti, mentre la versione integrale resta dietro una regola.

È la stessa logica dei permessi nei sistemi informativi, applicata alla conoscenza: non tutto ciò che serve alla risposta deve essere leggibile da chi fa la domanda.

3. Agenti come server MCP: il loop agentico con le regole

La terza architettura è quella che apre i sistemi davvero complessi. Un agente AIsuru può essere esposto come server MCP: a quel punto può essere usato come strumento da altri agenti, e può a sua volta coordinare altri agenti. Incluso se stesso.

Qui entra in gioco il loop agentico: esegui, valuta, correggi, ricomincia. Un agente che rilegge le proprie conversazioni, individua le domande rimaste senza risposta e propone i contenuti mancanti. Un agente collaudatore che ogni settimana interroga gli altri agenti del tenant con una batteria di domande di prova e segnala dove le risposte peggiorano. Un coordinatore che riceve un obiettivo ("prepara il report mensile sui clienti del Nord Est"), usa gli agenti della squadra come strumenti, assembla il risultato e lo consegna. Un revisore che confronta le risposte date con la documentazione ufficiale e propone correzioni al prompt degli agenti che scivolano.

La letteratura chiama questa famiglia di comportamenti self-improvement: sistemi che migliorano contenuti, funzioni e istruzioni sulla base dei propri risultati. Ed è esattamente il punto in cui la domanda di governance smette di essere teorica: un agente che può modificare altri agenti è potentissimo e va incatenato alle regole. Su AIsuru il loop avviene dentro l'infrastruttura di sempre: le credenziali restano in cassaforte, ogni passaggio è tracciato, le modifiche sono proposte e l'ultima parola resta a una persona.

Perché l'infrastruttura conta più del modello (anche con i modelli open)

C'è un equivoco che condanna molti progetti: credere che la precisione delle risposte dipenda dal modello. Il modello conta, certo. Ma in un sistema multiagente ben costruito la precisione nasce soprattutto da ciò che sta intorno al modello.

Nasce dalla conoscenza curata: l'agente risponde su documenti approvati e versionati, non su tutto ciò che ha letto internet. Nasce dalle funzioni deterministiche: il prezzo lo dice il gestionale, la disponibilità la dice il magazzino, la data la dice il calendario; il modello orchestra la frase, non inventa il numero. Nasce dai guardrail: perimetri di argomento, tono, formato, che valgono per l'agente e vengono ereditati da tutta la squadra. Nasce dal routing: il compito semplice va al modello piccolo ed economico, quello complesso al modello grande, e la scelta è una regola d'infrastruttura, non un caso. Nasce dal collaudo continuo: l'agente che testa gli altri agenti è manutenzione preventiva della qualità. E nasce dalla tracciabilità: quando ogni passaggio è registrato, l'errore si trova, si spiega e si corregge, invece di ripetersi in silenzio.

Questa è la ragione per cui un'infrastruttura ben fatta rende precisi anche i modelli open. Per molte organizzazioni i modelli aperti sono una scelta strategica: controllo dei costi, esecuzione in Europa o in casa, sovranità sul dato. Il loro limite storico, una minore brillantezza "a nudo", si compensa proprio con l'architettura: conoscenza giusta nel contesto giusto, dati dai sistemi e non dalla memoria del modello, compiti spezzati in passi piccoli che anche un modello medio esegue bene, verifica a valle. In un'architettura multiagente governata, il modello diventa un componente sostituibile: si cambia quando ne esce uno migliore o più conveniente, senza rifare nulla. Il modello passa. L'infrastruttura resta.

E i numeri dicono che la differenza si misura: le organizzazioni che affiancano agli agenti pratiche strutturate di governance e valutazione hanno una probabilità fino a 12 volte maggiore di portare valore reale ("State of AI Agents", Databricks, https://www.databricks.com/resources/ebook/state-of-ai-agents). La governance non è il freno del progetto: è il motivo per cui il progetto arriva in produzione.

ISO/IEC 42001: perché una certificazione cambia la scelta del fornitore

Qui arriviamo al punto che riguarda noi. Memori è certificata ISO/IEC 42001, il primo standard internazionale per i sistemi di gestione dell'intelligenza artificiale ("ISO/IEC 42001:2023, Artificial intelligence management system", ISO, https://www.iso.org/standard/81230.html). Non è un badge da collezionare: è un sistema di gestione verificato da un ente terzo, che copre l'intero ciclo di vita dell'AI, dalla valutazione dei rischi e degli impatti alla definizione dei ruoli, dal monitoraggio al miglioramento continuo. E come ogni certificazione vera, si supera di nuovo ogni anno.

Perché conta proprio per le architetture multiagente? Perché ogni agente in più è superficie in più: più conoscenze da presidiare, più connessioni verso i sistemi, più punti in cui qualcosa può andare storto. Un fornitore può raccontare di avere processi per gestire tutto questo; un fornitore certificato ISO/IEC 42001 lo ha dimostrato a un auditor esterno, con evidenze, e continuerà a dimostrarlo. Quando poi l'architettura include il loop agentico, cioè agenti che propongono modifiche ad altri agenti, la differenza tra "fidati" e "verificato" diventa la differenza tra un rischio e un sistema.

Nel nostro caso la ISO/IEC 42001 non è sola: si somma alle certificazioni sulla sicurezza delle informazioni e sul cloud (ISO/IEC 27001, 27017, 27018), alla ISO 9001 sulla qualità e alla conformità NIS2. È una combinazione che pochissimi fornitori di piattaforme agentiche possono mettere sul tavolo, ed è ciò che ci fa dire, con argomenti e non con slogan, che per costruire architetture multiagente governate siamo il partner di riferimento: perché la governance da noi non è un modulo aggiuntivo né una promessa commerciale, è il modo in cui la piattaforma è fatta e il modo in cui l'azienda che la produce è gestita, certificato da terzi. Chi sceglie il fornitore di un sistema multiagente non sta comprando risposte brillanti: sta affidando a qualcuno le chiavi dei propri processi. E le chiavi si affidano a chi può dimostrare come le custodisce.

Da dove cominciare

Il percorso sensato non parte dall'architettura più complessa. Parte da un processo vero: si scelgono due o tre esperti che coprono domande reali, si mettono in una Board of Experts, si misura. Poi si separa la conoscenza riservata con un agente che solo le AI possono interrogare. E quando la squadra funziona, si aggiunge il supervisore che la mantiene in forma. A ogni passo, le stesse regole: conoscenza approvata, credenziali in cassaforte, tutto tracciato, l'ultima parola a una persona.

Le chat AI si usano. Le architetture si progettano. E si progettano meglio su un'infrastruttura nata per connettere e per governare, non solo per chiacchierare.

Fonti citate nell'articolo