Dynamic workflows

Dynamic workflows are a Claude Code capability in which Claude writes its own orchestration script at runtime and runs it to plan, fan out, and reconcile many subagents within one session, so the coordination runs as model-authored code rather than one dispatch decision at a time.

How it works

Faced with a task too large for one context window, Claude writes a script that encodes the plan as ordinary control flow: which subagents to spawn, what each one receives, how many run at once, and how their returns are combined. Running the script dispatches the workers, each in its own context window, and collects their distilled results back into the coordinating session. Because the plan is code, the loops and branches and fan-out are explicit and inspectable rather than improvised, even though which branch runs still turns on what the workers produce. The pattern often pairs the fan-out with an adversarial step, where independent workers are asked to refute a finding rather than confirm it, and the script iterates until the answers converge or a limit is reached. Caps bound the blast radius: a ceiling on how many workers run at once and a ceiling on how many run in total keep a runaway plan from spawning without end.

Why it matters

The reason to let the model write the coordinator is scale a single context cannot hold: a migration across a large codebase, an audit of a whole repository, a research sweep too wide for one window. Moving the orchestration into a script makes that scale legible, since the plan is a written artifact I can read and reason about rather than a sequence of dispatch decisions that only exist as they happen. The trade-off is that the script is only as good as the plan behind it, so a wrong assumption does not fail in one place, it propagates across every worker the plan spawned, and a wide fan-out concentrates spend fast. What the script gives is a legible, repeatable structure, not a deterministic outcome, since its branches still turn on fallible worker output, so a clean run of the coordinator is not evidence the work it coordinated was correct. The capability earns its overhead on genuinely large work and is a tax on a task that fits one window, where the orchestration buys nothing the single context did not already have.

In practice

A repository-wide change is too large to hold in one context, so instead of working file by file Claude writes a script that fans the work out: one worker per module, each making its change in isolation and returning a summary, with the coordinator reconciling the results and re-dispatching the ones that failed. A second pass sends independent workers to check the changed modules against the original behavior, refuting rather than rubber-stamping, and the script loops on anything that does not converge. The coordinating session never holds all the files at once, so the work scales past the window, and the plan that drove it is a script I could read start to finish.

Practical considerations

Parallel workers that write files need isolation or they collide, so file-disjoint work or a per-worker worktree is the difference between a clean fan-out and a merge mess. The adversarial step does real work only when the refuting workers are independent of the one that produced the finding, since a worker grading its own output is the weak case the pattern exists to avoid. The concurrency ceiling means a plan that names more workers than the cap allows queues the excess rather than running it all at once, so wall-clock does not fall in step with the number of workers. A wide fan-out concentrates spend, so the cost of a dynamic workflow is better reasoned about as the sum of its workers than as one session. The honest default is to reach for this only when the work genuinely exceeds a single context; the orchestration is overhead a task small enough for one window pays without earning it back.

Defined by Ready Solutions AI