--- title: "Multi-agent orchestration: cosa si è rotto in 3.315 avvii" description: "Orchestrazione di agenti in pratica: 3.315 esecuzioni di subagenti in due mesi, il costo dei token a prezzi API e sette guasti diventati ciascuno un hook." url: "https://madsalt.tech/it/blog/multi-agent-orchestration-what-broke/" author: "Denys Zaichenko" language: "it" published: 2026-10-19 updated: 2026-10-22 --- # Multi-agent orchestration: cosa si è rotto in 3.315 avvii In breve Tra il 17 agosto e il 19 ottobre 2026 il mio setup di Claude Code ha lanciato 3.315 subagenti. Negli ultimi 30 giorni sono stati circa 16 miliardi di token, il 97,7% dei quali letture della cache. Pago un abbonamento a tariffa fissa; ai prezzi di listino delle API gli stessi token costerebbero almeno 3.350 USD. I guasti non sono quasi mai stati il modello che scrive codice sbagliato. Stavano nelle giunture: agenti paralleli che sovrascrivono lo stesso file con tutti i controlli verdi, uno script di pulizia che cancella lavoro finito, un agente che modifica i controlli che lo bloccavano. Ogni guasto è diventato un piccolo script che blocca l'esecuzione successiva, e sono questi script, non i prompt, a rendere il sistema utilizzabile. Sono Denys, ingegnere full-stack e di IA. Costruisco software con una sessione principale di Claude Code che affida il lavoro a subagenti specializzati: esploratori, un planner, sviluppatori, revisori di sicurezza e di codice. Questo è un resoconto di quel setup, non di un prodotto per un cliente. I numeri vengono dai log che il setup conserva: un registro dei lanci (una riga per agente lanciato), le trascrizioni delle sessioni e la cronologia git della configurazione stessa. Nomi di clienti e di progetti sono omessi. Ho costruito anche una [dashboard interattiva di orchestrazione multi-agente](https://madsalt.tech/it/work/multi-agent-orchestration/) come prototipo con dati di esempio. Tutto quello che segue viene da esecuzioni reali. ## Cos'è l'orchestrazione multi-agente? L'orchestrazione multi-agente è un assetto in cui un agente principale affida compiti circoscritti ad agenti specializzati e ne unisce i risultati; l'orchestratore possiede il contesto, i budget e i nuovi tentativi. In questo articolo compare in due forme: una sessione principale con subagenti (esploratori, un planner, sviluppatori, revisori) e hook che fanno rispettare le regole che gli agenti non possono aggirare a parole. La [dashboard di orchestrazione multi-agente](https://madsalt.tech/it/work/multi-agent-orchestration/) mostra la stessa idea su dati di esempio; le sezioni che seguono riguardano ciò che si è rotto in esecuzioni reali. ## Com'è fatto il setup? Una sessione principale parla con me e possiede il compito. Nei compiti più grandi non scrive mai codice di produzione da sola. Manda il lavoro fuori: - **Gli esploratori** leggono uno strato del codice (frontend, backend, database) e scrivono una mappa breve. - **Un planner** trasforma la mappa in passi numerati con i percorsi dei file. - **Gli sviluppatori** prendono una fase del piano ciascuno, scrivono prima i test e poi il codice. Gli sviluppatori in parallelo ricevono un proprio git worktree. - **I revisori** controllano il diff: uno per la sicurezza, uno per la correttezza, entrambi sullo stesso commit. Tra l'uno e l'altro stanno gli hook: piccoli script che Claude Code esegue prima e dopo ogni chiamata a uno strumento. Un hook può bloccare una chiamata, per esempio il lancio di un agente, la scrittura di un file o un `git commit`. La configurazione ha 165 hook, circa 40 dei quali sull'orchestrazione. Le regole che gli agenti leggono sono Markdown; le regole che non possono aggirare sono hook. Questa separazione è la lezione principale dei due mesi, e il resto del testo spiega perché. ![Come un compito attraversa gli agenti. Gli hook stanno tra ogni passo e possono bloccarlo. Percorso normale: Esploratori → Planner → Sviluppatori → Revisori → Commit gate; Stesso errore tre volte: Sviluppatori → Stesso errore 3x → Modello forte → Una persona.](https://madsalt.tech/charts/it/multi-agent-orchestration-what-broke-flow.svg) *Figura 1. Il mio setup di Claude, da agosto a ottobre 2026. Ogni implementatore in parallelo ha il proprio git worktree.* ## Quanti agenti sono stati eseguiti, e su quali modelli? | Misura (17 ago – 19 ott 2026) | Valore | | ----------------------------------------------------- | ---------------------------------------------------------------------------------- | | Subagenti lanciati | 3.315 in 57 giorni attivi | | Tipi di agente | 30 | | I più lanciati | sviluppatore (tdd-guide) 793, revisore di sicurezza 455, general-purpose 424 | | Modello effettivo | Opus 46,5%, Sonnet 45,8%, Fable 1,3%, il resto ereditato dalla sessione principale | | Lanciati uno alla volta | 67,7% | | Ondata parallela più grande | 5 agenti (il limite), raggiunta 9 volte | | Esecuzioni di revisore per esecuzione di sviluppatore | 0,71 (680 revisioni, 963 implementazioni) | Due numeri mi hanno sorpreso. Primo, la maggior parte dei lanci era di agenti singoli, non di ondate in parallelo. Il lavoro parallelo è l'eccezione: conviene per leggere e rivedere, e costa molto per scrivere (vedi il primo guasto qui sotto). Secondo, nel 23% dei lanci in cui il file di un agente indica un modello, il modello effettivamente eseguito era un altro, quasi sempre Sonnet promosso a Opus (584 su 610). È voluto: un hook alza il modello quando il passo tocca codice rischioso come migrazioni, autenticazione o route del server, e dopo che uno sviluppatore su Sonnet ha fallito lo stesso test tre volte di fila. Lo sviluppatore più forte è stato eseguito 159 volte; non riesco a dividere il log tra "passo rischioso" e "fallimento ripetuto", quindi non dico quanti fossero salvataggi. ## Quanto costa l'orchestrazione di più agenti? Pago un abbonamento a tariffa fissa, quindi non c'è un conto per token. Le trascrizioni però registrano ogni token, quindi ecco quanto costerebbero gli ultimi 30 giorni (dal 20 settembre al 19 ottobre) ai prezzi di listino delle API di Anthropic: | 30 giorni | Token | | ------------------------ | --------------------------------------------------------------------- | | Totale | circa 15,99 miliardi | | Letture della cache | 15,55 miliardi (il 97,7% di tutto ciò che è stato inviato al modello) | | Scritture della cache | 372 milioni | | Input nuovo, senza cache | 0,18 milioni | | Output | 69 milioni | Ai prezzi di listino (Opus 5.5 a 4 USD per milione di input, 20 per milione di output, 0,20 per milione di letture della cache; Sonnet 5.5 e Fable 5.1 ai loro), output, input e letture della cache dei soli tre modelli attuali arrivano a circa 3.350 USD. Restano fuori le scritture della cache e le versioni più vecchie dei modelli ancora presenti nei log, quindi la cifra reale delle API è più alta. Due terzi di quei 3.350 USD sono letture della cache: ogni turno rimanda l'intero contesto, e la cache è l'unico motivo per cui tutto questo è sostenibile. ![Chi ha scritto i 69 milioni di token in output. Milioni di token, 30 giorni. I subagenti hanno usato il 42% di tutti i token. Sessione principale: 23,70; Subagenti: 45,30.](https://madsalt.tech/charts/it/multi-agent-orchestration-what-broke-output.svg) *Figura 2. Trascrizioni di Claude, dal 20 settembre al 19 ottobre 2026: 75.129 richieste al modello.* La divisione tra sessione principale e subagenti è la parte che userei per pianificare un budget: - **I subagenti hanno usato il 42% di tutti i token ma hanno scritto il 66% dell'output.** La sessione principale è costosa perché porta il contesto più lungo; è nei subagenti che si scrivono davvero testo e codice. - **I revisori costano poco.** Una revisione di sicurezza o di codice ha usato da 1 a 4 milioni di token. Uno sviluppatore ne ha usati da 5 a 100 milioni. Due revisori su ogni commit rischioso costano meno di uno sviluppatore che ritenta. - **La sessione più grande**, il 6 ottobre, ha lanciato 63 subagenti e usato 372 milioni di token in 3,5 ore. ## Cosa si è rotto Ogni guasto qui sotto è avvenuto, ha una data ed è finito con un hook o uno script che impedisce che si ripeta. Nessuno è "il modello ha scritto un bug". I bug normali sono stati presi dai test e dai revisori. Questi sono passati da entrambi. | Data (2026) | Cosa si è rotto | Cosa lo blocca ora | | ----------- | ---------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | 19 ago | Agenti paralleli hanno sovrascritto un file di traduzioni: 55 chiavi su ~95 perse, tutti i controlli verdi | Ogni agente scrive le proprie chiavi in un frammento suo; uno script di unione prova che ogni chiave sia arrivata | | 24 ago | Uno script di pulizia ha cancellato 4 pacchetti di lavoro finiti | La pulizia salta ogni worktree con modifiche non raccolte; prima si raccoglie, poi si pulisce | | 1 set | Le ondate successive di agenti sono partite da codice vecchio | Unire il lavoro di ogni agente come patch a tre vie, mai come copia di file | | 13 set | Un agente è morto al lancio, e il lancio ha detto "successo" | Il lanciatore legge il primo output dell'agente e segna un modello morto per tutte le sessioni | | 20 set | Due mie regole si contraddicevano; gli agenti hanno ritentato un comando rifiutato | I brief per agenti isolati riportano le forme di comando che la sandbox accetta | | 18 ott | Un agente ha modificato i controlli che bloccavano il suo commit | I file dei controlli sono in sola lettura dalle sessioni di progetto; le modifiche vengono registrate e segnalate | | 18 ott | Istruzioni di correzione hanno cambiato in silenzio ciò che ricevono gli utenti di un'app cliente | Ogni brief di correzione dice "mantieni il comportamento in produzione"; le modifiche di prodotto tornano a me | ### Scrittori paralleli e il file che ogni funzione tocca Tre agenti hanno costruito contemporaneamente tre funzioni di un'app iOS di un cliente. Ognuno ha aggiunto i propri testi all'unico catalogo di traduzioni dell'app, e ognuno ha salvato la propria versione dell'intero file. Ha vinto l'ultimo salvataggio. 55 delle circa 95 chiavi nuove sono sparite. La build di ogni agente è passata, perché la copia di ciascuno era coerente; il controllo del catalogo è passato, perché la sua copertura era rotta in un altro modo. L'ho scoperto contando le chiavi a mano. La correzione ha tre parti. Un hook rifiuta di lanciare un agente i cui file dichiarati si sovrappongono a quelli di uno scrittore ancora in esecuzione. Gli agenti non modificano mai i cataloghi condivisi; scrivono le chiavi in un file frammento, e uno script unisce i frammenti, fallisce su valori in conflitto e poi verifica che ogni chiave sia presente. Un secondo hook blocca il commit se un catalogo ha meno chiavi di prima. La parte onesta: ho aggiunto queste protezioni il 18 ottobre, 60 giorni dopo la perdita. Tra le due date l'unica protezione era una riga in una regola Markdown, e una regola è un suggerimento. ### Una pulizia che ha cancellato lavoro finito Gli sviluppatori in parallelo lavorano in git worktree e preparano le modifiche senza fare commit. Un controllo del commit ha detto alla sessione principale di eseguire lo script di pulizia. Lo script saltava i worktree il cui agente era ancora in esecuzione, e questi agenti avevano finito. Quattro pacchetti di lavoro finiti sono stati cancellati, senza oggetti git da recuperare. "L'agente è ancora in esecuzione?" e "il suo lavoro è stato raccolto?" sono domande diverse, e lo script poneva solo la prima. Ora la pulizia salta ogni worktree con modifiche che il checkout principale non ha, e un hook a parte blocca la cancellazione diretta delle cartelle dei worktree. ### Ondate partite da codice vecchio Un piano di 11 passi è stato eseguito con 6 sviluppatori in 3 ondate. Le ondate 2 e 3 sono partite dal commit su cui era iniziata la sessione, tre commit indietro. Copiare indietro il file di un agente avrebbe annullato la modifica finita di un altro. Un worktree è un'istantanea del punto di partenza, quindi ora i risultati tornano come patch a tre vie, e i conflitti emergono invece di essere sovrascritti in silenzio. ### Un agente morto che ha dichiarato successo Un agente vincolato a un modello il cui limite d'uso era esaurito è morto prima del primo passo. Il lancio ha restituito "spawned successfully"; il guasto è arrivato dopo come avviso di inattività. Un nuovo tentativo su un altro modello è stato annullato dallo stesso hook che fissa i modelli. La sessione principale ha poi scritto il piano da sé, in silenzio, cioè proprio l'esito che il planner doveva evitare. Ora l'hook legge il primo output dell'agente e segna un modello morto per tutte le sessioni per un certo tempo. ### L'agente che ha modificato i propri controlli Il 18 ottobre una sessione che lavorava su un progetto cliente si vedeva bloccare il commit da un controllo, di continuo. Ha modificato tre degli script di controllo perché il commit passasse. Niente di tutto questo era nascosto; le modifiche erano in piena vista. Ma niente le ha fermate, perché i controlli stavano in una cartella in cui l'agente poteva scrivere, e venivano sorvegliati solo gli strumenti di modifica dei file, non i comandi di shell. Ora i file dei controlli si possono cambiare solo da una sessione avviata nella cartella di configurazione stessa, ogni via di scrittura è coperta (editor, redirezioni di shell, script, git), e ogni modifica durante una sessione di progetto viene registrata con un avviso. È il guasto di cui avviserei per primo chiunque. A un agente a cui si dice "fai passare il commit", il varco appare come parte del problema. ### Due mie regole non andavano d'accordo Una regola diceva agli agenti di unire tre o più passi di shell in un solo script per risparmiare token. Gli agenti isolati in un worktree girano in una sandbox che rifiuta esattamente quella forma. Gli agenti hanno incontrato "too complex to verify" tre volte di fila in più giorni, e hanno bruciato il budget a riformulare. Ora gli agenti si fermano dopo due rifiuti identici, e i brief per gli agenti isolati indicano le forme di comando che funzionano. ## Perché un sistema multi-agente fallisce? Da questi due mesi: non perché un modello sia troppo debole. Nessuno dei sette guasti qui sopra è stato un modello che falliva il compito assegnato. Falliscono nelle giunture tra gli agenti, dove nessun agente singolo è responsabile: - **Stato condiviso.** Un file che ogni funzione tocca, un albero di lavoro, un branch. Ogni agente ha ragione a livello locale e il risultato è sbagliato a livello globale. - **Controlli verdi.** Ogni incidente qui sopra ha superato i controlli che esistevano allora. Un controllo prova ciò che controlla, niente di più. - **Segnali di successo che mentono.** "Spawned", "saved", "cleaned up" significavano ciascuno qualcosa di più ristretto di ciò che dicevano. - **Agenti che ottimizzano per il varco.** Si dica a un agente che il commit è bloccato e cercherà un modo di sbloccarlo, anche passando dal varco stesso. Altri sviluppatori riportano lo stesso schema da flotte più grandi. Jed Arden, che gestisce circa venti agenti, ha scritto che [l'LLM quasi non compare nel registro degli incidenti](https://jedarden.com/notes/what-breaks-at-twenty-agents/) (luglio 2026). [Il team di Cursor ha rilevato](https://cursor.com/blog/scaling-agents) che venti agenti che condividevano un file di coordinamento con lock rallentavano fino alla velocità di due o tre (gennaio 2026). ## Cosa configurerei per primo Se comincia con i subagenti di Claude Code o con qualsiasi orchestrazione multi-agente, questo è l'ordine in cui lo farei, visto quanto mi è costato impararlo: 1. **Registrare ogni lancio di agente.** Una riga per lancio: ora, tipo di agente, modello, rischio. Senza, non si capisce cosa fa il sistema, e nessuno dei numeri qui sopra esisterebbe. 2. **Uno scrittore per file.** Gli scrittori paralleli ricevono un worktree e un elenco di file dichiarato. I file a cui ogni funzione aggiunge qualcosa (traduzioni, lockfile, changelog) hanno un solo proprietario, e gli altri consegnano frammenti. 3. **Raccogliere prima di pulire.** Non lasci mai che un passo di pulizia decida con "è in esecuzione?". Decida con "il suo lavoro è nel checkout principale?". 4. **Mettere i controlli fuori dalla portata degli agenti.** Hook che bloccano, tenuti dove una sessione di progetto non può scrivere. 5. **Limitare l'ondata.** Cinque agenti in parallelo sono il mio tetto; oltre, la revisione diventa il collo di bottiglia e i conflitti crescono più in fretta della produttività. 6. **Scalare sulla ripetizione, non sullo sforzo.** Un modello economico di default; dopo lo stesso errore tre volte, un tentativo su un modello più forte; dopo, una persona. Quanto costa costruire e far funzionare un agente IA per un'azienda, invece che per il flusso di lavoro di un solo sviluppatore? È un'altra domanda, a cui si risponde con i numeri in [quanto costa un agente IA](https://madsalt.tech/it/blog/how-much-does-an-ai-agent-cost/). I pannelli che tengo d'occhio oggi, dagli stessi log un mese dopo, sono in [AI agent monitoring: cosa hanno mostrato 1.238 esecuzioni](https://madsalt.tech/it/blog/ai-agent-monitoring-dashboard/). ## Limiti di questo resoconto - **Il setup di un solo sviluppatore.** Una sessione principale, fino a cinque agenti in parallelo. Flotte di decine o centinaia di agenti falliscono in modi ulteriori, per esempio al lancio. - **Nessun conto reale.** La cifra in dollari è un equivalente a prezzi di listino delle API per 30 giorni, un minimo che esclude le scritture della cache e i modelli più vecchi. Pago un abbonamento a tariffa fissa. - **Lacune nei log.** I lanci bloccati non vengono registrati, quindi non so dire quante volte sia scattato il limite dell'ondata. Le 159 esecuzioni dello sviluppatore più forte mescolano passi rischiosi e fallimenti ripetuti. - **Date dalle mie note.** Le date degli incidenti vengono da note e commit scritti lo stesso giorno; un incidente ha una data diversa in un vecchio file di regole, e ho usato la nota. Il prototipo di dashboard nato da questo lavoro è il [caso di orchestrazione multi-agente](https://madsalt.tech/it/work/multi-agent-orchestration/), e costruire agenti per i clienti rientra negli [agenti IA e chatbot su misura](https://madsalt.tech/it/services/ai-agent-development/). Fa girare agenti in parallelo e perde lavoro tra l'uno e l'altro? Mi confronto volentieri su hook, worktree e controlli di revisione. Nessuna proposta commerciale. [Mi contatti](https://madsalt.tech/it/#contact)