Claude Code Dynamic Workflows: orchestrare agenti su larga scala

Il 28 maggio 2026 Anthropic ha rilasciato Claude Code 2.1.154 con una funzionalità che cambia il modo in cui il coding agentico scala: i dynamic workflows. Invece di affrontare un compito difficile passo dopo passo, Claude ora scrive il proprio script di orchestrazione e distribuisce il lavoro su decine o centinaia di subagenti in background in un'unica sessione.

I dynamic workflows in Claude Code sono script di orchestrazione JavaScript che Claude scrive per un compito che descrivi. Un runtime in background esegue lo script, coordina molti subagenti in parallelo, mantiene lo stato intermedio nelle variabili di script e verifica i risultati prima che arrivino a te.

Sembra un piccolo aggiornamento della CLI. Non lo è. Sposta l'orchestrazione fuori dal turno di chat e dentro il codice — e per i team che fanno coding agentico su scala di produzione, cambia il calcolo di capacità e costo. Ecco cosa è stato effettivamente rilasciato, cosa significa sul piano architetturale e come uno studio di sviluppo dovrebbe pensare all'adozione.

Cosa sono davvero i dynamic workflows

Un dynamic workflow è uno script JavaScript che orchestra subagenti su larga scala; Claude scrive lo script per il compito che descrivi, e un runtime lo esegue in background mentre la tua sessione resta reattiva (Claude Code Docs).

La meccanica conta. Nel vecchio modello, una sola conversazione coordinava tutto: ogni risultato di subagente tornava in una finestra di contesto, e la finestra si riempiva in fretta. I dynamic workflows invertono questo. La logica di orchestrazione — cicli, ramificazioni, decisioni sul numero di agenti, passaggi di verifica — vive nelle variabili di script, e la finestra di contesto del modello riceve solo i risultati condensati (TechTimes). Lo script tiene lo stato; il modello tiene il giudizio.

Secondo Anthropic, Claude «scrive i propri script di orchestrazione, distribuisce il lavoro su decine o centinaia di subagenti paralleli in un'unica sessione e verifica i propri risultati prima che qualcosa arrivi a te» (Anthropic). La research preview supporterebbe fino a 1.000 subagenti per workflow (Pasquale Pillitteri). Li attivi e li ispezioni con il nuovo comando /workflows (Claude Code Changelog).

È lo stesso spostamento che avevamo segnalato quando il cockpit multi-agente è arrivato in Claude Code Agent View: l'unità di lavoro non è più un prompt, è una flotta coordinata.

Perché è un salto di paradigma, non una patch

Il vincolo che i dynamic workflows infrangono è il collo di bottiglia della finestra di contesto singola — il tetto rigido su quanto lavoro parallelo una sola conversazione potesse mai coordinare.

Prima dei dynamic workflows, il numero di subagenti che un compito poteva usare era limitato da ciò che una singola conversazione poteva seguire. Spostando il coordinamento in uno script, Claude Code rimuove quel tetto e consente a una sessione di orchestrare centinaia di agenti contemporaneamente.

Claude Code offre ora tre primitive di collaborazione distinte — Dynamic Workflows, Subagents e Agent Teams — e scegliere quella giusta per la struttura del tuo problema non è più un optional (Ken Huang). I Subagents gestiscono la delega circoscritta. Gli Agent Teams gestiscono la collaborazione persistente basata sui ruoli. I dynamic workflows gestiscono il caso in cui un compito ha semplicemente bisogno di più agenti di quanti una conversazione possa coordinarne.

Le affermazioni sulla scala sono reali, estreme al limite superiore. Un caso riportato ha visto un workflow generare 750.000 righe di Rust in 11 giorni — non replicabile su ogni progetto, ma un segnale chiaro di dove si colloca ora il tetto (Pasquale Pillitteri). La formulazione di Anthropic è netta: un lavoro che normalmente pianificheresti in trimestri può concludersi in giorni (r/ClaudeAI).

Questo si aggancia direttamente alla tesi che abbiamo sostenuto in Il report 2026 di Anthropic sul coding agentico: l'era dell'orchestrazione: il fattore differenziante non è più la qualità grezza del modello, è l'orchestrazione.

I dynamic workflows sono arrivati con Opus 4.8

Claude Code 2.1.154 non ha rilasciato i dynamic workflows da soli — sono arrivati insieme a Claude Opus 4.8, che ora va di default in high effort, con /effort xhigh disponibile per i compiti più difficili (Classmethod).

L'abbinamento è deliberato. Un modello orchestratore più forte che scrive gli script significa decisioni migliori sul numero di agenti e passaggi di verifica più stretti. Il livello di modello in sé l'abbiamo trattato in La prossima ondata di Anthropic: Opus 4.8, Sonnet 4.8, Mythos; la novità qui è ciò che quel modello ora fa per te in background.

Due note operative. Primo, l'high effort di default cambia il consumo di token — mettilo a budget. Secondo, dopo la 2.1.154 sono seguite rapidamente release di punto, comprese correzioni sul comportamento di Opus 4.8, quindi usa l'ultima Claude Code invece di fissarti sul primo rilascio (Claude Code Changelog).

Il calcolo di capacità e costo cambia

I dynamic workflows cambiano l'equazione del costo tanto quanto quella della capacità: centinaia di agenti paralleli aumentano il throughput, ma anche il conto se non governi il numero di agenti.

I subagenti paralleli aumentano sia la velocità sia il costo. Per mantenere economici i dynamic workflows occorre governare quanti agenti un compito avvia e verificare i risultati a basso costo, anziché lasciare che ogni compito si espanda fino al numero massimo di agenti.

L'analisi dei costi degli agenti Claude Code mostra che la vera domanda non è più il prezzo di un singolo completamento, ma quanto costano davvero le sessioni parallele — e che i risparmi maggiori vengono dall'adeguare il numero di agenti alla struttura del compito, non dal tagliare le capacità (CloudZero). È la stessa lente del «costo per risultato accettato» che abbiamo usato in L'economia dei token di Anthropic.

Per un'agenzia, lo spostamento è strutturale. Una fatturazione costruita sulle ore di sviluppo si concilia male con uno strumento che comprime un trimestre di lavoro in giorni. La posizione difendibile è prezzare l'efficienza di orchestrazione e i risultati verificati — il che funziona solo se puoi dimostrare che l'output è corretto.

Come uno studio di sviluppo dovrebbe adottarlo

Adotta i dynamic workflows dove il lavoro è davvero parallelo e verificabile — grandi refactoring, generazione di test su larga scala, migrazioni multi-file — e mantieni un gate di approvazione umano su tutto ciò che tocca la logica di business centrale.

Il passaggio di verifica è tutto il gioco. Anthropic ha integrato l'auto-verifica nel runtime del workflow, ma l'auto-verifica non è la stessa cosa della tua verifica. La disciplina che abbiamo sostenuto in Il tokenmaxxing ha bisogno di reviewmaxxing vale ora ancora di più: più agenti che producono più codice significano che il throughput di revisione, non quello di generazione, diventa il collo di bottiglia.

Sequenza pratica per i team:

Inizia con compiti circoscritti e paralleli. Generazione di test su un modulo, un aggiornamento di dipendenza su molti file, un passaggio di documentazione. Facili da verificare, raggio d'impatto basso.
Usa le sessioni in background per non bloccare le persone. Elenchi gli agenti in esecuzione con /sessions e ne riprendi uno con /switch <session-id> (MindStudio).
Tratta gli agenti di lunga durata come processi di lunga durata. I pattern per gli agenti in background in Claude Code 2.1 somigliano più alla gestione di servizi che ai turni di chat — osservabilità e arresto pulito contano (CallSphere).
Governa il numero di agenti. Di default la flotta più piccola che risolve il compito; riserva le esecuzioni con centinaia di agenti al lavoro dimostrabilmente parallelo.

Niente di tutto questo è vibe coding. È la disciplina ingegneristica che abbiamo descritto in L'ingegneria agentica non è vibe coding, ora con un raggio d'impatto molto più ampio.

Dove i dynamic workflows possono andare storti

La modalità di fallimento non è il codice scadente — è codice non revisionabile a un volume per cui nessun team umano era dimensionato, prodotto più in fretta di quanto il tuo processo di revisione possa assorbire.

Il rischio principale dei dynamic workflows è che il volume superi la verifica. Centinaia di agenti possono generare in un giorno più modifiche di quante un team possa revisionare in modo utile, così il vincolo passa dalla velocità con cui scrivi il codice alla velocità con cui puoi fidartene.

Tre trappole vanno pianificate prima di attivare tutto questo in una codebase di un cliente. La prima è il debito di revisione. Quando un workflow consegna un grande insieme di modifiche coordinate, la tentazione è fidarsi dell'auto-verifica del runtime e fare merge. L'auto-verifica intercetta gli errori meccanici — test che falliscono, build rotte — ma non intercetta un'implementazione dall'aspetto corretto del requisito sbagliato. Quel giudizio deve restare tuo.

La seconda è l'osservabilità. Le sessioni in background girano in modo indipendente dalla tua chat, è il punto, ma significa anche che un workflow può lavorare a lungo prima che tu noti che è andato fuori strada. I pattern che emergono attorno agli agenti in background in Claude Code 2.1 somigliano più alla gestione di servizi di lunga durata che all'invio di messaggi di chat — vuoi logging, controlli di stato e arresto pulito, non fiducia cieca (CallSphere). Sapere come elencare e riprendere le sessioni con /sessions e /switch è il minimo, non il traguardo.

La terza è la sorpresa sui costi. Un workflow che di default usa il numero massimo di agenti su un compito che non ne aveva bisogno brucia budget senza valore aggiunto. Scegliere la flotta più piccola che risolve davvero il problema è insieme una decisione di architettura e una decisione finanziaria. Gli studi che trattano questi tre punti come requisiti ingegneristici centrali, non come ripensamenti, sono quelli che mettono i dynamic workflows in produzione senza rimpianti.

FAQ

**Cosa sono i dynamic workflows in Claude Code?** I dynamic workflows sono script di orchestrazione JavaScript che Claude scrive per un compito. Un runtime in background esegue molti subagenti in parallelo, mantiene lo stato intermedio nelle variabili di script e restituisce un risultato verificato e coordinato ([Claude Code Docs](https://code.claude.com/docs/en/workflows)).

Quanti subagenti può usare un dynamic workflow? Anthropic descrive decine o centinaia di subagenti paralleli per sessione, e la research preview supporterebbe fino a 1.000 (Anthropic).

In cosa differiscono i dynamic workflows da subagents e agent teams? Sono tre primitive distinte: i subagents per la delega circoscritta, gli agent teams per il lavoro persistente basato sui ruoli e i dynamic workflows per compiti che richiedono più agenti di quanti una conversazione possa coordinarne (Ken Huang).

Quale versione di Claude Code ha introdotto i dynamic workflows? Claude Code 2.1.154, rilasciata il 28 maggio 2026, insieme a Claude Opus 4.8 (Classmethod).

I dynamic workflows costano di più? Possono. Centinaia di agenti paralleli aumentano throughput e conto; i risparmi vengono dall'adeguare il numero di agenti alla struttura del compito (CloudZero).

In sintesi

I dynamic workflows sono il primo vero salto di paradigma in Claude Code dai subagents, perché l'orchestrazione ora vive nel codice invece che nel turno di chat. I team che vinceranno con questo non saranno quelli che avviano più agenti — saranno quelli con la disciplina di verifica per fidarsi di ciò che torna indietro. Se stai scalando il coding agentico e vuoi un'orchestrazione costruita su gate di revisione anziché su throughput cieco, è esattamente il lavoro di ingegneria che facciamo in Context Studios.