---
title: "Uno o più agenti AI: come si decide l'architettura di un sistema agentico"
url: https://zerofive.ai/blog/approfondimenti/sistemi-multi-agente-quanti-agenti-servono
canonical: https://zerofive.ai/blog/approfondimenti/sistemi-multi-agente-quanti-agenti-servono
language: it
published: 2026-10-26
updated: 2026-10-22
author: "ZeroFive.AI"
tags: agenti AI, sistemi multi-agente, harness, architettura AI, governance
abstract: "Uno o più agenti AI? Come si decide l'architettura di un sistema agentico: baseline a un agente, criteri per dividere, harness, misure e gate."
---

# Uno o più agenti AI: come si decide l'architettura di un sistema agentico

**In sintesi.** Quanti agenti mettere in un sistema AI è una decisione di progetto con conseguenze su costi, permessi e responsabilità, e va presa come le altre decisioni di investimento: con una baseline misurata e un'alternativa scartata per iscritto. Nel metodo ZeroFive.AI la baseline è un agente solo, con gli strumenti che il processo richiede e una pianificazione vincolata, provato su un set di casi reali. Si divide in più agenti dove cambia il modo in cui una parte del processo va governata, e solo se la versione divisa supera la baseline a parità di budget. In ogni configurazione la sequenza dei passi e le scritture sui sistemi restano al codice deterministico, e l'harness si progetta prima degli agenti.

Negli schemi che accompagnano le proposte di progetti agentici compare quasi sempre una squadra: un agente che pianifica, uno che cerca, uno che scrive, uno che rivede, a volte un supervisore che li coordina tutti. Il disegno convince perché ricalca un organigramma, e chi lo guarda in un comitato di direzione ci riconosce il modo in cui lavora un ufficio, con i suoi passaggi di mano e le sue revisioni.

Ci siamo passati anche noi, progettando gli agenti che usiamo internamente per gestire progetti e aggiornare il nostro software: la prima versione disegnata a tavolino aveva più agenti di quanti ne servissero, e il sistema è migliorato togliendone. Da quell'esperienza viene il modo in cui oggi affrontiamo la domanda con i clienti, che è lo stesso con cui trattiamo ogni altra scelta di un'iniziativa AI, dentro i [gate decisionali](/blog/ai-governance/agenti-ai-quattro-livelli-perimetro-delega) del nostro metodo.

## Il numero di agenti come decisione di progetto

Ogni agente in più è un componente con un modello da pagare a ogni chiamata, permessi da assegnare, un registro da leggere e una persona che ne risponde. Moltiplicare gli agenti moltiplica tutte queste voci, e il beneficio va dimostrato con l'aritmetica che si usa per qualunque spesa, cioè con un confronto contro l'opzione più semplice che risolve lo stesso problema.

Per questo la domanda su quanti agenti servano arriva per ultima, in cima a una scala di configurazioni che si sale un gradino alla volta, e solo quando il gradino sotto è stato misurato e non basta.

| Configurazione | Quando basta | Cosa aggiunge in costo e rischio |
|---|---|---|
| Regola deterministica o script | Input strutturato, regola nota | Solo la manutenzione della regola |
| Flusso fisso con il modello su alcuni passi | Sequenza nota, input vario in alcuni passaggi | Consumo del modello sui passi interpretativi |
| Un agente con pianificazione vincolata | Casi con varianti dentro un perimetro definito | Registro del piano, permessi sugli strumenti, un owner |
| Più agenti coordinati dal codice | Parti del processo da governare in modo diverso | Coordinamento, un owner e un perimetro per ogni agente, prove sulle interazioni |

Il primo gradino coincide con il G0: un caso d'uso entra in portafoglio solo dopo che l'[alternativa non-AI](/blog/strategia/value-case-alternativa-non-ai-scartata) è stata valutata e scartata per iscritto, e in una parte dei casi è proprio lei a vincere, con un costo che è una frazione di quello di un agente. Il secondo e il terzo gradino corrispondono ai livelli di autonomia che abbiamo descritto parlando di [skill e pianificazione agentica](/blog/ai-governance/skill-pianificazione-agentica). Il quarto è il tema di questo articolo, e ci si arriva con i numeri dei tre precedenti già in mano.

## La baseline a un agente

La baseline si costruisce con un set di valutazione interno, lo stesso strumento che usiamo per [scegliere il modello adatto al compito](/blog/approfondimenti/scegliere-modello-ai-per-il-compito): tra trenta e cinquanta casi presi dal processo reale, ciascuno con l'esito che un professionista esperto considererebbe corretto, compresi i casi in cui l'esito giusto è fermarsi perché l'informazione non c'è. Su quel set gira un agente solo, con gli strumenti di cui il processo ha bisogno e una pianificazione limitata alle skill dichiarate.

Dalla prova escono i numeri che accompagnano il progetto fino al presidio. La quota di esiti corretti dice se il sistema fa il lavoro, il costo per esito corretto dice quanto costa farlo bene, e pesa più del costo per esecuzione perché un'esecuzione sbagliata si paga due volte, la prima per produrla e la seconda per accorgersene. Accanto a questi c'è la quota di casi in cui l'agente si ferma quando dovrebbe fermarsi, che nei processi regolati vale quanto l'accuratezza.

Quando la baseline resta sotto la soglia, la causa va cercata prima di aggiungere componenti. Se il modello sbaglia anche con il contesto giusto davanti, il limite sta nella sua capacità, e si interviene cambiando modello o restringendo il compito. Se mancano strumenti o dati affidabili, il lavoro da fare sta negli strati bassi descritti nell'[architettura a otto strati](/blog/approfondimenti/azienda-agentica-otto-strati), e nessun agente aggiuntivo lo sostituisce. Solo quando parti diverse del processo richiedono contesti troppo ampi o troppo eterogenei per stare in una sola esecuzione la divisione entra tra le opzioni, e anche allora va motivata.

## I criteri per dividere un sistema

Il criterio che applichiamo nei progetti segue i confini della governance: un sistema si divide dove cambia qualcosa che va governato in modo diverso, e si tiene intero dove cambia soltanto il ruolo descritto nelle istruzioni del modello.

Il primo confine è la classe dei dati. Nel nostro metodo ogni dato appartiene a una classe (libera, interna o riservata) che stabilisce quali modelli possono leggerlo, e un processo che tocca dati riservati in un passaggio e informazioni pubbliche in un altro si progetta meglio con due agenti: quello che lavora sui dati riservati gira su un modello dentro il perimetro aziendale, l'altro può usare il modello più capace disponibile sul mercato. Con un agente solo tutto il contesto viaggerebbe verso lo stesso modello, e la scelta sarebbe tra pagare il modello interno anche per il lavoro banale o mandare fuori quello che non dovrebbe uscire.

Il secondo confine sono i permessi di scrittura. Un agente che legge documenti e uno che registra un ordine sul gestionale hanno profili di rischio diversi, e tenerli separati limita quello che un errore può toccare. La regola che ne deriva si dichiara in una riga: chi raccoglie e propone non scrive, e le scritture passano da un solo componente deterministico che applica le soglie di approvazione. È il confine che abbiamo descritto in [probabilistico e deterministico](/blog/approfondimenti/probabilistico-deterministico-architettura-ai), dove il modello interpreta e propone mentre il codice calcola e decide.

Il terzo confine è la responsabilità. Quando un processo attraversa due funzioni con due responsabili, per esempio l'istruttoria commerciale e la verifica del credito, due agenti permettono a ciascun [owner con nome e cognome](/blog/ai-governance/agenti-ai-owner-nominativo-produzione) di rispondere del proprio perimetro, di fermarlo e di leggerne il registro senza dipendere dall'altra funzione.

Il ruolo scritto nel prompt invece non giustifica una divisione. Un "redattore" e un "revisore" che usano lo stesso modello sugli stessi dati con gli stessi strumenti producono un secondo passaggio di inferenza sullo stesso ragionamento, e la revisione che serve davvero è deterministica dove si può scrivere una regola (un totale, un formato, una soglia) e umana dove la regola non si può scrivere.

## L'harness prima degli agenti

Nell'articolo sull'[azienda agentica](/blog/approfondimenti/azienda-agentica-otto-strati) abbiamo descritto le quattro famiglie di regole con cui scriviamo l'harness: permessi sugli strumenti a tre livelli, approvazione umana delle scritture, verifiche deterministiche, registro delle azioni. In un sistema a più agenti l'harness ha un compito in più, il coordinamento, e qui applichiamo alcune regole di progetto che valgono qualunque sia il framework scelto.

La sequenza dei passi è un piano che il sistema produce come dato prima di eseguirlo, e che resta nel registro insieme a quello che è successo davvero, così da poter confrontare l'intenzione con l'esecuzione. Il piano lo esegue il codice: è il codice ad avviare gli agenti, a passare i risultati da uno all'altro, ad applicare tempi massimi e condizioni di arresto, e nessun modello stabilisce da solo quando il lavoro è finito. Tra un passo e l'altro girano le verifiche deterministiche, perché un errore fermato dove nasce costa una frazione di quello che arriva in fondo alla catena con l'aria di una risposta sicura.

Gli agenti si scambiano oggetti con una struttura dichiarata, presi dall'[ontologia aziendale](/blog/approfondimenti/ontologia-aziendale-ai), invece di testo libero da reinterpretare. Un "cliente" passato da un agente all'altro ha gli stessi campi e lo stesso significato per entrambi, e questo elimina una famiglia intera di errori che nelle prove si presentano come incomprensioni tra componenti. Gli strumenti arrivano agli agenti attraverso server MCP che operano con i permessi reali della persona per cui il sistema lavora, mai con un'utenza tecnica dal perimetro illimitato.

L'harness è anche il luogo dove il progetto incontra la norma. Per i sistemi ad alto rischio il Regolamento UE 2024/1689 (AI Act) prevede la registrazione automatica degli eventi all'articolo 12 e la sorveglianza umana all'articolo 14, obblighi che per i sistemi dell'Allegato III, dopo il Digital Omnibus, si applicano dal 2 dicembre 2027. In un sistema a più agenti il registro deve permettere di ricostruire l'intera catena, chi ha proposto cosa, quale componente ha scritto e chi ha approvato, e non soltanto il comportamento di ciascun agente preso da solo. Un harness costruito così produce buona parte delle evidenze che servono anche per un sistema di gestione ISO/IEC 42001, e prepara l'organizzazione alle verifiche che restano compito dei legali e degli organismi di certificazione accreditati. Nei nostri percorsi di formazione è la disciplina che chiamiamo harness engineering, e la mettiamo prima di qualunque discussione su modelli e framework.

## Le misure prima del rilascio

Un sistema a più agenti va in produzione con un piccolo cruscotto di misure, calcolate sullo stesso set di valutazione della baseline e ripetute a ogni rilascio.

| Misura | Domanda a cui risponde | Gate in cui pesa |
|---|---|---|
| Costo per esito corretto rispetto alla baseline | La divisione ripaga quello che costa? | G2 |
| Contributo di ciascun agente | Togliendo quell'agente, l'esito sul set cambia? | G2 e ogni revisione |
| Astensione corretta | Il sistema si ferma quando l'informazione manca? | G3 |
| Tempo di ricostruzione di un'esecuzione | Quanto serve per spiegare a un auditor cosa è successo? | G3 e G4 |
| Tempo di annullamento | Quanto serve per riportare indietro le scritture di una catena? | G4 |
| Adozione misurata | Chi riceve il lavoro del sistema lo usa davvero? | G5 |

Le ultime tre righe sono quelle che mancano più spesso nei progetti che vediamo, perché nessuna dimostrazione le mette in mostra. Pesano però quanto le prime nella decisione di accendere il sistema, e una volta in esercizio vanno ricalcolate ogni volta che un fornitore aggiorna il modello, dato che un aggiornamento può cambiare il comportamento di un agente senza che nessuno abbia toccato il codice.

## I gate per un sistema a più agenti

I sei gate del metodo valgono per qualunque iniziativa AI. Per un sistema a più agenti ciascuno porta un criterio specifico, non compensabile come gli altri.

| Gate | Criterio per un sistema a più agenti |
|---|---|
| G0 Legittimità | Alternativa non-AI e versione a un agente valutate e scartate per iscritto |
| G1 Prontezza | Dati classificati e un sistema proprietario per ogni dato che gli agenti leggono |
| G2 Validazione | Ipotesi dichiarata prima della prova: la versione divisa supera la baseline a parità di budget |
| G3 Autorizzazione | Un perimetro di delega per ogni agente, coerente con la classe di rischio del caso d'uso |
| G4 Scala | Un owner per ogni agente, un registro unico della catena, annullamento provato |
| G5 Presidio | Misure ricalcolate a ogni aggiornamento dei modelli e adozione misurata sul campo |

Il G2 è il gate in cui un'architettura a più agenti viene più spesso ridimensionata, ed è un esito utile quanto un via libera, perché arriva prima che l'azienda abbia pagato l'integrazione con i sistemi reali. La validazione si fa con prototipi rapidi su dati reali nella unit [protot.ai](https://protot.ai), con l'ipotesi scritta prima di conoscere il risultato. Il perimetro di delega del G3 si dichiara agente per agente con i [livelli AI-assisted, AI-first e AI-native](/blog/strategia/ai-assisted-ai-first-ai-native-livelli-delega), e due agenti dello stesso sistema possono stare legittimamente a livelli diversi.

## Gli errori di progettazione più frequenti

L'errore più comune è disegnare il sistema a partire dall'organigramma, con un agente per ogni figura professionale coinvolta nel processo. Il risultato somiglia all'ufficio che si vuole assistere e si comporta come un agente solo che parla con se stesso, al costo di quattro o cinque.

Quasi altrettanto frequente è distribuire le scritture: ogni agente aggiorna i sistemi che tocca, e i conflitti tra due versioni dello stesso record si scoprono alla fine, quando la catena ha già prodotto i suoi effetti. Accentrare le scritture in un componente deterministico costa poco in fase di progetto e moltissimo da aggiungere dopo.

C'è poi l'architettura scelta dal framework o dalla demo del fornitore, che arriva con un numero di agenti già deciso da chi l'ha costruita per mostrare il prodotto. Un'azienda che parte da lì si trova a giustificare a posteriori una struttura che nessuno ha misurato, mentre chi parte dalla baseline sceglie il framework dopo, sapendo cosa gli chiede.

Da ultimo ci sono i sistemi accesi senza un inventario. Ai fini del registro e della responsabilità ogni agente conta come un sistema AI, e un sistema da cinque agenti significa cinque voci nell'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), con cinque owner, cinque perimetri e un registro che li tiene insieme.

## Da dove partire

Il lavoro comincia dalla baseline: un processo, un set di casi reali, un agente solo e i suoi numeri. Con quei numeri la decisione su quanti agenti servano diventa una decisione documentata, che si può presentare a un comitato rischi e difendere davanti a un auditor, e spesso si scopre che il sistema giusto è più piccolo di quello disegnato all'inizio.

Il quadro dei livelli e del perimetro di delega è in [quattro livelli e un perimetro](/blog/ai-governance/agenti-ai-quattro-livelli-perimetro-delega), la mappa completa dello stack è nell'[azienda agentica in otto strati](/blog/approfondimenti/azienda-agentica-otto-strati), e il servizio con cui progettiamo e portiamo in esercizio gli agenti è descritto nella pagina [AI Agents](/servizi/ai-agents). Per misurare a che punto è la vostra organizzazione prima di accendere il primo agente potete [avviare un AI Rating](/avvia-ai-rating) o [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive).