Architetture multi-agente: quale scegliere, e quali non sono architetture

Quando un solo agente non basta, la risposta abituale è metterne più d’uno e farli collaborare - ciascuno specializzato in un’area, come si divide il lavoro in una squadra di persone. È spesso la scelta giusta, e quasi sempre viene presentata male.

Gli elenchi che si trovano in giro mettono in fila otto o nove «architetture multi-agente» come se fossero otto alternative fra cui scegliere. Non lo sono. Ci sono quattro topologie, cioè quattro modi in cui gli agenti si dispongono l’uno rispetto all’altro, e poi ci sono controlli che si sovrappongono a qualunque topologia. Metterli sulla stessa riga è un errore di categoria, e chi ci casca finisce per scegliere fra cose che non si escludono a vicenda.

Questo articolo dà per acquisito che cosa sia un agente e di cosa sia fatto: se serve, sta in Architettura di un agente AI. Qui si parla solo di che cosa succede quando gli agenti diventano più di uno.

Le quattro topologie

Gerarchica, a rete, sequenziale, parallela. Sono l’unica scelta davvero mutuamente esclusiva del progetto.

Una topologia dice chi parla con chi. È la decisione strutturale, quella che si cambia con difficoltà dopo, e ce ne sono quattro.

Architettura gerarchica. Un agente supervisore coordina agenti specializzati e ne compone i risultati. Il caso tipico è l’istruttoria: una richiesta di analisi creditizia in cui il supervisore delega a un agente per lo storico interno, a uno per le valutazioni esterne, a uno per la corrispondenza con il cliente, e alla fine scrive un unico documento. Ordine e responsabilità chiare; il supervisore è anche il collo di bottiglia e il punto in cui l’intero sistema si ferma se sbaglia.

Architettura a rete. Agenti paritari collaborano senza un coordinatore. Una catena di fornitura globale in cui gli agenti dei magazzini, dei trasporti e dei punti vendita dialogano fra loro per ottimizzare le scorte. Nessun punto singolo di rottura, e adattamento continuo; in cambio la sincronizzazione si complica al crescere del numero e i comportamenti diventano difficili da ricostruire quando qualcosa va storto.

Architettura sequenziale. Ogni agente lavora su ciò che ha prodotto il precedente. In un’agenzia: uno recupera i dati delle campagne, un altro calcola il ritorno, un terzo scrive il documento finale. Tracciabile e facile da capire; fragile, perché basta un anello che sbaglia e la catena si ferma.

Architettura parallela. Più agenti lavorano contemporaneamente su compiti indipendenti, e i risultati si aggregano alla fine. Serve quando il problema si divide davvero e la velocità conta. Il costo si sposta sull’aggregazione: mettere insieme esiti che non si sono parlati produce con facilità incoerenze.

Due cose che vengono chiamate architetture e non lo sono

L’intervento umano e la trasformazione dei dati compaiono negli elenchi come alternative. La prima è un controllo, la seconda un caso particolare del sequenziale.

Qui sta l’errore che rende inutilizzabili quasi tutti gli elenchi in circolazione.

L’intervento umano non è una topologia: è un controllo. Negli elenchi compare come «architettura con intervento umano», accanto a gerarchica e a rete, come se si dovesse scegliere l’una o l’altra. Ma un medico che convalida una terapia proposta da un agente, o un istruttore che approva una delibera di fido, non cambiano il modo in cui gli agenti si dispongono: aggiungono un punto in cui il sistema si ferma e attende. Quel punto si può mettere dentro una gerarchia, dentro una rete, dentro una sequenza. È il pattern che in inglese si chiama human in the loop, sigla HITL, e va deciso separatamente dalla topologia - perché risponde a una domanda diversa: non «chi parla con chi», ma «dove serve che qualcuno possa bloccare».

La trasformazione dei dati non è una topologia: è un compito. Un agente che normalizza o arricchisce i dati prima che altri li usino - che etichetta il sentimento nelle recensioni, o che rende anonimi i dati personali prima dell’analisi - non definisce una struttura: occupa un posto in una sequenza. È un caso particolare del sequenziale, e chiamarlo architettura fa credere che si possa sceglierlo invece della gerarchia, il che non vuol dire niente.

Distinguere queste due cose dal resto è metà della decisione, perché elimina due false alternative e lascia una scelta pulita fra quattro topologie.

I controlli che si sovrappongono

Obiettivo, ripetizione, approvazione umana, instradamento. Si aggiungono a una topologia, non la sostituiscono.

Oltre alla topologia si sceglie quali controlli attivare. Sono indipendenti fra loro e indipendenti dalla forma.

Sono quattro, e i primi due rispondono alla stessa domanda - quando ci si ferma - in due modi diversi.

Approvazione umana (HITL). Il sistema si ferma e attende una persona che ha l’autorità di bloccare. Va messo dove l’errore ha un costo che non si recupera: una terapia, una delibera, una spedizione. Il prezzo è la latenza - il sistema va alla velocità di chi approva - e la scalabilità, che ora dipende da quante persone ci sono.

Obiettivo (goal) e ripetizione (loop) vengono spesso confusi, e sono due cose diverse. La differenza non sta nel numero di iterazioni: sta in come si riconosce di aver finito.

Un obiettivo è un compito da portare a termine: «costruisci un’interfaccia di programmazione per questa applicazione». Può richiedere molti passaggi, ma non è per sua natura iterativo: si conclude quando la cosa esiste e funziona. Il criterio di uscita è una definizione di fatto - quali funzioni deve esporre, quali prove deve superare - e non è un numero.

Una ripetizione è un lavoro ricorsivo su una metrica misurabile: «porta il tempo di accesso ai dati da due secondi a mezzo secondo». Qui il criterio di uscita è una soglia numerica, e ogni iterazione deve poterla misurare. Senza una metrica deterministica non c’è ripetizione: c’è un agente che rifà la stessa cosa sperando che venga meglio.

I due si compongono - un obiettivo si può perseguire con una ripetizione al suo interno - ma vanno dichiarati separatamente, perché falliscono in modi diversi. Un obiettivo senza definizione di fatto produce un sistema che si ferma troppo presto o non si ferma mai, e in entrambi i casi nessuno sa dire se ha funzionato. Una ripetizione senza metrica misurabile produce cicli che non terminano, con un costo di calcolo che cresce senza che nessuno se ne accorga finché non arriva la fattura.

La domanda da farsi prima di accendere il sistema è quindi doppia: che cosa vuol dire aver finito? e, se la risposta è un numero, chi lo misura e ogni quanto?

Instradamento (router). Un agente classifica le richieste in arrivo e le manda allo specialista giusto. Serve quando le richieste sono eterogenee e mandarle tutte a tutti sarebbe uno spreco. Aggiunge un passaggio e un punto in cui la classificazione può sbagliare, mandando la richiesta nel posto sbagliato con sicurezza.

Negli elenchi originali, loop e router compaiono come «altri pattern», in coda e senza spiegazione, e l’obiettivo non compare affatto - mentre nella pratica sono le decisioni che si prendono più spesso.

Come si sceglie davvero

Tre domande in ordine determinano la topologia. I controlli si decidono dopo, e separatamente.

La letteratura su questo punto tende a produrre un elenco di domande - quali sono gli obiettivi, quali i vincoli, quali le risorse, come evolverà - che è vero e inservibile, perché non dice in che ordine rispondere né cosa fare della risposta.

La topologia si determina con tre domande in sequenza. La prima che dà «sì» decide.

#	Domanda	Se sì
1	I passi dipendono l’uno dall’altro, cioè ognuno usa il risultato del precedente?	Sequenziale
2	I compiti sono indipendenti e la velocità conta?	Parallela
3	Serve una visione d’insieme, o una responsabilità chiara su chi decide?	Gerarchica
-	Nessuna delle tre	A rete

Funziona perché le tre domande sono in ordine di vincolo: una dipendenza fra i passi non si aggira, l’indipendenza è un’occasione da cogliere, la responsabilità è un requisito organizzativo. La rete resta la scelta residua, ed è giusto che sia così: è la più costosa da governare e conviene sceglierla quando le altre non vanno bene, non per prima.

Poi si decidono i controlli, e sono tre domande indipendenti:

• che cosa vuol dire aver finito? Se è una condizione da soddisfare → obiettivo, con la definizione di fatto scritta prima; se è un numero da raggiungere → ripetizione, con la metrica e chi la misura scritti prima;
• l’errore ha un costo che non si recupera? → approvazione umana in quel punto;
• le richieste in arrivo sono eterogenee? → instradamento.

Quasi tutti i sistemi che funzionano sono ibridi: una gerarchia con un’approvazione umana nel punto critico, o una rete con un instradatore all’ingresso. L’ibrido è la norma: si ottiene componendo, non scegliendo una nona architettura dall’elenco.

I sub-agenti: la gerarchia che si monta da sola

Un agente può creare altri agenti per il compito in corso. La decisione è del modello; la creazione resta una chiamata di strumento, e la esegue l’harness.

Le quattro topologie condividono un presupposto rimasto implicito: gli agenti esistono prima del lavoro. Qualcuno ha progettato il supervisore e gli specialisti, li ha collegati, e la struttura sta in piedi anche quando il sistema è spento. L’evoluzione recente rompe il presupposto: l’agente che, davanti a un compito divisibile, crea da sé gli agenti che gli servono - i sub-agenti - e a lavoro finito li lascia andare. La gerarchia smette di essere un disegno preparato prima e diventa un evento dell’esecuzione.

Il meccanismo merita precisione, perché il racconto di marketing lo confonde. Un modello di linguaggio non può avviare niente: produce testo e richieste. La delega fra agenti - così chiameremo la creazione di un sub-agente - è quindi una chiamata di strumento come le altre: fra gli strumenti dichiarati ce n’è uno che dice «avvia un agente con questo incarico»; il modello lo chiede coi suoi argomenti - l’incarico, appunto - e l’harness lo esegue, aprendo una nuova conversazione col modello: istruzioni proprie, contesto proprio, strumenti propri, di norma più ristretti di quelli del genitore. Quando il sub-agente finisce, al genitore torna il risultato e non il percorso. È la regola fissata dall’articolo sull’architettura che si applica a se stessa: il modello decide, l’orchestrazione esegue - anche quando ciò che si esegue è la nascita di un altro agente.

Negli harness che documentano il meccanismo si vede tutto questo per esteso. In Claude Code un sub-agente si dichiara in un file con un nome e una descrizione - come uno strumento, come una skill - e il modello vi delega quando il compito corrisponde alla descrizione; il sub-agente lavora in una finestra di contesto separata, con permessi propri, e restituisce alla conversazione principale soltanto il sommario del lavoro.

Il guadagno vero sta nel contesto, prima ancora che nella velocità. La finestra di un agente solo si riempie, ed è la scelta che l’articolo sull’harness chiama la più sottovalutata. I sub-agenti la moltiplicano: ciascuno esplora nella propria, in parallelo, e riporta conclusioni invece di letture. Anthropic, nel resoconto di ingegneria sul proprio sistema di ricerca multi-agente, descrive esattamente questo: un agente guida che scompone la domanda e delega a sub-agenti paralleli, ognuno con la propria finestra, che fanno da filtri e riportano l’essenziale.

La scala a cui il meccanismo è arrivato la mostra Kimi K3 di Moonshot, con il suo «Agent Swarm»: un orchestratore che dirige fino a centinaia di sub-agenti e migliaia di passi paralleli, ciascun sub-agente col proprio taccuino di contesto. Il tratto più interessante è dove sta l’apprendimento: col metodo che chiamano PARL (apprendimento per rinforzo ad agenti paralleli), viene addestrato solo l’orchestratore - a decidere quando delegare, a chi e quanto - mentre i sub-agenti restano modelli normali. La documentazione pubblica non descrive il meccanismo di avvio; che sia una chiamata di strumento, come negli harness che lo documentano, è un’inferenza, e va detta come tale. Il punto di merito però non cambia: quando si legge che il modello crea agenti «in autonomia», l’autonomia sta nella decisione di delegare, che nessun programmatore ha scritto; l’esecuzione resta dell’harness.

Il protocollo del colloquio: dentro l’harness e fra organizzazioni

Resta da dire come si parlano, perché qui la parola «protocollo» va maneggiata con cura. Dentro un harness, fra l’orchestratore e i suoi sub-agenti, un protocollo pubblico non serve e non esiste: il colloquio è fatto di due soli scambi, mediati dal contesto. All’andata l’incarico: l’argomento della chiamata di delega diventa il contesto iniziale del sub-agente, che non vede la conversazione del genitore - del mondo sa solo ciò che l’incarico gli dice. Al ritorno il sommario: il testo con cui il sub-agente chiude entra nel contesto dell’orchestratore come l’esito di qualunque altro strumento. Fra i due momenti, di norma, silenzio: il genitore non assiste ai passi del figlio, e il figlio non fa domande. Alcuni harness ammettono di più - in Claude Code l’orchestratore può riprendere un sub-agente concluso e continuare il colloquio nel contesto che quello conserva, e un sub-agente lasciato in sottofondo riappare con una notifica - ma sono comodità del singolo harness, non un protocollo: il canale resta il contesto di qualcuno.

Quanto contesto riceva il sub-agente, però, non lo fissa nessuno standard: è una scelta di progetto, e gli harness documentano un ventaglio che va da un estremo all’altro. Il caso normale è il contesto fresco: il solo incarico, più le istruzioni e le skill che la dichiarazione del sub-agente precarica. All’estremo opposto sta la biforcazione (in inglese fork): il sub-agente eredita l’intera conversazione del genitore fino a quel punto e ne prosegue una copia - Claude Code documenta entrambe le forme. In mezzo, tutte le gradazioni che l’orchestratore compone scrivendo l’incarico: più contesto porta più coerenza e più costo, meno contesto porta più indipendenza e più rischio di malintesi.

Su dove mettersi in questo ventaglio le posizioni pubblicate sono due, e conviene leggerle insieme. Cognition, la casa dell’agente Devin, sconsiglia proprio i sub-agenti paralleli a contesto parziale: ogni azione porta con sé decisioni implicite, e decisioni prese su assunzioni diverse confliggono - l’esempio del loro articolo è un gioco montato da due sub-agenti che hanno scelto due stili incompatibili; da cui i due principi, «condividi il contesto» e «condividi le tracce intere, non i singoli messaggi». Anthropic raccomanda invece i sub-agenti a finestra pulita per la ricerca e l’analisi parallelizzabili, dove ognuno esplora per decine di migliaia di token e ne riporta mille o duemila. Le due posizioni sembrano opposte e in realtà si dividono i compiti. Dove i sub-agenti leggono - cercano, analizzano, verificano - il contesto fresco paga, perché le conclusioni si sommano senza confliggere. Dove i sub-agenti scrivono o decidono - producono parti di uno stesso artefatto - le decisioni implicite confliggono, e servono o il contesto condiviso o un agente solo. È l’indicazione da tenere davanti quando si decide se dichiarare lo strumento di delega, e con quale ampiezza.

Le skill entrano in questo colloquio da due porte, entrambe documentate. La prima: l’orchestratore può consegnare al sub-agente, insieme all’incarico, le skill che gli serviranno - in Claude Code la dichiarazione di un sub-agente può elencare le skill da precaricare nel suo contesto, così il compito arriva già accompagnato dal come farlo. La seconda è l’inverso, e sta nella guida dello standard delle skill: una skill complessa può essere eseguita da un sub-agente dedicato, che riceve le istruzioni, lavora nella propria finestra e riporta il sommario, invece di riversare l’intera procedura nella conversazione principale. In entrambi i casi la skill non è un interlocutore: è testo che si legge. Nel colloquio fra agenti parla sempre e solo il contesto.

Tutto questo vale finché orchestratore e sub-agenti abitano lo stesso harness, che è il caso di gran lunga più comune: gli sciami come quello di Kimi vivono dentro un solo sistema. Quando invece l’agente da ingaggiare sta in un’altra organizzazione, il colloquio deve attraversare la rete, e lì un protocollo pubblico serve davvero: è l’A2A dell’articolo sui protocolli, con la carta dell’agente per presentarsi, i compiti con i loro stati per lavorare nel tempo, gli artefatti per consegnare i risultati.

	Dentro l’harness	Fra organizzazioni (A2A)
Chi si parla	L’orchestratore e i suoi sub-agenti	Agenti di produttori o aziende diverse
L’andata	L’incarico, argomento della chiamata di delega	Il compito, con stati e richieste intermedie
Il ritorno	Il sommario, nel contesto del genitore	Gli artefatti, o uno stato finale
Il canale	Il contesto: testo che entra nelle finestre	La rete: richieste, streaming, notifiche
La fiducia	Implicita: stesso sistema, stessi permessi	Da costruire: carta dell’agente, credenziali

La corrispondenza si vede a occhio - l’incarico diventa il compito, il sommario diventa l’artefatto - ma le differenze pesano: dentro l’harness la fiducia è implicita e il canale è il contesto; fra organizzazioni la fiducia va costruita e il canale è una connessione che può cadere e riprendere. E l’avvertenza dell’articolo sui protocolli vale anche qui: A2A è uno standard designato, con governo e specifica, ma i casi di produzione documentati ancora mancano - oggi la delega fra agenti che funziona davvero è quella interna.

Nella classificazione di questo articolo, i sub-agenti non sono una quinta topologia: sono l’architettura gerarchica montata al momento dell’esecuzione invece che sul tavolo da disegno. Le tre domande della sezione precedente restano quelle; cambia chi risponde. In fase di progetto si decide se l’agente può delegare - lo strumento di creazione c’è o non c’è, con quale profondità e con quale dotazione - e il modello decide quando. E i controlli pesano il doppio: senza un limite di profondità, un sub-agente che può creare sub-agenti è una gerarchia che non smette di assumere; senza dotazione il costo scappa, perché un sistema multi-agente consuma, nella misura di Anthropic, circa quindici volte i token di una conversazione semplice. Il resto del conto - capire che cosa è successo, e quanto costa il coordinamento - sta nella sezione che segue.

Quello che l’elenco non dice

Il costo di ricostruire cosa è successo cresce con il numero di agenti, e non compare in nessuna tabella di confronto.

I confronti fra architetture elencano scalabilità, resilienza, latenza, complessità di realizzazione. Manca la voce che nella pratica decide più delle altre: quanto costa capire cosa è andato storto. La chiamo costo di ricostruzione, perché è una spesa vera anche se non compare in nessun preventivo.

In una sequenza è facile: si guarda a che anello si è rotto. In una gerarchia è ancora gestibile, perché il supervisore ha una visione d’insieme e i suoi registri raccontano la storia. In una rete diventa difficile, e la difficoltà non cresce in proporzione al numero di agenti ma alle possibili interazioni fra loro: un comportamento sbagliato può non stare in nessun agente ma nel modo in cui due si sono parlati.

Da questo discende una regola pratica che vale più di molte tabelle: la topologia più semplice che risolve il problema è quasi sempre quella giusta, e la rete si sceglie quando le altre tre non vanno bene, non perché è la più moderna. Ogni agente aggiunto moltiplica i modi in cui il sistema può fallire, non le cose che sa fare.

L’altra voce assente è il costo di comunicazione. Gli agenti che si parlano si scambiano contesto, e ogni scambio è consumo di calcolo. In una rete con dieci agenti che dialogano, la parte di spesa che finisce nel coordinamento può superare quella che finisce nel lavoro utile.

I concetti che questo articolo introduce

Quattordici voci nuove. I concetti dell’articolo precedente non sono ripetuti: la mappa completa nasce dall’unione.

Fonti

• Anthropic, How we built our multi-agent research system (giugno 2025) - il pattern coordinatore-esecutore, i sub-agenti in parallelo ciascuno con la propria finestra di contesto, e le misure di consumo: circa quattro volte i token di una conversazione per un agente, circa quindici per un sistema multi-agente.
• Claude Code, Subagents - un esempio documentato del meccanismo di delega: il sub-agente si dichiara con nome e descrizione, si avvia con una chiamata di strumento, lavora in un contesto separato con permessi propri e restituisce solo il sommario. Dalla stessa pagina vengono la ripresa del colloquio con un sub-agente concluso, la notifica dei sub-agenti in sottofondo e le skill precaricate nella dichiarazione.
• Agent Skills, How to add skills support to your agent - il modello della delega di una skill a un sub-agente dedicato, che riceve le istruzioni, lavora in una sessione separata e riporta il sommario.
• Walden Yan (Cognition), Don’t Build Multi-Agents (giugno 2025) - la posizione contraria ai sub-agenti paralleli a contesto parziale: i due principi sul contesto condiviso e sulle tracce intere, e l’esempio delle decisioni implicite in conflitto.
• Anthropic, Effective context engineering for AI agents (settembre 2025) - i sub-agenti a finestra pulita come tecnica di gestione del contesto: l’esplorazione estesa che si riduce a un sommario di mille-duemila token, raccomandata per la ricerca e l’analisi parallelizzabili.
• Moonshot AI, Kimi Agent Swarm e la scheda del centro assistenza (2026) - l’orchestratore che dirige centinaia di sub-agenti, l’addestramento per rinforzo del solo orchestratore (PARL) e i taccuini di contesto dei sub-agenti. La documentazione pubblica non descrive il meccanismo di avvio: che sia una chiamata di strumento è un’inferenza dal funzionamento degli harness che lo documentano, ed è dichiarata come tale nel testo.