Meta, 14 agenti e una lezione: l’affidabilità non si delega al prompt

Abbiamo passato mesi a discutere di agenti AI sempre più autonomi, dotati di più strumenti, più memoria, più contesto e, possibilmente, della capacità di decidere tutto da soli. Poi arriva un caso tecnico interessante da Meta e la conclusione è quasi offensiva per chi vende intelligenza artificiale a peso: per rendere affidabile il sistema, hanno tolto responsabilità al componente centrale.

Il punto non è che Meta abbia messo insieme quattordici agenti specializzati. Il punto è che l’orchestratore, secondo il resoconto tecnico pubblicato da Meta Engineering il 19 ottobre 2026, è un programma di circa 1.300 righe che coordina oltre venti workflow senza prendere decisioni di dominio. Classifica, raccoglie parametri, controlla prerequisiti, instrada, verifica gli esiti. La parte probabilistica arriva dopo, dove serve davvero.

È una distinzione apparentemente banale. Finché non si prova a gestire un processo reale, con dati già esistenti, operazioni da non ripetere, errori intermittenti, revisioni umane e uno stato da ritrovare anche quando il modello ha smesso di rispondere. Lì il problema non è scrivere un prompt più elegante. È decidere quali responsabilità non devono mai essere affidate a un prompt.

La demo capisce tutto. Il processo, invece, deve arrivare alla fine

Il caso descritto da Meta riguarda l’inserimento di nuove colonne nei sistemi di raccomandazione: configurazioni Python, generazione di codice C++, servizi di elaborazione e sistemi analitici, distribuiti su tre repository e tre linguaggi. Una modifica può attraversare fino a sei fasi prima che il dato sia effettivamente disponibile. Non basta generare il file giusto: bisogna coordinare modifiche coerenti, nell’ordine corretto, evitando che un passo riuscito venga scambiato per il completamento dell’intero processo.

La prima soluzione era un agente generalista caricato con tutta la conoscenza necessaria. Nelle dimostrazioni funzionava. In produzione, racconta Meta, finiva per mescolare convenzioni e procedure di sottosistemi differenti. Una regola corretta per una sorgente dati diventava improvvisamente la regola sbagliata per un’altra. Il modello non era necessariamente privo di informazioni: ne aveva troppe, senza confini abbastanza netti.

La reazione più comune a questo problema è aumentare il contesto, ritoccare il system prompt, aggiungere un altro agente che controlli il primo. A volte aiuta. Ma se la causa è un’architettura che lascia a un modello la responsabilità di scegliere, eseguire e certificare la stessa operazione, stiamo migliorando il vigile urbano senza disegnare gli incroci.

Sette passaggi, sei deterministici: la parte importante è questa

Meta descrive un protocollo in sette passaggi: leggere le istruzioni dello specialista, controllare se l’oggetto esiste già, raccogliere i campi obbligatori, scoprire le informazioni inferibili, applicare i gate di affidabilità, delegare allo specialista, infine gestire il risultato e gli errori. Secondo la descrizione pubblicata, i passaggi da uno a cinque e il settimo sono deterministici; il ragionamento del modello è concentrato nel sesto.

Qui c’è un principio di progettazione che vale molto oltre Meta: un controllo verificabile non dovrebbe dipendere dall’umore statistico di chi lo esegue. Se un’entità esiste già, la verifica è una query con una chiave e una regola di unicità. Se mancano dati obbligatori, è un contratto di input. Se una fase richiede revisione, è una condizione esplicita dello stato. Se un’operazione può essere ripetuta, serve una strategia di idempotenza, non una promessa scritta in linguaggio naturale.

L’agente può proporre una soluzione. Non deve essere lui a stabilire se un vincolo di integrità è facoltativo.

È anche il motivo per cui trovo più utile leggere questa architettura come una separazione delle responsabilità che come l’ennesima storia di multi-agent. Un router affidabile non deve sapere scrivere codice C++ per ogni sorgente dati. Deve sapere a chi delegare, quali informazioni sono necessarie, quale operazione è già stata eseguita e cosa fare quando il risultato non è valido.

Stato, retry e idempotenza: le cose poco fotogeniche che tengono in piedi gli agenti

Prendiamo un esempio più vicino a molti progetti software: un agente deve aggiornare un catalogo, generare una scheda prodotto e pubblicarla. Il modello genera una descrizione corretta, invia la richiesta di creazione e poi perde la connessione prima di ricevere la risposta. Alla ripartenza non sa se la scheda sia stata creata. Se il sistema si limita a ripetere l’azione, il risultato potrebbe essere un duplicato. Se si limita a non ripeterla, potrebbe lasciare il lavoro incompleto.

La soluzione non è chiedergli di ricordarsi meglio. È conservare fuori dal modello una chiave idempotente, un identificatore canonico, lo stato della transazione e l’esito osservabile. Il processo deve poter distinguere un tentativo da un risultato, un risultato parziale da uno completo, un errore di trasporto da un errore di validazione. Questi sono requisiti applicativi, non talenti linguistici.

La distinzione tra workflow predefiniti e agenti con controllo dinamico è discussa anche nella guida ai pattern architetturali di Anthropic. E la documentazione di LangGraph insiste su stato persistente, esecuzione durevole e controllo del flusso. Non sono conferme indipendenti delle metriche dichiarate da Meta; sono riferimenti che mostrano come il problema della separazione fra controllo e ragionamento sia generale.

Questo tema tocca direttamente anche la necessità di esplicitare il modello decisionale degli agenti. Ma qui il passo ulteriore è operativo: non basta dichiarare chi decide. Bisogna progettare cosa accade quando la decisione arriva due volte, non arriva affatto o arriva dopo che lo stato è cambiato.

Quattordici specialisti non significano quattordici cervelli onniscienti

Meta racconta di aver organizzato il lavoro in quattordici specialisti con contesti isolati: gestione degli schemi, popolamento delle sorgenti, validazione e altre attività verticali. Il coordinatore usa template di workflow per comporre questi specialisti in sequenze diverse. La conoscenza viene caricata quando serve, da oltre venticinque file di dominio, invece di restare stipata nel prompt del router.

È un compromesso. Gli specialisti possono diventare più precisi nel proprio perimetro, ma qualcuno deve definire bene le interfacce tra i perimetri. Un agente che produce una configurazione deve restituire un risultato controllabile, non un generico “fatto”. Un altro che la valida deve ricevere l’artefatto corretto e sapere quale versione sta esaminando. La specializzazione riduce una classe di errori, non abolisce la necessità di progettare contratti e osservabilità.

Se un workflow nuovo richiede soltanto una diversa sequenza di capacità esistenti, un template è più economico di un altro agente. Ma se ogni nuovo caso d’uso impone un prompt monolitico, autorizzazioni implicite e stato ricostruito a tentativi, abbiamo soltanto moltiplicato i punti in cui il sistema può sbagliare.

I risultati sono interessanti. Non sono una legge universale

Meta riferisce che la preparazione delle configurazioni per una nuova colonna, prima misurata in tre o quattro giorni di lavoro manuale e poi in circa un giorno con il sistema precedente, scende sotto un’ora con la nuova architettura. Aggiunge che circa due terzi delle modifiche vengono integrate senza interventi umani sostanziali. Sono dati riportati dall’azienda sul proprio ambiente: non un benchmark indipendente e nemmeno una garanzia trasferibile a un e-commerce, a un gestionale o a una pipeline differente.

Per valutare davvero un’architettura simile guarderei almeno quattro numeri: percentuale di modifiche accettate senza correzioni, costo per modifica effettivamente accettata, incidenti dovuti a duplicazioni o stato incoerente, tempo medio necessario per recuperare un’esecuzione interrotta. Il conteggio degli agenti e dei token consumati, da soli, dice molto meno. È lo stesso motivo per cui più codice generato non coincide automaticamente con più software consegnato.

Dove mettere davvero l’intelligenza

Un sistema affidabile non è quello che non fallisce mai: è quello in cui i fallimenti sono previsti, riconoscibili e recuperabili. Il modello può scegliere come interpretare un requisito ambiguo, proporre una modifica o spiegare un’anomalia. Il software attorno deve stabilire se la richiesta è autorizzata, se i prerequisiti sono soddisfatti, se il risultato rispetta lo schema, se è già stato applicato e se è possibile riprendere senza duplicare gli effetti.

Non significa trasformare ogni progetto in una centrale nucleare di stati e controlli. Significa scegliere il livello di garanzia proporzionato al danno possibile. Una bozza di testo può tollerare un retry grossolano; una modifica a un inventario, a un pagamento o a una configurazione di produzione no. La complessità va spesa dove riduce il rischio, non dove rende più impressionante il diagramma.

Il messaggio utile del caso Meta non è “servono quattordici agenti”. È quasi l’opposto: quando il processo conta, l’architettura deve impedire al componente probabilistico di diventare anche arbitro delle proprie regole. L’intelligenza è preziosa nei problemi aperti. Per tutto il resto abbiamo già strumenti molto efficaci: contratti, stati, transazioni, verifiche, log e codice che fa esattamente ciò che deve fare. Stranamente, continuano a funzionare anche senza essere chiamati agenti.