What we learned running Claude dynamic workflows

Short answer: Multi-agent workflows in Claude Code are worth using for big, checkable jobs, such as auditing a website or comparing design options, but only if you design for interruption. Over two days in September 2026 we ran 11 workflow runs with Claude Opus 5.5 to rebuild our own website. What worked best was pairing every agent that makes a claim with an agent that tries to disprove it. What broke was predictable: usage limits cut three runs short, some agents stalled, and parallel agents needed strict rules about which files each one could touch. We designed around it with resumable runs, strict file ownership, isolated copies of the code, and a human review before anything went public. It cost about 17.4 million subagent tokens.

Key numbers

• 11 recorded workflow runs over 2 days (24 to 25 September 2026).
• About 17.4 million subagent tokens, excluding the main orchestrating thread.
• About 4,500 tool calls in the runs where we counted them.
• 3 runs cut short by usage limits, all recovered by resuming.
• 109 audit findings, of which sceptic agents corrected 23 and added 11.

What is a Claude dynamic workflow?

A workflow here is a short script, written by Claude, that hands jobs to several AI agents and collects what they produce. Each agent (a "subagent") is a separate Claude session with its own instructions and its own slice of the work.

The script decides the shape of the job. A few shapes came up again and again for us:

• Fan out: send the same kind of task to several agents at once, for example one auditor per group of pages.
• Pipeline stages: the output of one stage becomes the input of the next. Audit, then synthesis. Build, then judge.
• Adversarial verifiers: an agent whose only job is to try to prove another agent wrong.
• Judge panels: several agents score the same options, each from a different point of view.
• Resume: if a run stops, start it again and reuse the agents that already finished.

We used this to rebuild the Flowtivity website, from audit to production. The full story is in our case study. This piece is about the method: what held up, what did not, and what we would tell a friend trying it for the first time.

What worked well?

Sceptics made the findings trustworthy. Our site audit had four page-group auditors, each checked by a sceptic agent. Of 109 findings, sceptics confirmed 32, corrected 23 and added 11. They refuted none outright. The corrections were the value. Without that step, about one finding in five would have reached me slightly wrong, and I would not have known which.

Different lenses caught different things. Alongside the page auditors, four agents looked across the whole site through one lens each: design system and colour, brand narrative, benchmarks against other sites, and quantitative rhythm. The rhythm agent measured that 83% of our desktop scroll was text only. No page-by-page reviewer would have added that up.

Judge panels beat a single opinion. We built four design concepts as real pages and had four judges score them: an art director, a sceptical small business buyer, a front-end engineer and a brand strategist. The highest average (Tide, 7.58) was not the concept three of the four judges ranked first (Thread, 7.25). That disagreement was the useful part. The synthesis recommended combining them, and that hybrid is what we shipped.

Verify stages that try to refute, not approve. Our verify stages were framed as "what is wrong with this?" rather than "is this good?". After release, a two-agent verification run checked all 266 URLs in our sitemap on the live site. Asking agents to find problems gets you problems. Asking them to confirm quality gets you reassurance.

What broke?

Plenty. None of it was surprising in hindsight.

Usage limits cut runs mid-way, three times. The first concept run used 1,857,086 tokens across 9 agents and then stopped mid-build when we hit a usage limit. Our biggest run, the Phase 0 site fixes (4,501,368 tokens, 11 agents, about four hours), hit a limit during its fix stage. A revision pass hit one too. Big workflows run into plan limits. You should expect it.

Agents stalled. Some agents stopped making progress and had to be restarted.

Talking to a running agent pulled it out of the workflow. At one point we sent a message directly to an agent that was running inside a workflow. That took it out of the workflow. The lesson: once a run is going, do not message individual agents. Let the stage finish, or stop and rerun it with better instructions.

Parallel agents needed strict file ownership. When several agents edit code at the same time, two of them touching the same file is a recipe for lost work. It only takes one overlap, so we stopped leaving it to chance.

How did we design around it?

Resumable runs with cached agents. A resumed run reuses every agent that already finished, and only reruns what did not. After the first concept run stopped, the resumed run used 3,410,688 tokens across 13 agents and completed the job. A revision pass even resumed on its own after the limit reset, using 423,768 tokens. The Phase 0 resume took another 448,287. Resuming is not free, but it is far cheaper than starting again.

Disjoint file ownership. Before a parallel stage starts, every agent is given a list of the files it owns, and no two lists overlap. Our rule of thumb: if an agent needs a change in a file it does not own, it should report it rather than make it.

Isolated git worktrees. A worktree is a separate working copy of the same code, on its own branch. Agents that build in their own worktree cannot break each other's work, or the main copy, while they are mid-change. We merge only what passes review.

Read before publish. Nothing went to a shareable page, or to production, until it had been read in full. That included the interactive prototype I reviewed, which was published only as a private page.

Refuting verify stages. As above: verifiers were told to disprove, not to approve.

What did it actually cost?

We think honesty about cost matters more than the headline.

That comes to about 16.9 million tokens in the listed runs, and about 17.4 million with the final page-conversion agent (483,522 tokens), and it excludes the main thread that planned and coordinated everything. We ran Claude Opus 5.5 with a 1 million token context at its highest effort setting, which is the expensive end.

The other costs are easier to miss:

• Interrupted time. Each usage limit meant waiting for a reset before we could resume.
• Wasted work. The stopped concept run spent 1.86 million tokens before it stopped. Finished agents were reused on resume, but work in progress was not.
• Human attention. I approved the direction, answered copy questions the agents could not, and reviewed the prototype. Workflows reduce the typing, not the judgement.

Was it worth it? For us, yes. We got a measured audit, four real options and a live site in two days. But a smaller job would not need this machinery. One auditor and one sceptic will get you most of the value.

When should you use a multi-agent workflow?

Use one when the job is big, splits cleanly into parts, and has answers you can check. Audits, comparisons of options, large sets of similar fixes, and link checks all fit.

Skip it when the job is small, when the parts depend tightly on each other, or when the hard part is a judgement only you can make. In those cases, one agent and a good conversation is faster and cheaper.

A small experiment to try

Pick one document your business relies on, perhaps a proposal template or your services page. Ask one agent to review it. Then ask a second agent to try to prove each of the first agent's points wrong.

Compare the two. Which findings survived? Which ones changed? That is the core of what made our workflows trustworthy, and you can try it in an afternoon.

Once you have seen an AI check another AI's work, it is hard to go back to trusting a single answer.

FAQ

What is a dynamic workflow in Claude Code?

It is a script that sends separate tasks to several Claude agents, in parallel or in stages, and combines their results. Common patterns are fan-out, pipelines, adversarial verifiers, judge panels and resuming after an interruption.

How many tokens does a multi-agent workflow use?

It depends on the job. Our runs ranged from about 343,000 tokens for a single build agent to 4.5 million for an 11-agent fix run. The whole website rebuild used about 17.4 million subagent tokens.

What happens when a workflow hits a usage limit?

The run stops partway. You can resume it after the limit resets, and agents that already finished are reused from cache rather than rerun. It happened to us three times.

How do you stop parallel agents overwriting each other's work?

Give each agent a list of files it owns, with no overlaps, and have each one work in its own git worktree, a separate working copy of the code. Merge only after review.

Should I message an agent while a workflow is running?

We would not. Sending a message to a running workflow agent pulled it out of the workflow. Let the stage finish, or stop the run and restart it with clearer instructions.

What is an adversarial verifier?

An agent whose only job is to try to disprove another agent's findings. In our audit, sceptics corrected 23 of 109 findings and added 11 new ones.

Are multi-agent workflows worth it for a small business?

For large, checkable jobs, yes. For most day-to-day tasks, one agent plus one checker gives you most of the value at a fraction of the cost.