Dynamic workflows: when Claude builds its own harness

The default Claude Code is built for coding, and it turns out a surprising amount of work resembles coding closely enough that the same tool handles it well. But there’s a class of jobs where one Claude, thinking and doing inside a single conversation, starts to struggle: tasks that are very long, massively parallel, or adversarial by nature. For those, the team has historically had to hand-build special-purpose harnesses — for deep research, security analysis, code review, and the like.

Dynamic workflows collapse that distinction. Instead of someone pre-building a harness, Claude writes one on the spot — a small JavaScript program, custom-fit to the task in front of it, that spawns and coordinates a fleet of subagents. You can save the good ones, re-run them, and share them with your team.

A caveat up front: this is new, and the best practices are still being figured out. Workflows tend to use more tokens than a plain request, so the real skill is knowing when the extra compute earns its keep. Most of this guide is about exactly that judgment call.

Why bother — the failure modes a workflow fixes

When you hand the default harness a task, it has to plan and execute in the same context window. For ordinary coding, that’s a feature. But the longer a single Claude grinds on a complex job, the more it drifts into three predictable traps:

• Stopping early. On a big multi-part task, Claude can call it done after partial progress — fixing 20 of 50 flagged issues and declaring victory. Long checklists are where this bites.
• Grading its own homework. Asked to verify or judge its own output against a rubric, Claude leans toward approving it. A reviewer who also wrote the thing is a soft reviewer.
• Losing the thread. Across many turns — especially after the conversation gets summarized to save space — the original goal blurs. The “don’t do X” constraint or the edge case you mentioned an hour ago quietly falls out of view.

A workflow attacks all three structurally. Each subagent gets its own fresh context and one narrow, well-defined goal. The agent that verifies a finding is a different agent from the one that produced it. And because the orchestration is a deterministic script, the original goal can’t drift — the loop holds it.

Dynamic vs. static workflows

If you’ve coordinated multiple Claudes before — with the Agent SDK, or by scripting claude -p calls — you’ve built a static workflow. Those are written ahead of time and have to cover every case, so they end up generic. A dynamic workflow flips that: Claude is now capable enough to write a harness tailored to your specific job, the moment you ask for it. Less “one script for all migrations,” more “the script this migration needs.”

The patterns worth knowing

You can trigger a workflow just by asking for one in plain language (or with the word ultracode, which tells Claude Code to reach for one). But it helps to recognize the shapes Claude composes from — they’re the vocabulary you’ll use to nudge it:

• Fan-out and synthesize. Break a job into many small pieces, run an agent on each, then merge the results. The merge is a barrier: it waits for everyone before combining their outputs. Best when there are lots of small steps, or when each step needs a clean context so they don’t contaminate each other.
• Adversarial verification. For every agent that produces a finding, spin up a separate agent whose job is to attack it against a rubric. This is the antidote to the self-grading problem.
• Generate and filter. Brainstorm a pile of candidates, then filter by a rubric or by verification, drop the duplicates, and return only what survives.
• Tournament. Rather than dividing the work, have agents compete on it — N agents each attempt the same task differently, then judges compare them pairwise until one wins. Comparison is more reliable than absolute scoring.
• Classify and route. A classifier agent decides what kind of task this is, then sends it to the right specialist — or runs at the end to shape the output.
• Loop until done. When you don’t know how much work there is, keep spawning agents until a stop condition is met — no new findings, no errors left in the logs — instead of guessing a fixed number of passes.

These compose. A serious review might fan out across dimensions, adversarially verify each finding, then loop until two rounds turn up nothing new.

Where workflows shine

The surprising thing is how often the biggest wins are non-coding work. A sampling:

• Migrations and refactors. Break the change into units — call sites, failing tests, modules — and give each its own subagent working in an isolated worktree, with a second agent reviewing the fix before it merges. (Bun’s Zig-to-Rust rewrite leaned on exactly this.) Tip: tell the agents to avoid resource-hungry commands so you can run many in parallel without melting your machine.
• Deep research. Fan out searches, fetch sources, adversarially check each claim, and synthesize a cited report. It’s not just for the web — point the same shape at Slack to compile a status update, or at a codebase to understand how a feature really works. (Claude Code ships a /deep-research skill built on this.)
• Fact-checking a document. One agent extracts every factual claim from a draft; a subagent verifies each one in detail against the source; a third can even audit whether the source is trustworthy. Useful before you ship anything you can’t afford to get wrong.
• Qualitative sorting. Ranking 1,000 support tickets by severity won’t fit in one context, and quality sags if you try. Instead, run pairwise comparisons as a tournament or bucket-rank in parallel and merge. Each comparison is its own agent; the script holds the bracket so only the running order stays in context.
• Root-cause investigation. Good debugging means several independent hypotheses, tested fairly — but one context window invites the model to favor its first guess. A workflow assigns separate agents to disjoint evidence (logs, files, data), generates competing theories, and puts each in front of a panel of verifiers and refuters. Works for “why did sales dip in March?” as much as for a stack trace.
• Triage at scale. Classify each item in a backlog, dedupe it against what’s already tracked, and either fix it or escalate. A safety pattern here is quarantine: agents that read untrusted public content aren’t allowed to take privileged actions — separate agents act on the information. Pair it with /loop to run continuously.
• Taste and exploration. Naming, design, anything judged by feel benefits from a rubric. Generate many options, hand a review agent the criteria for “good,” and let a tournament order them. The job’s done when the reviewer is satisfied.
• Lightweight evals and rule-checking. Compare outputs against a rubric to refine a skill, or enforce the CLAUDE.md rules Claude keeps missing — one verifier agent per rule, plus a skeptic persona to keep false positives down. The reverse works too: mine your recent sessions for corrections you keep repeating, cluster them, verify each would have prevented a real mistake, and distill the survivors back into your memory file.
• Model routing. A classifier can research a task first — how many files are in the auth module, what shape the codebase is — and then route to a faster or more capable model based on the complexity it found. (Our guide on which model to use covers the tradeoffs by hand.)

Some prompts to steal

The fastest way to get the feel is to see the requests, not the theory:

This test fails about 1 in 50 runs. Set up a workflow to reproduce it, form
theories, and adversarially test each one in its own worktree. Don't stop
until a theory holds.

Use a workflow to dig through six months of #incidents in Slack and surface
recurring root causes where nobody ever filed a ticket.

Take my business plan and run a workflow where different agents tear it apart
from an investor's, a customer's, and a competitor's point of view.

Here's a folder of 80 resumes. Use a workflow to rank them for the backend
role and double-check the top ten. Interview me for the rubric first.

Go through my blog draft and use a workflow to verify every technical claim
against the codebase. I don't want to ship anything wrong.

When not to reach for one

This is the part that takes discipline. Workflows are new and genuinely powerful, which makes them tempting to overuse — and they can cost meaningfully more tokens. Before spinning one up, ask the honest question: does this task actually need more compute? Most ordinary coding doesn’t. A normal review doesn’t need a panel of five reviewers; a single rename doesn’t need a fleet. Save workflows for the jobs that are large, parallel, or adversarial in a way a single context can’t hold — and let everything else stay simple. (If you want the everyday habits instead of the heavy machinery, that’s our companion guide, 9 Claude Code workflows that actually save time.)

A few practical tips

• Prompt with the patterns. The more specific you are — naming fan-out, verification, a tournament — the better the harness Claude writes. Vague asks get vague orchestration.
• Workflows can be small. You don’t need a giant task. Ask for a “quick workflow” to run a fast adversarial check on a single assumption.
• Pair with /loop and /goal. Repeatable jobs — triage, research, verification — run well on an interval with /loop, and /goal sets a hard finish line the workflow can’t quietly declare itself past.
• Set a token budget. You can cap the spend right in the prompt: “use 10k tokens” sets the ceiling, so an ambitious workflow can’t run away with your bill.
• Save and share. Press s in the workflow menu to keep a good one. Check it into ~/.claude/workflows, or bundle it inside a skill — and when you do, tell Claude to treat the saved script as a template to adapt, not a recipe to run verbatim.

The bigger picture

A dynamic workflow is, at heart, Claude noticing that one mind in one context isn’t the right shape for the problem — and assembling a team that is. That’s a different kind of leverage than “a faster Claude.” It’s worth treating this as a starting point rather than a finished playbook: the patterns above are a foundation, and the most interesting uses are probably the ones nobody’s tried yet. Point one at a problem that’s been too big to hold in your head, and see what comes back.