Deep dive · the canal

Dynamic workflows

When the job is too big for one channel, Claude engineers a canal: a script that routes the work through dozens — up to hundreds — of workers, and that you can run again.

The problem this solves

Some jobs aren't one task — they're the same task five hundred times, or a question one reading can't be trusted to answer. A conversation hits two walls there: it can juggle only a few helpers at a time, and every intermediate result lands back in its finite memory.

A dynamic workflow moves the plan into a small script. You describe the job; Claude writes the script; it runs in the background while your session stays free. The loop and the intermediate results live in the script — your conversation holds only the final answer. That buys three things the docs call out:

Scale — dozens to hundreds of workers per run, versus a few per turn.
Trust — independent workers can check each other's findings before anything is reported, so what survives is verified, not just plausible.
Repeatability — save a good run and it becomes a command that runs the same route every time.

You'll recognize the situation

The migration everyone keeps deferring

A frontend team needs every component moved to a new styling system. It's not hard — it's five hundred times mildly annoying, and any single sitting runs out of steam thirty files in.

use a workflow to migrate every component under src/components/ from
styled-components to Tailwind, working on each file in its own isolated copy

The script finds the files, transforms each in parallel in its own copy so edits don't conflict, and verifies each result. A stopped run can usually resume where it left off.

The audit that has to actually cover everything

Security asks: does every API route check authentication? A conversational sweep answers for the files that fit in one reading, and "we checked most of them" is not a sentence anyone wants in the report.

use a workflow to audit every route handler under src/routes/ for missing
authentication checks, and adversarially verify each finding before reporting it

One worker per route, then verifiers that try to knock each finding down before it's reported.

The research question that deserves more than one pass

Product wants to know how three competitors handle rate limiting — real answers with sources, not one skim's impression.

use a workflow to research how our three competitors handle rate limiting:
read their public docs and recent changelog entries in parallel, then
compare the approaches

Readers fan out in parallel, then one worker compares. The bundled /deep-research command is the general-purpose version: it cross-checks the sources against each other and returns a cited report, with claims that didn't survive the cross-check filtered out.

Shoal water — don't use this when

A few delegated tasks would do. Subagents handle a handful per turn; workflows are for dozens to hundreds. Don't dig a canal for a creek.
The work needs your judgment mid-run. A running workflow takes no input from you. For sign-off between stages, run one workflow per stage.
What you want to reuse is instructions, not orchestration. A checklist Claude should follow in-conversation is a skill, not a workflow.
The budget is tight. A run can cost meaningfully more than conversation — pilot one directory or one narrow question first.

Talk track — say it to a customer

"For a five-hundred-file migration or a whole-codebase audit, Claude writes the plan as a script and runs it in the background — your session stays free, and you get one report instead of a play-by-play."

"The findings earn their place: independent workers cross-check each other's results before anything reaches you."

"When a run does what you wanted, you save it — it becomes a command your whole team can run on every branch, same route every time."

If the customer asks…

"What does a run cost?": More than conversation — the docs say "meaningfully more," and publish no per-run figure, so neither do we. The controls are real: pilot a small slice, watch each worker's usage live in /workflows, stop a run at any time (usually keeping completed work), and hard caps bound a runaway script — 16 workers at once, 1,000 per run, and a visible warning when a run grows unusually large.
"Does it just… run? Who approved that?": The developer holds the gate: before a run starts, Claude Code shows the planned steps, with the option to read the script, and starts on a yes. (More permissive or automated setups prompt once or not at all — their configured rules govern instead.) Mid-run, commands outside the approved list still prompt like any other action; file edits are auto-approved, so that up-front look is where you check what the run will do.
"Is this available on our plan?": On a recent Claude Code: all paid plans, the API, and the major cloud providers. On Pro it's off until enabled in /config, and organizations can disable it fleet-wide.
"Can we see what it actually did?": Yes: /workflows shows every step and worker during the run, and afterward the script is a readable file you can open, compare, or edit and relaunch.

See it work

The fastest demo ships in the box:

Run the bundled research workflow on any real question:

/deep-research What changed in the Node.js permission model between v20 and v22?

Approve it, and the run starts in the background.

Watch the steps, workers, and usage live:

/workflows

For your own task, just ask — "use a workflow to…" in your own words. When a run is worth keeping, press s in /workflows to save it for the repo or just for yourself; it runs as a slash command from then on.

And the script Claude writes is small enough to read aloud — this is the docs' auth-audit example, whole:

export const meta = {
  name: 'audit-routes',
  description: 'Audit every route handler for missing auth checks',
}

const found = await agent('List every .ts file under src/routes/.', {
  schema: { type: 'object', required: ['files'],
    properties: { files: { type: 'array', items: { type: 'string' } } } },
})

const audits = await pipeline(found.files, file =>
  agent(`Audit ${file} for missing authentication checks.`, { label: file }),
)

return audits.filter(Boolean)

agent() spawns one worker; pipeline() runs one per file. The plan is code, the workers are Claudes, and your conversation only sees what the script returns. Everything deeper is in the full reference.

Where the river forks

Just one noisy side task?

That's a side channel, not a canal.

Subagents →

Independent tasks you'll steer yourself?

Background sessions, watched from one screen.

Agent view →

Workers that should confer as peers?

A script coordinates; it doesn't host a debate.

Agent teams →