12 errori che vediamo fare ai team al primo sistema ops multi-agent

Un sistema ops multi-agent è un workflow in cui due o più agent LLM condividono stato e si dividono il lavoro verso un singolo risultato di business, di solito sotto un orchestratore che tiene il piano e assegna i task a subagent specializzati. Sul whiteboard sembra pulito. In produzione si rompe in modi prevedibili. Le analisi più recenti collocano il tasso di fallimento in produzione dei sistemi LLM multi-agent fra il 41 e l'86,7 percento, e circa il 79 percento dei fallimenti si riconduce a specifiche scritte male e a coordinamento rotto, non alla qualità del modello (Augment Code, tassonomia MAST).

TL;DR. Quasi tutti i team spediscono l'orchestratore prima dell'eval harness, danno ai subagent stato condiviso in scrittura, saltano il verificatore e scoprono la bolletta dei token un lunedì mattina. La cura è noiosa: ogni risorsa ha un proprietario, il verificatore è un agent diverso dall'orchestratore, retry e token sono limitati, e si parte da due agent prima di salire a dieci.

1. Trattare l'orchestratore come un chatbot

L'orchestratore non è un assistente di chat con qualche tool in più. È un planner che deve registrare il piano, sapere cosa possiede ogni subagent e sopravvivere all'esaurimento di token a metà run. I team che saltano questo passo scrivono un prompt che suona come un system message amichevole, e poi guardano gli agent divergere al primo task lungo. Il team di ricerca Anthropic fa sì che il lead scriva il piano in memoria prima di dispatchare i subagent, proprio perché il run sopravviva a un context reset (Anthropic Engineering).

2. Lasciare ai subagent stato condiviso in scrittura

Se due agent possono scrivere sulla stessa riga di database, sullo stesso file o sullo stesso ticket Linear, hai un bug di concorrenza che aspetta solo una scadenza. La regola che regge in produzione è semplice: ogni risorsa ha un solo proprietario. Gli agent che devono coordinarsi lo fanno tramite un message bus o una task queue, non attraverso un record condiviso mutabile. I problemi di specifica e design pesano per il 41,8 percento dei fallimenti multi-agent nella tassonomia MAST, e l'ambiguità di proprietà è la sotto-categoria più grande.

3. Saltare il verificatore, o farlo coincidere con l'orchestratore

Circa un fallimento su quattro nei sistemi multi-agent accade perché il sistema non ha verificato bene il proprio lavoro, e la verifica scorretta è il singolo modo di fallire più frequente al 9,1 percento. Il verificatore va separato, con prompt diverso e idealmente classe di modello diversa. Un orchestratore che valuta il proprio piano accetta il proprio output sbagliato. Abbiamo visto team aggiungere il verificatore solo dopo il terzo post-mortem.

4. Girare in sincrono quando il lavoro è parallelizzabile

La topologia di default dei subagent di Claude Code è sincrona. Il lead aspetta che ogni gruppo di subagent finisca prima di dispatchare il successivo. Anthropic lo ha indicato come collo di bottiglia reale e ha osservato che l'async sbloccherebbe più parallelismo al costo di una gestione degli errori più dura. Se i tuoi subagent leggono da fonti indipendenti e non devono mai confrontarsi a metà task, il costo dell'async vale la pena. Se invece devono confrontarsi, resta sincrono e riduci il fan-out.

5. Nessun budget di token per task

L'accumulo di token in un loop agentico ingenuo è quadratico, non lineare. Un loop a 20 step in cui ogni step genera 1.000 token produce circa 210.000 token di input cumulativi, perché l'intera storia viene ri-serializzata a ogni chiamata (Augment Code). Si risolve con un controllo di budget pre-esecuzione e una compattazione automatica del contesto prima che la finestra si riempia. Senza, un singolo task troppo zelante una domenica sera può spendere più di quanto un ingegnere senior porti a casa in una settimana.

6. Nessun tetto ai retry

L'incidente più comune in produzione nei sistemi agentici non è una risposta sbagliata. È un agent che riprova, e riprova, e riprova. Ogni retry è una chiamata piena al provider. Il contesto raddoppia. Un contesto iniziale da 4.000 token può arrivare a 128.000 allo step 5, e il costo per step è cresciuto di 32 volte. Allo step 30 il loop ha speso più dello stipendio mensile di un ingegnere competente (TrueFoundry). Limita i retry a tre, logga il fallimento, esci. Meglio escalare a un umano che dissanguarsi.

7. Forzare il multi-agent su lavoro strettamente accoppiato

Anthropic è stata diretta. I sistemi multi-agent eccellono nei problemi che si separano in strand di ricerca paralleli e sono meno efficaci nei task strettamente interdipendenti come il coding. Se nel tuo grafo dei task ogni nodo legge l'output del nodo precedente, non hai un problema multi-agent, hai un run lungo a singolo agent con checkpoint. Il divario di costo è reale: una configurazione multi-agent consuma circa quindici volte più token di una singola chat per lo stesso risultato.

8. Lasciare agli agent la scoperta degli schemi a runtime

La contaminazione dei dati è il modo di fallimento esterno più comune nei sistemi multi-agent. La causa di solito è la stessa: un agent chiama un'API o interroga una tabella senza schema stretto, riceve indietro una forma che non capisce e inventa campi o scrive spazzatura a valle. Consegna a ogni agent il suo schema nel prompt, valida i payload in ingresso con Zod o Pydantic prima di ragionarci sopra, rifiuta input che non parsano.

9. Loggare solo gli output finali

Se le tracce catturano solo la risposta finale, non puoi debuggare un fallimento multi-agent. Servono il piano dell'orchestratore, il prompt e la risposta di ogni subagent, ogni tool call, il conteggio token per chiamata e il verdetto del verificatore. Piccoli cambiamenti nei sistemi agentici si propagano in grandi cambi di comportamento, e fare debug post-incidente senza tracce a livello di step è tirare a indovinare. OpenTelemetry con attributi di span per nome agent e task ID è la configurazione meno costosa che funziona.

10. Saltare l'eval harness prima della produzione

Circa l'88 percento dei progetti AI agent non arriva mai in produzione, e la ragione più frequente non è la capacità del modello. È che il team non aveva un set di valutazione offline, una suite di regressione, e nessun modo di sapere se un cambio di prompt aveva migliorato o peggiorato le cose. Costruisci un set di venti task rappresentativi prima di spedire. Fai girare l'intero loop multi-agent contro di loro a ogni cambio di prompt o modello. Senza, ogni rilascio è un lancio di moneta.

11. Scegliere la topologia sbagliata prima di avere telemetria

Il panorama dei framework nel 2026 distingue tre modelli di orchestrazione dominanti: graph-based (LangGraph), role-based (CrewAI) e swarm con handoff (OpenAI Agents SDK, Anthropic Agent Teams). Ognuno ottimizza un fallimento diverso. I grafi rendono lo stato esplicito ma rigido. I ruoli rendono la collaborazione leggibile ma costosa. Gli swarm minimizzano l'overhead ma rendono lo stato difficile da recuperare. Scegli la topologia che combacia con il tuo pattern di fallimento reale, che conosci solo dopo una settimana di telemetria.

12. Nascondere il costo dentro un wrapper

L'ultimo errore è organizzativo. Il team che costruisce l'agent vede la latency e la qualità del modello. La finanza vede una fattura da 40.000 dollari il primo del mese. Senza attribuzione del costo per agent, nessuno può rispondere alla domanda successiva ovvia, che è se l'agent stia ripagando il proprio conto. Tagga ogni chiamata al provider con un ID agent, un ID task e un ID tenant, e spingi la spesa nella stessa dashboard delle altre unit economics. Un agent che costa più di quanto risparmia è una feature che aspetta di essere spenta.

Il pattern sotto i dodici

Rileggi la lista e una forma si ripete. I sistemi multi-agent falliscono quando il team li tratta come chatbot più grandi invece che come sistemi distribuiti con un contatore di token. La versione competente di questo lavoro assomiglia di più a una piccola architettura a microservizi con coda che a una conversazione Claude, con budget, confini di proprietà, verificatori, retry, suite di eval e tracce. Il modello è un componente. Gli altri dodici sono il sistema.