▶ Watch this course as a narrated video playlist (8 lessons, about 28 min)
Claude Code can now write its own multi-agent harness; Anthropic used a Slack-driven agent loop to speed claude.ai up 3× in two weeks. What each does, what it costs, and what neither post proves.
Spine texts (claude.dev): Dynamic workflows in Claude Code · How we made claude.ai 3x faster
Both posts are written by Anthropic about Anthropic’s own tools, and both are results-first: the workflows post gives patterns and two token counts but no comparison against a static baseline; the claude.ai post reports a dazzling aggregate but no cost, no revert count and no counterfactual. I separate what the source says, what it leaves unmeasured or self-serving, and independent evidence (Anthropic’s own multi-agent research system write-up and Building effective agents).
Modules 1, 3, 4 and 6 make you commit to an answer before the reveal. Related courses in this library: Loop Engineering (the Cherny view of the same pattern) and The Harness Is the Policy.
Dynamic workflows let Claude Code write and run a JavaScript file that orchestrates subagents with three primitives: agent() to launch one, parallel() to fan out, and pipeline() to chain stages. A workflow can pick the model per agent (Opus, Sonnet, Haiku) and the isolation level (a git worktree, or remote). “Dynamic” means the harness is written for this task rather than being a generic loop: where a static harness runs the same five web searches every time, a dynamic one might inspect the billing code, verify features against provider docs, price at real volumes and add an adversarial check before recommending.
Separate subagents with fresh, isolated contexts address each: a verifier has no authorship to defend; a worker sees only its slice of the goal; a loop can keep launching agents until a completion condition is met instead of a fixed count.
| Published example | Agents | Tokens | Time |
|---|---|---|---|
| review-changes | 14 | 482K | 6 min 12 s |
| deep-research | 22 | 1.1M | 11 min |
From the table: the deep-research workflow used 22 agents and 1.1M tokens. What is the average number of thousand tokens per agent? Commit a number, then see what it implies for how you budget a workflow.
The three failure modes are real but the cure is not free. A fresh-context verifier from the same model family shares the generator’s blind spots; independence of context is not independence of error. Adversarial verification reduces self-flattery, not correlated mistakes. The post gives no false-positive or miss rate for any verifier pattern. Where a deterministic check exists (tests, type-check, a diff against a reference), prefer it over a verifier agent at every stage it can reach.
The post is honest about cost (“significant token costs”, “most standard development work doesn’t benefit from five-reviewer panels”). Take that seriously: the default for ordinary coding should stay a single agent.
| Pattern | Shape | Use when | Main risk |
|---|---|---|---|
| Classify-and-act | route by type to a specialist | heterogeneous inputs | misroute; classifier becomes a bottleneck |
| Fan-out & synthesize | N parallel agents → barrier → merge structured results | independent subtasks (callsites, sources, modules) | unstructured outputs make the merge lossy |
| Adversarial verification | separate agent checks output against a rubric | claims, diffs, reports | correlated errors; rubric quality |
| Generate & filter | many ideas → score → dedupe | naming, design options | the filter encodes your taste; garbage rubric = garbage pick |
| Tournament | pairwise judges eliminate competitors | ranking 1,000+ items; competing approaches | judge noise; O(n) comparisons of cost |
| Loop until done | keep spawning until a completion condition holds | open-ended work | no true stop condition → runaway spend |
These map almost one-to-one onto the five workflows in Building effective agents (routing ≈ classify-and-act, parallelization ≈ fan-out, orchestrator-workers ≈ fan-out with a planner, evaluator-optimizer ≈ verify/loop). What is new in the dynamic version is not the patterns — it is that the model writes the orchestration code for the specific task.
It is a prompt-injection control: any agent that reads untrusted text gets no tools with side effects; any agent with side effects reads only the sanitized, structured summary. It works only if the summary schema cannot carry instructions (enumerations and IDs, not free text). That is the single most security-relevant idea in the post, and it gets two sentences.
Anthropic’s multi-agent research system (orchestrator Opus, Sonnet subagents) reported a 90.2% improvement over a single-agent Opus on an internal research eval. Its cost: agents use ~4× the tokens of chat, multi-agent systems ~15×. And the finding most people skip: token usage alone explained about 80% of the performance variance. They list poor fits — most coding tasks and anything needing shared context — and early failure modes: 50+ subagents for a trivial query, duplicated work from vague task descriptions, picking SEO spam over primary sources.
If agents use ~4× chat tokens and multi-agent systems ~15× chat tokens, how many times more tokens does the multi-agent system use than a single agent?
Compare a workflow against a single agent given the same token budget (e.g. best-of-N, or one agent with a 3.75× longer budget and the same deterministic checks). Only if the workflow wins at equal spend has structure, rather than spend, earned its place. The dynamic-workflows post reports two runs and no comparison at all; each pattern is justified by narrative.
Tension to resolve: the workflows post sells code migrations and refactors; the research write-up says most coding is a poor fit. The reconciliation is that migrations are parallel with machine checks, whereas open-ended feature work needs shared context. Treat “coding” as two different workloads.
Static vs dynamic is also unmeasured. Letting the model write the harness adds a failure mode: a badly written orchestration (wrong barrier, lossy merge, no stop condition) that you did not review. Save and review workflows that matter (the post’s “s” key and ~/.claude/workflows); treat a generated workflow like generated code.
In two weeks (August 2026) the claude.ai and desktop apps got roughly 3× faster across thirteen user journeys. Examples: fresh web load 3.1 s → 0.55 s (5.6×); desktop cold start 6.3 s → 3.3 s; loading an existing conversation 2.4× on web and 2.8× on desktop; Cowork message send 928 ms → 48 ms (19×). By day three they had hit 12 of 13 original targets and set new ones; at peak 150+ threads ran at once and 200+ changes landed on the busiest days.
Once a metric exists, Claude can hill-climb it. The team built several complementary benchmarks: Valgrind-based instruction counting for JavaScript hot paths (node --predictable), V8 precise-coverage call counts, React commit counts, style-recalculation counts and DOM-mutation counts. Crucially, each metric had to be validated twice: that it tracked wall-clock time, and that optimizing it produced real gains. Their example: cutting instructions 48% on message-tree assembly improved wall-clock 78%, which earned the metric trust.
Three things: push ambition (“we have the power to do anything. please be braver” — Claude by default hedges and pads estimates), aesthetic judgment (each thread had a named human owner reviewing before/after screenshots: skeleton at 0 ms or after 500 ms? is a word-fade worth a fifth of the frame budget?), and scope control (narrow threads; rejected a 2 ms/message win that needed a complex build plugin).
3.1 ÷ 0.55 = 5.6× and (3.1−0.55)/3.1 = 82% reduction — both match. 928 ÷ 48 = 19.3×. The headline “3×” is therefore an aggregate over 13 journeys whose individual gains range from 1.5× to 19×; it is not a typical journey and the post doesn’t say how it aggregates.
What is not in the post: total token/compute spend for 150 concurrent threads; the number of reverted changes (“unsuccessful ones were reverted” — how many?); the human review hours; and any baseline for what the same team would have achieved in two weeks with the same measurement discipline and no agents. “Tens of thousands of user-hours saved” is an unshown calculation. Selection bias is built in: a post celebrating a sprint does not report the failed sprints.
Where it probably generalizes: performance is close to an ideal agent task — a scalar metric, cheap reproduction, mechanical rollback. The load-bearing idea is validated metric + ratchet + flags + staged rollout, not “150 agents.” Without a scalar you trust, the same loop optimizes the wrong thing faster (the ratchet locks in a mistake).
Lab-to-field gap: instruction counts and headless frame stepping are proxies; the post’s defense (field telemetry after each flag ramp) is the right one, and it is the part to copy first.
| Situation | Use | Gate that must exist |
|---|---|---|
| Small, well-scoped change; tests exist | single agent | the tests |
| Parallel slices, deterministic per-slice check | fan-out workflow | per-slice tests; merge schema |
| Breadth-first research, claims to verify | fan-out + verifier per claim | citations; source audit |
| Subjective choice at scale | generate-and-filter / tournament | a rubric you have calibrated on hand-labelled pairs |
| Untrusted input plus side effects | quarantine (reader / actor) | a schema with no free-text channel |
| Open-ended improvement of a scalar | measured loop (benchmarks, flags, ratchet) | a validated metric; field telemetry; rollback |
Goal: <one sentence + completion condition>
Pattern: fan-out by <unit>, then adversarial review, then merge
Worker: model=Sonnet, isolation=worktree, output=JSON{unit,status,diff_summary,evidence}
Gate: per-unit tests must pass; reviewer (fresh context, rubric below) must fail to refute
Rubric: <3-5 checkable questions>
Budget: max <N> agents, <T> tokens; stop and report if exceeded
Baseline: run the same task single-agent with the same token budget; compare pass rateBoth claude.dev posts were read in full on 1 Oct 2026. Supplementary numbers (90.2%, 4×/15×, 80% variance, failure modes) are from Anthropic’s multi-agent research system write-up, and the five workflow definitions from Building effective agents. Arithmetic is mine. Simulator cases are illustrative.