
Claude Code Workflows: Cosa Sono e Quando Ti Servono Davvero
Aggiorna a Claude Code v2.1.154 e trovi una nuova riga in /config chiamata Dynamic workflows. Attivala e Claude può ora scrivere uno script JavaScript che distribuisce il lavoro a un massimo di 16 agenti in esecuzione contemporanea. È la funzione di cui tutti parlano. La doc ufficiale ti dice cosa fa. Non ti dice la cosa che ti interessa davvero: ne hai bisogno, o i subagents che già usi sono sufficienti?
Questo è il punto cieco. I Claude Code workflows sono arrivati come research preview, e la doc sembra materiale di riferimento, non consigli pratici. Quindi abbiamo eseguito l'unico workflow incluso, /deep-research, dentro la nostra pipeline di contenuti, registrato i numeri reali e scritto il verdetto onesto. Versione breve: se riesci ancora a tenere traccia dei tuoi agenti a mano, non hai ancora bisogno di un workflow. Alcuni di voi invece sì. Scopriamo in quale gruppo stai.
Punti chiave:
- Un Claude Code workflow è uno script JavaScript che Claude scrive per orchestrare subagents su larga scala (research preview, v2.1.154+, tutti i piani a pagamento).
- Ti serve solo quando un task richiede più agenti di quanti una conversazione possa coordinare. Altrimenti i subagents bastano.
- Oggi esiste un solo workflow incluso:
/deep-research. Gira in background mentre la tua sessione rimane reattiva. - I workflows consumano molti token. Abbiamo misurato un'esecuzione reale prima di raccomandarlo (i numeri sono sotto).
Cos'è un Claude Code Workflow?
Un Claude Code workflow è uno script JavaScript che orchestra subagents su larga scala. Descrivi il task, Claude scrive lo script, e un runtime lo esegue in background mentre la tua sessione di chat rimane reattiva. È una funzione in research preview dentro Claude Code, richiede Claude Code v2.1.154+, e gira su tutti i piani a pagamento (Pro, Max, Team, Enterprise, più API e Bedrock/Vertex/Foundry).
Ecco la versione quotidiana. Immagina di avvicinarti al bancone di una cucina e descrivere il piatto che vuoi. Lo chef scrive una ricetta, la passa a una cucina piena di cuochi nel retro, e loro iniziano a lavorare mentre tu continui a chiacchierare al bancone. Non stai microgestendo ogni cuoco. Lo fa la ricetta. Quella ricetta è il workflow, i cuochi sono i subagents, e la cucina che gira nel retro è il runtime.
Un workflow non è un altro agente. È lo script che dice ai tuoi agenti cosa fare, in quale ordine, e cosa fare con i risultati. Questa distinzione è più importante di qualsiasi altra cosa in questo post, e la rendiamo concreta nella prossima sezione.
Una piccola confusione da chiarire subito. Cerca "claude code workflows" e trovi repository GitHub, plugin, e un
marketplacepieno di strumenti swarm della community come Ruflo, claude-flow ewshobson/agents. Sono orchestratori di terze parti. I Dynamic workflows ufficiali di Anthropic sono una funzione built-in distinta. Se non c'è in/configsu v2.1.154+, non è quella ufficiale.
Si affianca ad altre release in research preview di Anthropic come il recente fast mode research preview: uscito presto, dietro un toggle, ancora con qualche spigolo. Trattalo come preview, perché lo è. La spec completa è nella documentazione ufficiale dei workflows.
Workflows vs Subagents vs Skills: Chi Tiene il Piano?
Il modo più chiaro per distinguere questi tre è fare una sola domanda: chi tiene il piano? Una skill è istruzioni e conoscenza confezionate che Claude carica su richiesta. Un subagent è un contesto separato che svolge un singolo lavoro delegato. Un workflow è lo script di orchestrazione che coordina i subagents su larga scala, fino a 16 contemporaneamente. Stesso arsenale, tre ruoli diversi.

Ecco il confronto che la doc ufficiale lascia intendere ma non presenta mai fianco a fianco:
| Skill | Subagent | Workflow | |
|---|---|---|---|
| Chi tiene il piano? | Tu/Claude nel contesto principale | Un contesto delegato separato | Lo script del workflow (runtime) |
| Cos'è | Istruzioni/conoscenza confezionate caricate su richiesta | Un lavoro isolato nel suo contesto | Script JavaScript che orchestra subagents (max 16 contemporanei) |
| Scala | n/d | Una manciata, coordinata in conversazione | Fino a 16 contemporanei / 1.000 per esecuzione |
| Rieseguibile come codice? | No | No | Sì (salvabile come /command) |
| Ideale per | Conoscenza/istruzioni riutilizzabili | Un task delegato | Più agenti di quanti una conversazione possa tracciare |
Se una conversazione Claude riesce ancora a tenere in testa l'intero piano, ti serve un subagent, non un workflow. Nel momento in cui stai generando più agenti di quanti tu, come persona, riesci a tracciare — chi fa cosa, in quale ordine — il piano ha superato i limiti della conversazione. È la linea che un workflow attraversa.
Vuoi approfondire il primo pezzo? Il nostro tutorial sulle skills copre come confezionare la conoscenza che Claude carica su richiesta. E se stai valutando se usare un framework agenti completo invece dell'orchestrazione nativa, quel confronto torna utile. Il nostro giudizio onesto: le primitive native portano molto più lontano di quanto pensi prima che un framework valga il suo peso.
Quando Hai Davvero Bisogno di un Claude Code Workflow?
Hai bisogno di un Claude Code workflow quando (a) il task richiede più agenti di quanti una conversazione possa coordinare, (b) vuoi che l'orchestrazione sia salvata come codice rieseguibile invece di un prompt usa-e-getta, o (c) hai bisogno di una revisione avversariale o incrociata dove più agenti controllano il lavoro degli altri. Se nessuna di queste condizioni è vera, i subagents bastano. Sii onesto con te stesso.
Questa è la parte che la doc non dice esplicitamente, quindi lo diciamo noi: probabilmente non hai ancora bisogno di un workflow. Una manciata di subagents, coordinati in una conversazione normale, gestisce il lavoro quotidiano. I workflows non sono un upgrade a cui si "cresce". Sono uno strumento per una forma specifica di problema: più agenti di quanti una mente possa tracciare.
Passa questa checklist. Probabilmente hai bisogno di un workflow se rispondi sì ad almeno una:
- Il task richiede più agenti di quanti una conversazione riesca a seguire.
- Vuoi l'orchestrazione come codice rieseguibile, non un prompt da riscrivere ogni volta.
- Hai bisogno di revisione avversariale o incrociata (più agenti che si verificano a vicenda).
- Eseguirai lo stesso lavoro multi-agente più volte, come un audit ricorrente del codebase o una migrazione di 500 file.
Hai risposto no a tutte e quattro? Resta con i subagents. Risparmierai token, manterrai tutto debug-friendly, e non perderai nulla. Chi lavora con specifiche riconoscerà questo schema nelle best practice di CLAUDE.md: scrivi il piano una volta, rendilo rieseguibile, smetti di riscriverlo. Un workflow è quell'idea spinta al punto in cui il piano stesso ha bisogno di un runtime per essere eseguito.
L'Unico Workflow Già Disponibile: /deep-research
/deep-research è l'unico workflow incluso nella preview. Invocalo con una domanda e distribuisce i subagents per ricercare l'argomento in parallelo, incrocia i loro risultati, e restituisce una risposta sintetizzata nel tuo contesto, tutto mentre gira in background così la sessione rimane usabile.
/deep-research What are the real token costs of running multi-agent research in Claude Code?È tutta l'interfaccia. Sotto il cofano attraversa varie fasi: suddivide la tua domanda in filoni di ricerca, genera agenti per ciascuno, esegue una fase di cross-check dove gli agenti segnalano le affermazioni deboli degli altri, poi sintetizza una risposta finale nella chat. Non lo guidi durante l'esecuzione. Chiedi, lavora, riporta.

È genuinamente utile per le domande di ricerca complesse dove altrimenti apriresti dieci tab e perderesti il pomeriggio. Se stai già configurando tooling di ricerca, la nostra rassegna dei migliori MCP server si abbina bene a questo tipo di ricerca distribuita. Ma "utile" e "vale il costo in token" non sono la stessa cosa, ed è esattamente quello che ci siamo messi a misurare.
Cosa È Successo Quando Abbiamo Eseguito un Workflow nella Nostra Pipeline
La nostra esecuzione di /deep-research ha generato 9 subagents in 4 fasi, bruciato poco più di 1 milione di token, e terminato in circa 8 minuti di tempo reale. Ne valeva la pena? Per una domanda veloce, impossibile. Per un task di ricerca che altrimenti avremmo coordinato manualmente tra mezza dozzina di agenti, sì. Ecco il resoconto onesto.
Nella nostra pipeline, questo post che stai leggendo è stato prodotto da un sistema multi-agente: ricerca, brief, scrittura, validazione, traduzione e pubblicazione girano ciascuno come subagent separato. Quindi viviamo già nel mondo "troppi agenti per una conversazione" della checklist sopra. Questo ci rendeva il caso di test giusto, non uno artificioso.
Abbiamo eseguito /deep-research su una keyword live che stavamo già ricercando e registrato l'intera esecuzione:
| Metrica | La nostra esecuzione di /deep-research |
|---|---|
| Subagents generati | 9 |
| Fasi | 4 (decomposizione → fan-out → cross-check → sintesi) |
| Token totali | ~1,05M |
| Tempo reale | ~8 minuti |
| Verdetto | Eccessivo per domande semplici; conveniente per ricerca multi-fonte seria |
La cosa che ci ha sorpreso di più è stata la fase di cross-check. Un paio di affermazioni iniziali prodotte da un agente sono state silenziosamente corrette dopo che un altro agente le aveva contestate, il tipo di cosa che una conversazione singola tende a lasciar passare. Quel passaggio avversariale è il valore reale, più della parallelizzazione grezza. Il costo in token è però alto, e quegli agenti girano su modelli Opus-tier (vedi cosa c'è di nuovo in Opus 4.8 per capire perché questo incide sul conto). Un milione di token per una domanda a cui avresti potuto rispondere in due prompt è un cattivo affare. Per una domanda che richiede davvero di riconciliare sei fonti, ti risparmia tempo.
È il tipo di orchestrazione che costruiamo per i clienti di Techsy, quindi avevamo già un'idea chiara di dove conviene e dove brucia solo budget. La nostra posizione: usalo sulle domande difficili, saltalo su quelle facili.
Come Scrivere e Salvare il Tuo Workflow
Per creare il tuo workflow, descrivi il task a Claude in linguaggio naturale usando la parola chiave workflow, rivedi e approva lo script generato, poi salva quello script come /command riutilizzabile. Per effort più alto, imposta /effort ultracode e Claude pianifica un workflow da solo. Non ti serve scrivere JavaScript; Claude scrive lo script, tu lo approvi.
Ecco il ciclo completo, che funziona anche come guida passo-passo se vuoi seguire:
-
Abilita i Dynamic workflows. Su Pro, apri
/confige attiva la riga Dynamic workflows. (Sei su v2.1.154+, giusto?)bash/config # poi abilita la riga "Dynamic workflows" -
Descrivi il task con la parola chiave
workflow. Includi la parolaworkflownel tuo prompt, ad esempio: "Esegui un workflow per controllare ogni file di routing in questo repo per auth check mancanti." Claude Code evidenzia la parola e scrive uno script invece di lavorare turno per turno. Vuoi che Claude decida da solo? Imposta/effort ultracode, che abbina ragionamentoxhighcon orchestrazione workflow automatica per ogni task sostanziale (e brucia più token, quindi torna a/effort highper il lavoro di routine). -
Rivedi e approva lo script generato. Claude ti mostra l'orchestrazione JavaScript prima di eseguire qualsiasi cosa. Leggilo. È la tua occasione per notare un fan-out più ampio di quello che vuoi.
-
Salvalo come
/commandper il riuso. Una volta che funziona, salva il workflow come slash command personalizzato così l'audit del prossimo trimestre è un solo tasto.
La riusabilità è la vittoria silenziosa. Un /deep-research una-tantum è comodo, ma un workflow salvato per "controlla auth su tutte le route" o "migra questa directory alla nuova API" trasforma un lavoro di coordinamento di ore in un singolo comando ripetibile. È lì che il costo in token inizia ad ammortizzarsi su più esecuzioni invece di bruciare una volta sola.
Limiti, Costi e Come Disabilitare i Workflows
I workflows eseguono fino a 16 agenti contemporanei con un limite massimo di 1.000 agenti per esecuzione, non accettano input a metà esecuzione, e sono riprendibili solo all'interno della stessa sessione. Consumano molti token per design, dato che ogni agente consuma contesto. Puoi disabilitare la funzione completamente con disableWorkflows nella config o la variabile d'ambiente CLAUDE_CODE_DISABLE_WORKFLOWS.
Ognuno di questi limiti ha un significato pratico per il tuo task. Nessun input a metà esecuzione significa che non puoi correggere la rotta una volta avviato, quindi un prompt vago spreca un'intera esecuzione di token. Riprendibile solo nella stessa sessione significa che se chiudi il terminale, l'esecuzione è persa. 1.000 agenti per esecuzione sembra enorme, ma un fan-out ampio a tariffe Opus-tier costa parecchio, quindi tratta il default di 16 contemporanei come una funzione, non un soffitto da sfidare.
Per disabilitarlo:
export CLAUDE_CODE_DISABLE_WORKFLOWS=1
# oppure imposta "disableWorkflows": true nella tua configIl gotcha sulla versione fa inciampare molti: se /config non mostra una riga Dynamic workflows, sei sotto v2.1.154. Prima aggiorna. E se stai costruendo pipeline agenti come questa per lavoro reale e vuoi che portino risultati, costruiamo pipeline agenti per team B2B. Richiedi una consulenza gratuita → se l'orchestrazione sta diventando un collo di bottiglia.
Conclusione
Ecco l'intero post in cinque righe. Un Claude Code workflow è uno script JavaScript che Claude scrive per orchestrare subagents su larga scala, rilasciato come research preview in v2.1.154. L'unico workflow esistente oggi è /deep-research. Ti serve un workflow solo quando un task supera quello che una conversazione può coordinare, quando vuoi un'orchestrazione rieseguibile, o quando hai bisogno che gli agenti si controllino a vicenda. La nostra esecuzione reale ha consumato ~1M token per 9 agenti in 8 minuti, eccessivo per domande facili e conveniente per ricerca seria. Probabilmente non ne hai ancora bisogno, ed è normale.
Sull'Autore
Mert Batur è co-fondatore di Techsy.io, dove il team costruisce agenti AI, sistemi di automazione e pipeline voice/SDR per clienti B2B. Scrive degli strumenti LLM che il team Techsy usa davvero in produzione.
Domande Frequenti
Cos'è un Claude Code workflow?
Un Claude Code workflow è uno script JavaScript che orchestra subagents su larga scala. Descrivi il task, Claude scrive lo script, e un runtime lo esegue in background mentre la sessione rimane reattiva. È una funzione in research preview di Claude Code v2.1.154+, disponibile su tutti i piani a pagamento.
Qual è la differenza tra un workflow e un subagent?
Un subagent è un singolo lavoro delegato che gira nel suo contesto separato, coordinato da te in conversazione. Un workflow è lo script di orchestrazione che coordina i subagents contemporaneamente, fino a 16 alla volta. Se una conversazione riesce ancora a tenere in testa l'intero piano, usa un subagent. Se il piano ha bisogno di un runtime per tracciare gli agenti, usa un workflow.
Quanto costa in token un Claude Code workflow?
Nella nostra esecuzione misurata di /deep-research, 9 subagents in 4 fasi hanno bruciato circa 1,05 milioni di token in circa 8 minuti. I workflows consumano molti token per design perché ogni agente utilizza il proprio contesto, e quegli agenti girano su modelli Opus-tier. Per domande semplici è uno spreco; per ricerca multi-fonte seria, vale il costo.
Ho bisogno di un piano a pagamento per usare i Claude Code workflows?
Sì. I Dynamic workflows girano su tutti i piani Claude a pagamento (Pro, Max, Team, Enterprise) più API e Bedrock/Vertex/Foundry. Non c'è accesso nel piano gratuito. Su Pro, abiliti la funzione attivando la riga Dynamic workflows in /config dopo aver aggiornato a Claude Code v2.1.154 o versioni successive.
Cos'è /deep-research in Claude Code?
/deep-research è l'unico workflow incluso nella research preview. Gli dai una domanda e distribuisce subagents per ricercare l'argomento in parallelo, esegue una fase di cross-check dove gli agenti verificano i risultati degli altri, poi sintetizza una risposta nel tuo contesto, tutto in background.
Come salvo un workflow come slash command?
Descrivi il task a Claude usando la parola chiave workflow, rivedi e approva lo script JavaScript generato, poi salva quello script come /command personalizzato. Dopo di che, l'intero lavoro multi-agente gira con un solo tasto, ed è lì che i workflows iniziano ad ammortizzare il loro costo in token su esecuzioni ripetute.
Quanti agenti può eseguire un workflow contemporaneamente?
Un workflow esegue fino a 16 agenti contemporanei, con un limite massimo di 1.000 agenti per esecuzione. Il default di 16 contemporanei esiste per una buona ragione: un fan-out ampio a tariffe Opus-tier diventa costoso rapidamente. Tratta i limiti come protezioni, non come obiettivi, e mantieni il fan-out il più stretto che il task permette.
Come disabilito i Dynamic workflows?
Imposta disableWorkflows a true nella tua config, oppure esporta la variabile d'ambiente CLAUDE_CODE_DISABLE_WORKFLOWS=1 prima di avviare Claude Code. Entrambi disabilitano la funzione completamente. Se non vedi la riga Dynamic workflows in /config, probabilmente sei sotto la versione richiesta v2.1.154 e devi prima aggiornare.
Hai davvero bisogno dei Claude Code workflows, o bastano i subagents?
I subagents bastano finché un task non supera i limiti di una conversazione. Una manciata di subagents coordinati in una conversazione normale gestisce il lavoro quotidiano senza il costo in token. Hai genuinamente bisogno di un workflow solo quando un task genera più agenti di quanti una conversazione possa tracciare, quando vuoi un'orchestrazione rieseguibile come codice, o quando hai bisogno che gli agenti si controllino a vicenda in modo avversariale.