Il problema di un agente unico sovraccarico

All’inizio del progetto Meta, l’obiettivo era automatizzare l’onboarding di colonne dati nei sistemi di raccomandazione. Il processo attraversa tre repository di codice, tre linguaggi di programmazione e fino a sei fasi della pipeline, tutte da mantenere sincronizzate.

Il team ha seguito la prassi più comune: creare un unico agente intelligente che contenesse tutta la conoscenza necessaria – schemi di configurazione, regole di generazione del codice, logica di routing della pipeline e requisiti di validazione. Nei demo l’agente funzionava, ma in produzione iniziò a “allucinare”, generando configurazioni errate o applicando convenzioni di denominazione di un sottosistema a un altro.

Il tentativo di risolvere il problema aumentando la dimensione del contesto o affinando i prompt non ha portato benefici. Il vero colpevole era l’eccessivo carico di conoscenza affidato a un singolo modello, che ha iniziato a contaminare i contesti e a degradare le prestazioni.

Studi a supporto

    • Un preprint del Windreich Department of Artificial Intelligence and Human Health (Mount Sinai) mostra che sistemi multi‑agent orchestrati raggiungono il 65,3 % di accuratezza su batch da 80 task, rispetto al 16,6 % dei singoli agenti, riducendo l’uso di token fino a 65 volte.
    • Un test interno con un unico agente, supportato da ingegneri che scrivevano prompt personalizzati, ha ottenuto un tasso di successo del 70‑80 %; senza quella “hand‑holding” il risultato è sceso al 10‑20 %.

La soluzione: il Thin Orchestrator

La risposta è stata dividere il sistema in due livelli distinti:

    • Orchestratore deterministico: un router che non effettua alcuna elaborazione di dominio. Classifica l’intento, raccoglie i campi richiesti, esegue controlli di affidabilità e delega al sotto‑agente appropriato.
    • Quattordici sotto‑agenti specialisti: ciascuno è un esperto completo di un singolo dominio (gestione schema, generazione di codice per 10 fonti dati, validazione, ecc.). Nessun agente vede l’intero panorama; l’isolamento è una caratteristica, non un difetto.

L’orchestratore segue un protocollo fisso di sette passaggi per ogni richiesta, di cui solo il passaggio 6 – la delega al sotto‑agente – utilizza un modello LLM. Tutti gli altri passaggi sono deterministici e quindi più rapidi e prevedibili.

Protocollo a 7 step

    • Leggere il file di istruzioni del sotto‑agente.
    • Verificare se la destinazione esiste già (evitare duplicati).
    • Raccogliere i campi richiesti all’utente.
    • Scoprire automaticamente informazioni inferibili (tipo di repository, configurazioni esistenti).
    • Eseguire un gate di affidabilità (avvisi attivi, revisori richiesti).
    • Delegare al sotto‑agente con il contesto completo.
    • Gestire i risultati, segnalare errori e confermare il successo.

Implementazione pratica: template di workflow

Un insight chiave è stato separare “cosa” deve accadere da “come” viene eseguito. L’orchestratore definisce l’ordine delle fasi mediante template di workflow, macchine a stati deterministiche che limitano lo spazio decisionale del modello LLM.

Esempi di template:

    • Onboarding di colonna: Schema → Validazione → Popolazione → Test.
    • Onboarding di evento: Schema → Popolazione → Validazione → Test → Elaborazione evento.
    • Migrazione pipeline: Valutazione → Pianificazione → Popolazione → Validazione → Monitoraggio.

Tutti i template riutilizzano gli stessi 14 sotto‑agenti in sequenze diverse. Quando è stato richiesto di supportare la migrazione della pipeline, non è stato necessario creare nuovi agenti: è stato sufficiente scrivere un nuovo template che riordina gli agenti esistenti.

Struttura standard di un sotto‑agente

    • Fonti di conoscenza: file di dominio caricati a runtime (di solito poche migliaia di token).
    • Checklist di pre‑raccolta: dati che l’orchestratore deve raccogliere prima della delega.
    • Workflow passo‑a‑passo: piano di esecuzione specifico del dominio.
    • Pattern di scoperta: modalità per trovare codici rilevanti nel monorepo.
    • Risoluzione dei problemi: mappatura errori‑soluzioni per i fallimenti più comuni.

Questa uniformità rende l’aggiunta di un nuovo sotto‑agente un’attività template, non un progetto da zero. Il quindicesimo agente, ad esempio, è strutturalmente identico ai precedenti.

Risultati concreti

Con l’orchestratore thin, la preparazione della configurazione per una nuova colonna, che richiedeva 3‑4 giorni manuali o circa un giorno con il precedente sistema basato su configurazioni, è stata ridotta a meno di un’ora.

In termini di adozione, circa due‑terzi delle modifiche al sistema vengono ora introdotte senza interventi umani significativi. Il guadagno nasce dal trade‑off deliberato: l’orchestratore rimane generico, mentre i sotto‑agenti possiedono conoscenze profonde e isolate.

Perché il thin orchestrator funziona

    • Decisioni deterministiche rimangono deterministiche: il routing non richiede LLM.
    • Isolamento del contesto: ogni agente vede solo il proprio dominio, evitando contaminazioni.
    • Fallimenti contenuti: se un agente fallisce, l’orchestratore può ritentare o segnalare, senza compromettere gli altri.
    • Miglioramenti indipendenti: un modello più potente migliora tutti i 14 sotto‑agenti simultaneamente; un aggiornamento di un file di conoscenza entra in vigore immediatamente.

Come adottare il pattern nella propria organizzazione

Il modello non è limitato ai data pipeline di Meta. Qualsiasi squadra che sviluppa agenti AI in produzione può trarne vantaggio seguendo questi passi:

    • Identificare le funzioni di routing rispetto a quelle di ragionamento di dominio.
    • Costruire un orchestratore minimale che si occupi solo di classificazione dell’intento, raccolta di dati e controlli di affidabilità.
    • Creare sotto‑agenti specialisti, ciascuno con un set di conoscenza limitato e ben definito.
    • Definire template di workflow che descrivano la sequenza di agenti necessari per ogni caso d’uso.
    • Implementare un meccanismo di caricamento on‑demand dei file di conoscenza, in modo che gli aggiornamenti siano immediatamente disponibili.
    • Stabilire policy di retry ed escalation nell’orchestratore per gestire i fallimenti dei sotto‑agenti.

Seguendo questa architettura, le organizzazioni possono ridurre drasticamente le allucinazioni dei modelli, ottimizzare l’uso dei token e accelerare i cicli di sviluppo.

Conclusioni

Meta ha dimostrato che un orchestratore “thin”, che delega tutte le decisioni di dominio a specialisti isolati, porta a sistemi AI più affidabili, veloci e scalabili. L’approccio rompe il mito secondo cui più contesto garantisce migliori risultati, evidenziando invece l’importanza di una separazione chiara tra routing e ragionamento. Applicando questi principi, le squadre di ingegneria possono costruire agenti AI più robusti e pronti per la produzione.