Multi-agent workflow: analyst, engineer, reviewer, owner

Un singolo agente che fa analisi dati dall’inizio alla fine sembra efficiente e quasi sempre finisce male: mescola la domanda di business con la query SQL, la query con l’interpretazione, l’interpretazione con la raccomandazione, e alla fine nessuno sa dire dove si è rotto qualcosa. Il memo finale suona convincente, i numeri tornano a occhio, ma se un collega chiede come sei arrivato a quel tasso di conversione o perché la coorte è definita così, la risposta è una conversazione persa in un log di chat. La soluzione non è un prompt migliore: è dividere il lavoro in quattro responsabilità strette, analyst, engineer, reviewer, owner, ciascuna con input, output e controlli propri, cucite insieme da handoff espliciti che un essere umano può ispezionare, contestare, fermare. Questa lezione appartiene al binario sistemi-llm.

Perché un solo agente non basta per l’analisi dati

Il lavoro analitico ha una proprietà scomoda: gli errori si compongono in silenzio. Una finestra temporale sbagliata di sette giorni sposta una coorte, la coorte sposta il denominatore, il denominatore sposta il tasso, il tasso sposta la decisione sul budget. Con un agente unico, ogni passaggio eredita l’errore del precedente senza che nessuno lo verifichi, perché non esiste un punto di controllo intermedio con un proprietario diverso da chi ha prodotto il passaggio. È lo stesso motivo per cui nelle pipeline software esistono build, test e review separati: non perché gli sviluppatori siano inaffidabili, ma perché i difetti vanno intercettati dove nascono, non a valle quando hanno già contaminato tutto.

C’è poi un problema di incentivi impliciti. Un agente generico ottimizzato per produrre una risposta utile tende a colmare i vuoti: se il grain della tabella non è chiaro, lo indovina; se manca la definizione di utente attivo, ne sceglie una plausibile e va avanti. Il risultato è fluido da leggere e fragile da usare. Dividere i ruoli cambia l’incentivo: l’analyst deve dichiarare le assunzioni perché l’engineer le verificherà contro lo schema reale, l’engineer deve documentare il lineage perché il reviewer lo controllerà, il reviewer deve scrivere obiezioni verificabili perché l’owner deciderà sulla base di quelle, non del tono del memo.

Il terzo motivo è operativo e riguarda il blast radius. Un agente unico con accesso a warehouse, tool di esecuzione e canali di comunicazione può fare danni su tre assi contemporaneamente: query costose senza limiti, scritture su tabelle di produzione, messaggi a stakeholder con numeri non validati. Con quattro ruoli puoi applicare il principio del privilegio minimo: solo l’engineer esegue SQL e solo in lettura su dataset dichiarati, solo il reviewer può marcare un artefatto come verificato, solo l’owner può autorizzare un’azione esterna. Se un ruolo viene compromesso da un’istruzione malevola o da un dato avvelenato, gli altri arginano il danno.

I quattro ruoli e i confini che li rendono utili

La tabella qui sotto fissa il contratto in una riga per ruolo: cosa possiede, cosa produce, cosa non deve mai fare. Tutto il resto dell’articolo è l’implementazione di questa tabella.

Role	Possiede	Produce	Non fa mai
Analyst	la domanda e le ipotesi	ipotesi testabili, definizioni di metriche, disegno dell’analisi	non tocca i dati grezzi né esegue query
Engineer	i dati e il lineage	query versionate, dataset intermedi, test di qualità	non interpreta i risultati in chiave business
Reviewer	i controlli	obiezioni verificabili, esito di test, giudizio di tenuta	non propone nuove analisi, giudica quelle esistenti
Owner	la decisione	soglia decisionale, azione, piano di monitoraggio	non delega la firma su budget, roadmap o compliance

L’analyst lavora sul perché: riceve una richiesta vaga come le attivazioni sono calate, capisci cosa succede e la restituisce come tre o quattro ipotesi falsificabili, ciascuna con la metrica, il segmento e il periodo che la confermerebbero o la smentirebbero. Non ha accesso al warehouse, e questa è una scelta deliberata: lo costringe a scrivere definizioni abbastanza precise da essere eseguibili da qualcun altro. Se l’analyst potesse improvvisare una query al volo, le ambiguità resterebbero sepolte nel codice invece di emergere come domande esplicite.

L’engineer lavora sul cosa e sul come dei dati: prende le definizioni dell’analyst e le traduce in SQL versionato, con grain dichiarato, filtri espliciti e test che falliscono in modo rumoroso quando i dati cambiano forma. Non gli è permesso aggiustare un risultato che sembra sbagliato cambiando un filtro in silenzio: ogni correzione passa da una nuova versione della query con motivazione registrata. Questa rigidità è il punto, perché rende ogni numero tracciabile fino alla riga di codice che lo ha prodotto.

Il reviewer è l’avversario interno. Non rilegge il memo per lo stile: riesegue i controlli indipendenti, cerca leakage temporale, verifica che il denominatore delle metriche sia quello giusto, segmenta il risultato per vedere se regge. Ha potere di veto, non di proposta: può bocciare un artefatto rimandandolo all’analyst o all’engineer con obiezioni puntuali, ma non può riscriverlo lui. La separazione impedisce il conflitto di interessi più comune nei sistemi agentici, quello in cui chi produce il lavoro ne certifica anche la qualità.

L’owner è l’unico umano nel loop che conta davvero, oppure un agente con credenziali esplicitamente delegate per decisioni reversibili a basso impatto. Fissa la soglia prima di vedere i risultati, per esempio interveniamo sul checkout solo se il calo di conversione supera i due punti percentuali su traffico comparabile per due settimane, e firma l’azione con un piano di monitoraggio. Senza owner, il workflow produce insight che nessuno usa; con un owner vago, produce decisioni che nessuno difende.

Il contratto di handoff che tiene insieme i quattro ruoli

Tra un ruolo e l’altro non passa una conversazione libera: passa un artefatto strutturato con cinque campi obbligatori. Chiamiamolo handoff envelope, e vale la pena implementarlo come schema validato, non come convenzione documentata, perché le convenzioni vengono ignorate sotto pressione mentre gli schemi rifiutano payload incompleti.

# Ogni passaggio tra ruoli è un dizionario validato: se manca un campo, il workflow si ferma
handoff = {
    "decisione": "ridisegnare lo step di pagamento se il calo è reale",  # quale scelta supporta
    "artefatto": "s3://analytics/handoffs/h_2026_08_14_cohort.parquet",  # dove si trova, mai inline
    "assunzioni": ["grain: una riga per utente/giorno", "fuso: Europe/Rome"],  # cosa si dà per vero
    "controlli": ["grain test superato", "baseline 4 settimane allegata"],  # cosa è stato verificato
    "stop": "se il null rate su channel supera il 15%, fermare tutto",  # cosa blocca il flusso
}
# Il validatore a valle rifiuta handoff senza questi campi: meglio un errore subito che un numero dubbio dopo

Tre regole rendono questo schema efficace. Primo, gli artefatti viaggiano per riferimento, non incollati nel contesto: l’handoff contiene un path versionato verso query, dataset o memo, così il contesto degli agenti resta piccolo e il costo resta sotto controllo. Secondo, ogni handoff dichiara le assunzioni in forma elencabile, perché il reviewer deve poterle trasformare in test uno a uno. Terzo, ogni handoff porta la sua stop condition: la frase che dice quando fermarsi. Sembra burocrazia e invece è l’opposto, perché elimina le discussioni infinite su ma questi dati sono abbastanza buoni sostituendole con un criterio scritto prima che i numeri arrivino.

Il formato dell’handoff cambia con la coppia di ruoli. Dall’analyst all’engineer passa una specifica di analisi: ipotesi, metrica con numeratore e denominatore, coorte, periodo, segmenti, esclusioni. Dall’engineer al reviewer passa codice più evidenza: query versionata, profilo dati con null rate e cardinalità, risultato della baseline. Dal reviewer all’owner passa un giudizio: esito dei controlli, obiezioni residue, raccomandazione condizionata. Ogni formato ha il suo schema, ma tutti condividono i cinque campi sopra.

Come l’analyst trasforma una domanda vaga in ipotesi testabili

Il lavoro dell’analyst si giudica da una cosa sola: alla fine della sua fase, ogni ipotesi deve essere falsificabile con i dati disponibili. Gli utenti sono meno engaged non è un’ipotesi, è un umore. La quota di utenti con almeno tre sessioni settimanali nel segmento organico è scesa di oltre tre punti rispetto alla media mobile delle quattro settimane precedenti è un’ipotesi: ha metrica, soglia, segmento, baseline temporale. La differenza tra le due frasi è l’intero valore del ruolo.

Un buon analyst produce poche ipotesi ordinate per leva decisionale, non una lista lunga di curiosità. Per ciascuna dichiara cosa la confermerebbe, cosa la smentirebbe e quale decisione seguirebbe in ogni caso. Se confermata e smentita portano alla stessa azione, l’ipotesi è decorativa e va scartata: il test deve avere conseguenze, altrimenti è teatro analitico. Questo filtro da solo elimina metà del lavoro inutile che intasa i workflow agentici.

La parte quantitativa sta nel fissare la soglia prima di guardare i dati. Per un confronto tra proporzioni, per esempio conversione prima e dopo una modifica, l’analyst scrive la differenza da rilevare e l’errore standard sotto ipotesi di indipendenza, da cui l’intervallo di confidenza. Non serve sempre un test formale completo, ma serve la disciplina che il calcolo impone: quanti ordini di grandezza ha il campione, che ampiezza di intervallo è accettabile, quale differenza minima giustifica un’azione. Senza questi numeri, qualsiasi variazione sembra un segnale e ogni dashboard diventa un generatore di falsi allarmi.

L’analyst dichiara anche il disegno contro i confondenti: confronto su traffico comparabile, segmentazione per canale di acquisizione, controllo di stagionalità con baseline mobile. Scrive le esclusioni in anticipo, traffico bot, utenti interni, periodi di incident, perché le esclusioni decise dopo aver visto i numeri sono il modo più elegante per mentire a se stessi. L’engineer eseguirà alla lettera; il reviewer controllerà che l’esecuzione corrisponda alla specifica.

Come l’engineer rende i dati degni di fiducia

L’engineer riceve la specifica e restituisce tre cose: la query versionata, il profilo del dataset, il confronto con la baseline. La query sotto è lo scheletro tipico per una retention a 30 giorni calcolata su coorte di attivazione, il caso dove gli errori di grain fanno più danni. Ogni clausola risponde a una riga della specifica dell’analyst, e i commenti dicono quale.

-- Grain dichiarato: una riga per utente nella CTE cohort, una per data di attivazione in output
WITH cohort AS (
    SELECT
        user_id,
        MIN(event_date) AS activation_date  -- coorte = prima apparizione, non ultimo evento
    FROM events
    WHERE event_date >= '2026-06-01'  -- periodo dalla specifica analyst, mai scelto qui
      AND is_bot = FALSE                -- esclusioni dichiarate prima di vedere i numeri
      AND is_internal = FALSE
    GROUP BY user_id
),
retention AS (
    SELECT
        c.activation_date,
        COUNT(DISTINCT c.user_id) AS cohort_users,  -- denominatore: tutta la coorte
        COUNT(DISTINCT CASE
            WHEN e.event_date > c.activation_date
             AND e.event_date <= c.activation_date + INTERVAL '30 days'
            THEN e.user_id END) AS retained_users   -- numeratore: attività successiva, mai inclusiva del giorno zero
    FROM cohort c
    LEFT JOIN events e ON c.user_id = e.user_id
    GROUP BY c.activation_date
)
SELECT
    activation_date,
    cohort_users,
    retained_users,
    ROUND(retained_users * 1.0 / NULLIF(cohort_users, 0), 4) AS retention_rate
FROM retention
ORDER BY activation_date;

Notare tre dettagli che distinguono una query revisionabile da una improvvisata. Il LEFT JOIN with NULLIF al denominatore impedisce di nascondere le coorti vuote: se un giorno ha zero utenti, appare con tasso nullo invece di sparire. Il filtro bot e interni sta nella coorte, non solo negli eventi, perché un utente bot deve sparire dal denominatore oltre che dal numeratore. Il giorno zero è escluso dal numeratore, perché contare l’evento di attivazione come ritenzione gonfia il tasso di una quantità che dipende dal mix di canali, non dal comportamento reale.

Accanto alla query, l’engineer allega il profilo dati: null rate per colonna chiave, cardinalità di user_id, distribuzione di event_date con buchi e picchi, conteggio righe contro la settimana precedente. Aggiunge un confronto baseline: stessa query sulle quattro settimane precedenti, così il reviewer vede subito se il calo è una variazione o una rottura della pipeline. Se il null rate su una colonna di segmentazione supera la soglia scritta nella stop condition, l’engineer non procede: ferma il flusso e segnala, perché segmentare su dati mancanti produce insight che riflettono il logging, non il business.

Il reviewer come avversario costruttivo e i controlli che contano

Il reviewer non si chiede se l’analisi è convincente, si chiede in quanti modi indipendenti potrebbe essere sbagliata e li prova uno a uno. La checklist è corta e brutale: il grain è quello dichiarato, il denominatore è corretto, non c’è leakage temporale, il risultato regge alla segmentazione, la baseline è comparabile. Ogni voce produce un esito binario con evidenza allegata, non un parere. Sembra ragionevole non è un esito; rieseguito il grain test su 7 giorni con zero duplicati sulla chiave utente più data, log allegato, è un esito.

Il leakage temporale merita attenzione particolare perché è l’errore che gli agenti commettono più spesso e che suona meglio quando lo commettono. Tipico: una feature calcolata su una finestra che include il periodo da predire, oppure un filtro su eventi futuri rispetto alla coorte. Il sintomo è un miglioramento metrico troppo bello, e la cura è una regola meccanica: ogni colonna usata nel calcolo deve avere timestamp strettamente precedente all’istante di osservazione. Il reviewer la verifica leggendo la query, non fidandosi del memo.

La segmentazione è il secondo strumento: rifare il calcolo per canale di acquisizione, per piattaforma, per fascia di anzianità. Se il calo di conversione esiste solo su un canale, la storia sul prodotto che peggiora crolla e nasce un’ipotesi migliore sul mix di traffico o sul tracciamento di quel canale. È qui che si vede la differenza tra produttività individuale e affidabilità organizzativa: un agente singolo raramente si smentisce da solo, un reviewer separato non ha alcun costo emotivo nel demolire il lavoro altrui.

# Controlli meccanici del reviewer: rieseguiti sui dati, mai fidandosi del memo
import pandas as pd

def grain_test(df, keys):
    # vero se la chiave è univoca: duplicati qui = denominatori gonfiati ovunque
    return df.duplicated(subset=keys).sum() == 0

def null_rate(df, colonna):
    # quota di mancanti: oltre soglia, la segmentazione su questa colonna è inaffidabile
    return df[colonna].isna().mean()

def baseline_drift(attuale, baseline, soglia=0.10):
    # variazione relativa dei volumi contro baseline: oltre soglia, sospetta rottura pipeline
    return abs(attuale - baseline) / baseline > soglia

# Esempio d'uso: tre assert, tre righe di evidenza nel giudizio del reviewer
assert grain_test(cohort, ["user_id"])
assert null_rate(events, "channel") < 0.15
assert not baseline_drift(len(events), len(baseline_events))

Quando tutti i controlli passano ma resta un’obiezione non risolvibile con i dati attuali, il reviewer la dichiara come rischio residuo invece di bloccare tutto: il segmento iOS è sottorappresentato per un buco di logging noto, con effetto stimato entro una soglia dichiarata. L’owner deciderà se quel residuo è accettabile. Il veto scatta solo per difetti che cambiano la conclusione o violano privacy, costo o policy.

L’owner e la decisione con soglie scritte prima dei numeri

L’owner fa due cose che nessun agente dovrebbe fare al suo posto: fissa la soglia decisionale prima di vedere i risultati e firma l’azione con nome e data. La soglia pre-registrata protegge contro il bias più costoso dell’analisi assistita, quello di muovere il palo dopo aver visto dove cade la palla. Interveniamo se il calo supera i due punti su traffico comparabile per due settimane consecutive è una soglia; valutiamo in base ai dati è una delega in bianco. Il reviewer verifica che la soglia esista e sia precedente ai numeri, poi confronta.

La decisione dell’owner ha sempre quattro esiti possibili, non due. Procedere, quando controlli e soglia convergono. Non procedere, quando il segnale non c’è o il rischio residuo è troppo alto. Raccogliere più dati, quando l’intervallo è troppo largo per decidere in entrambe le direzioni, e in questo caso l’owner fissa cosa manca e quando si rivaluta, non un generico approfondiamo. Fermare il workflow, quando scatta una stop condition su qualità dati, costo o compliance. Quest’ultimo esito va celebrato, non nascosto: un processo che non si ferma mai non è robusto, è sordo.

Accanto alla decisione, l’owner firma il piano di monitoraggio: quale metrica osservare, con quale cadenza, con quale soglia di allarme e chi viene avvisato quando scatta. Un workflow senza monitoraggio è una scommessa una tantum; con il monitoraggio diventa un assetto decisionale ripetibile. La metrica di monitoraggio è spesso diversa da quella di analisi, più semplice, più frequente, più rumorosa ma disponibile in tempo reale, e va scelta esplicitamente, non ereditata per inerzia.

Mettere il workflow in produzione senza perdere il controllo

Quattro ruoli in un notebook funzionano in un pomeriggio; in produzione servono tre infrastrutture noiose che nessuno cita nei demo ma che decidono se il sistema sopravvive al primo mese. La prima è l’orchestrazione con stato: un grafo esplicito da analyst a engineer a reviewer a owner, con retry solo sui nodi idempotenti e checkpoint dopo ogni handoff validato. Se l’engineer fallisce per un timeout del warehouse, il retry è sicuro; se il reviewer ha bocciato un artefatto, il flusso torna all’analyst con l’obiezione allegata, non riparte da zero perdendo il contesto. Framework come LangGraph o l’Agents SDK servono a questo, non a rendere gli agenti più intelligenti: rendono le transizioni osservabili e i fallimenti recuperabili.

La seconda è il controllo dei permessi per ruolo, applicato dal sistema e non dalla buona volontà dei prompt. L’analyst non ha credenziali sul warehouse, l’engineer ha solo lettura su dataset dichiarati con tetto di spesa per query e timeout aggressivi, il reviewer può leggere tutto e scrivere solo giudizi, l’owner è l’unico che può autorizzare scritture o comunicazioni esterne. Le istruzioni malevole iniettate in un documento o in una cella di dati colpiscono così un ruolo con capacità limitate invece di un super-agente con le chiavi di tutto.

La terza è l’osservabilità: ogni handoff registrato con timestamp, versione degli artefatti, esiti dei controlli e token consumati. Il costo merita un rigo dedicato perché i workflow multi-agente lo moltiplicano: quattro ruoli che si passano contesti gonfi di tabelle incollate costano un ordine di grandezza più di uno che passa riferimenti. La regola è semplice, passare path e riassunti statistici, mai dataframe serializzati nel contesto, e fissare un budget per run con allarme. La latenza segue la stessa logica: i nodi indipendenti girano in parallelo, ma analyst, engineer e reviewer sono sequenziali per costruzione, perché la sequenza è il controllo.

Resta la domanda onesta su quando non serve tutto questo. Per un’esplorazione una tantum su dati piccoli e decisione reversibile, quattro ruoli sono burocrazia: bastano analyst ed engineer fusi con una checklist di auto-review. Per decisioni che toccano budget, clienti o compliance, invece, togliere il reviewer o l’owner non è semplificazione, è azzardo con un nome elegante. Il criterio è il costo dell’errore moltiplicato per la probabilità di accorgersene tardi: se entrambi sono alti, il workflow completo paga il suo overhead al primo disastro evitato. Quando il processo gira da mesi senza obiezioni del reviewer, il problema non è che i dati sono diventati perfetti: è che i controlli si sono addormentati, e va reintrodotta varietà, nuove segmentazioni, baseline alternative, fault injection sui test, prima che sia un incidente reale a svegliarli.

Verdetto: un agente singolo basta per esplorazioni reversibili, mentre per budget, clienti o compliance servono quattro ruoli separati con handoff validati, veto del reviewer e firma dell’owner.

Il cuore del modello in una frase

Il workflow a quattro ruoli separa chi propone l’analisi, chi esegue sui dati, chi controlla in modo indipendente e chi firma la decisione.

La sequenza operativa in cinque passi

1. Fai tradurre all’analyst la domanda in ipotesi falsificabili con metrica e soglia.
2. Fai eseguire all’engineer query versionate con grain, filtri ed esclusioni dichiarati.
3. Fai rieseguire al reviewer controlli indipendenti con esiti binari ed evidenza.
4. Fai fissare all’owner soglia decisionale e piano di monitoraggio prima dei numeri.
5. Registra ogni handoff con artefatti versionati e blocca sul primo controllo mancante.

Un caso reale: la separazione dei ruoli in un gioco di strategia

Nel novembre 2022 Meta ha presentato su Science CICERO, un sistema capace di giocare a Diplomacy con partecipanti umani. Diplomacy coinvolge 7 giocatori in trattative, alleanze e tradimenti, un banco di prova multi-agente reale. CICERO ha disputato 40 partite online piazzandosi nel top 10 per cento contro giocatori umani. Il caso mostra che la separazione dei ruoli funziona: pianificazione strategica e dialogo erano moduli distinti con un filtro che validava ogni mossa prima dell’invio.

Domande per chiudere la lezione

1. Cosa possiede ogni ruolo e cosa non deve mai fare?
2. Quali cinque campi rendono un handoff valido tra due ruoli?
3. Come il reviewer intercetta leakage temporale e denominatori sbagliati?
4. Quando l’owner procede, rimanda o ferma il workflow?