learnaiwithrafa
ClaudeWorkflows

Dynamic Workflows in Claude Code: 100 Agents, One Answer

Claude Code can now write its own orchestration plan and run hundreds of subagents in parallel. The parallelism is not the interesting part — the refute step is. Here's how to switch it on, when it pays, and the spec skill it quietly demands from you.

4 min read1 source
  • #claude-code
  • #dynamic-workflows
  • #agents
  • #orchestration

Everyone is sharing the headline number, but the parallelism is not what makes dynamic workflows interesting. Spinning up a hundred agents is easy; a hundred agents confidently making the same plausible mistake is the default outcome. What Anthropic actually shipped is an adversarial layer: agents attack the problem from independent angles, other agents try to refute their findings, and the run keeps iterating until the answers converge. The refutation is the product. The fan-out is just the engine.

The receipt

Anthropic's announcement leads with Jarred Sumner (the Bun creator) using dynamic workflows to port Bun from Zig to Rust: about 750,000 lines of Rust, with 99.8% of the existing test suite passing, and only eleven days between the first commit and the merge — hundreds of agents in parallel, two reviewers assigned per file. Notice why that worked: a runtime port has a brutal, machine-checkable definition of done (the test suite). The workflow didn't succeed because it was big; it succeeded because "done" was verifiable.

How to turn it on

Two entry points, and they work everywhere Claude Code runs (the CLI, the desktop app, the VS Code extension — plus the Claude API and the cloud platforms: Bedrock, Vertex AI, Microsoft Foundry):

  1. Just ask. Start your request with "Create a workflow to…". The first time one triggers, Claude Code shows you what it's about to run and waits for your confirmation.
  2. Flip ultracode. It lives in the effort menu, sets effort to xhigh, and hands Claude the call on whether a task deserves a workflow.

It comes on by default on Max, Team, and Enterprise plans (and when you use Claude Code through the API). On Pro you have to enable it yourself in /config — so if you've never seen a workflow trigger, that's probably the reason, not your prompt.

When it pays (and when it burns money)

Anthropic is upfront that a workflow eats far more tokens than a regular session and recommends your first run be a small, scoped task. My filter as an EM has three checks, and I want all three before I approve the plan:

  • The task fans out. Codebase-wide bug hunts, migrations spanning thousands of files, security hardening passes — the exact use cases Anthropic names.
  • "Done" is checkable by a machine. A test suite, a rubric, a diff that compiles. If you can't write the verify rule, the refute step has nothing to refute.
  • Being wrong is expensive. If a single agent gets it right in two minutes, a workflow is a tax, not a tool.

The career angle: specification is the transferable skill

Here's what this feature quietly demands from you: the bottleneck moved from writing code to specifying "done" precisely enough that a swarm of agents can check itself. That's the same skill that gets Brazilian devs hired onto international teams — writing acceptance criteria a stranger (human or agent) can execute against, async, without you in the room. Every workflow spec you write is a rep of staff-level communication, in English, with immediate feedback on whether it was precise enough.

Today: pick one real, scoped task — an audit of a single module, not your whole repo. Write the verify rule first ("done means the suite passes and every finding cites a file and line"), then ask Claude Code to create a workflow for it and read the plan before confirming. Watch what it spends before you point it at anything bigger.

Sources