Il modello del superagente
Quando i team iniziano a costruire sistemi agentici, la tentazione iniziale è creare un unico agente "intelligente" a cui dare tutti i tool e tutto il contesto. L'idea è che il modello, essendo capace, saprà orchestrare tutto da solo.
Funziona fino a un certo punto. Poi iniziano i problemi:
- L'agente sceglie il tool sbagliato in situazioni di ambiguità
- Perde il filo nei task lunghi perché il contesto si riempie di rumore accumulato
- Mescola ragionamenti di domini diversi, producendo output inconsistenti
- Diventa impossibile da testare: ogni piccolo cambiamento del prompt influenza dieci comportamenti diversi
A un certo punto, spezzare l'agente in più agenti diventa non un esercizio architettonico, ma una necessità operativa.
Quando l'architettura multi-agent aiuta davvero
Multi-agent non è sempre la risposta. In molti casi è overengineering. I segnali concreti che indicano che vale la pena spezzare un sistema in più agenti:
Domini di decisione molto diversi. Se un agente deve sia classificare ticket di supporto sia generare codice SQL, sono due task con contesti e criteri di successo diversi. Separarli produce due agenti più focalizzati, ognuno testabile in isolamento.
Scale di latenza e costo diverse. Alcuni passi del workflow richiedono risposta immediata, altri possono aspettare. Alcuni richiedono il modello più potente, altri funzionano con il più economico. Un agente unico paga sempre il costo del caso peggiore.
Paralleli naturali nel task. Se il lavoro può essere diviso in sotto-task indipendenti, eseguirli in parallelo con più agenti riduce la latenza totale. Un agente unico, per quanto capace, è sequenziale.
Domini con confini di accesso diversi. Se una parte del workflow richiede dati sensibili e l'altra no, spezzare in due agenti con permessi diversi è più sicuro che dare a uno solo l'accesso a tutto.
Quando resta meglio un agente unico
Al contrario, ci sono casi in cui la complessità aggiunta del multi-agent non è giustificata:
- Task brevi con pochi step (sotto i 5-6 passaggi)
- Workflow dove il contesto è denso e condiviso tra tutti i passaggi
- Sistemi con volume di traffico basso dove la latenza non è un problema
- Prototipi e PoC dove la semplicità batte l'eleganza
La regola pratica: inizia con un agente unico. Spezza solo quando hai un motivo misurabile per farlo.
I tre pattern architetturali che funzionano
Nei sistemi multi-agent in produzione, si consolidano tre pattern ricorrenti. Ognuno risolve un problema diverso.
Pattern 1 — Coordinator e worker
Un agente "coordinator" riceve la richiesta, la decompone in sotto-task, e li distribuisce a uno o più agenti "worker" che eseguono in parallelo. Il coordinator aggrega i risultati e produce la risposta finale.
È il pattern più comune e quello consigliato esplicitamente da Anthropic per la combinazione Sonnet + Haiku. Funziona bene quando:
- Il task si presta alla decomposizione parallela
- I worker possono essere modelli più piccoli/economici del coordinator
- La sintesi finale richiede un giudizio di qualità che i worker non possono fare
Il costo tipico: più chiamate totali, latenza limitata dal worker più lento, robustezza complessiva superiore rispetto a un agente unico.
Pattern 2 — Pipeline sequenziale
Un agente produce un output che diventa l'input dell'agente successivo. Nessuno tocca il task degli altri, ma ognuno raffina o trasforma il risultato precedente.
Esempio tipico: agente 1 classifica e arricchisce una richiesta, agente 2 genera la risposta, agente 3 verifica che la risposta rispetti le policy prima di inviarla. È un pattern che funziona bene quando:
- Ogni step ha criteri di successo chiari e verificabili
- La qualità è critica e ogni step aggiunge un controllo
- Il task ha una struttura naturalmente sequenziale (non parallelizzabile)
Il costo tipico: latenza sommata degli step, ma modularità elevata (puoi sostituire qualunque step senza toccare gli altri).
Pattern 3 — Critic e generator
Un agente "generator" produce output. Un agente "critic" li valuta e chiede revisioni quando necessario. Il loop continua fino a quando il critic approva, o fino a un numero massimo di iterazioni.
È il pattern che paga di più su task creativi o di qualità variabile: generazione di codice, scrittura strutturata, problem solving complesso. Funziona bene quando:
- Il task ha metriche di qualità oggettive o semi-oggettive
- Il costo di un errore è alto abbastanza da giustificare più tentativi
- Il critic può essere specializzato su qualcosa che il generator non vede bene
Il costo tipico: variabile. Può essere molto efficiente se il critic è bravo a bloccare le iterazioni presto; può esplodere se la qualità non converge.
Il problema della comunicazione tra agenti
Il vero costo del multi-agent non è aggiungere un altro modello. È gestire la comunicazione tra agenti. Tre scelte architettoniche pesano molto:
Cosa si passano gli agenti tra loro. Una stringa? Un JSON strutturato? Un oggetto con metadati? Più è strutturato, più è robusto, ma anche più rigido. L'equilibrio dipende da quanto il workflow è prevedibile.
Come gestiscono gli errori. Se un worker fallisce, il coordinator ritenta? Passa al fallback? Rinuncia al task? Senza una policy esplicita, ogni agente fallisce a modo suo e il sistema diventa ingovernabile.
Quanto contesto condividono. Troppo poco, e gli agenti non hanno abbastanza informazioni per lavorare bene. Troppo, e paghi token e performance. La domanda da porsi per ogni scambio: cosa serve davvero al prossimo agente per fare il suo lavoro?
L'architettura come contratto, non come codice
In un sistema multi-agent, il contratto tra agenti è parte dell'architettura. Se agente A produce un JSON con campo category e agente B legge type, hai un bug che nessun lint riuscirà a trovare finché non va in produzione.
Due pratiche che aiutano:
Schema espliciti per l'input e l'output di ogni agente. Pydantic, JSON Schema, o equivalenti. Il contratto tra agenti è dichiarato, non implicito.
Test di integrazione tra agenti. Oltre ai test del singolo agente, servono test che verificano che l'output di A sia un input valido per B. Senza questi test, un cambiamento al prompt di A può rompere B silenziosamente.
Il debugging: dove il multi-agent fa più male
Il problema vero del multi-agent arriva quando qualcosa non funziona in produzione. Un utente segnala una risposta sbagliata. Qual era il problema? Il coordinator ha classificato male la richiesta? Un worker ha prodotto output di scarsa qualità? Il sintetizzatore ha perso informazione importante?
Senza una strategia di osservabilità pensata per multi-agent, ogni incident diventa un'indagine lunga. Tre pratiche la rendono sostenibile:
Trace ID condiviso attraverso tutti gli agenti. Una richiesta utente genera un trace ID. Tutti gli agenti coinvolti nel risolverla loggano con lo stesso trace ID. Debugging = filtra per trace ID e leggi la storia completa.
Logging strutturato di ogni hand-off. Quando un agente passa il testimone al successivo, logga esplicitamente: quale agente, cosa sta passando, perché. Così vedi la catena di decisioni.
Visualizzazione del flow. Se puoi, costruisci un tool interno (anche semplice) che visualizza il percorso di una richiesta attraverso gli agenti. A occhio, un team individua pattern di errore ricorrenti in minuti invece che in ore.
L'evoluzione naturale: da uno a molti
Il percorso che vedo funzionare più spesso non è progettare un sistema multi-agent dall'inizio. È:
- Iniziare con un agente unico, semplice
- Quando un certo tipo di task inizia a degradare la performance, isolarlo in un sotto-agente
- Quando un altro tipo di task presenta lo stesso problema, fare lo stesso
- Dopo qualche iterazione, emergere con un'architettura multi-agent costruita intorno a problemi reali, non supposti
L'architettura multi-agent progettata a priori, senza evidenza di quali sono i collo di bottiglia reali, tende a essere complessa nei posti sbagliati e semplice dove invece avrebbe bisogno di complessità.
La domanda che chiude
Prima di spezzare un agente in due, vale la pena fare una domanda: se spezzo questo agente, il sistema diventa più prevedibile, più testabile, più veloce — o sto solo spostando la complessità?
Se la risposta è "più prevedibile e più testabile", è quasi sempre la scelta giusta. Se la risposta è "più veloce perché parallelizzo", è spesso giusta, ma attenzione al costo di orchestrazione. Se la risposta è "non lo so, ma sembra più pulito", aspetta ancora. Il multi-agent senza una ragione operativa precisa è uno dei modi migliori di moltiplicare i bug senza risolvere problemi.
Gli agenti che funzionano in produzione non sono quelli più sofisticati. Sono quelli costruiti con la disciplina di non aggiungere complessità prima che la complessità serva.