What Are Claude Code Dynamic Workflows (and Why They Matter for CCA-F D1)?

A normal Claude Code session is a single agent loop: send messages, check stop_reason, run a tool, append the result, repeat. Powerful, but linear - one context window doing one thing at a time.

Dynamic Workflows break that ceiling. The model writes its own orchestration layer - actual code - and uses it to decompose a job, fan out a fleet of sub-agents, and verify their work. Three properties define it:

• Two different limits, often confused. 16 sub-agents run concurrently; a workflow can spawn up to 1,000 total per run. The 16 is an in-flight cap that scales with CPU cores; the 1,000 is a lifetime backstop against runaway loops. (First-hand: these are the real concurrency and lifetime caps of fleet orchestration today.)
• Isolated context per sub-agent. Each sub-agent is a fresh Claude with its own window and one scoped task. The orchestrator sees only the returned result, never the full sub-transcript - which is precisely how a 400-file job avoids drowning the top-level context. (First-hand: this isolation is the mechanism, not a marketing line.)
• A judge step. After a sub-agent finishes, a separate verifier scores its output against the requirement before it's merged. (Reported as part of the architecture; reproduce demo-specific claims before trusting them.)

The one-line reframe: "model choice" is becoming "workflow design."

Decomposition shape matters more than agent count. Two primitives do most of the work:

• Parallel (a barrier): fan out N independent sub-agents, then wait for all of them before the next step. Correct only when the next stage genuinely needs every prior result (for example, dedupe across a full result set).
• Pipeline (no barrier): each item flows through its stages independently - item A can be in stage 3 while item B is still in stage 1. Wall-clock is the slowest single chain, not the slowest stage summed. This is the default for multi-stage work; a needless barrier wastes the fast workers' idle time.

Worked example - "audit 124 pages for broken links."

1. Fan out one checker per page (the queue drains ~16 at a time).
2. Each checker returns a tiny structured verdict - not its full reasoning - so the orchestrator's context stays clean.
3. Judge gate: a verifier confirms each "broken" result before it's reported, killing false positives.
4. Synthesize: one final agent merges verdicts into a report.

That's a pipeline with a judge - not 124 chat sessions, and not one context window trying to hold 124 pages.

The Orchestration Tax - every fan-out costs coordination overhead and tokens before it produces value. You pay it whether or not the work was actually parallel. Fan out genuinely independent work and the tax is trivially repaid; fan out a linear task and you have burned credits to automate confusion.

The companion pattern is Judge-Gated Fan-Out: never let a fleet's output reach you unverified, because parallelism multiplies errors exactly as fast as it multiplies work. Speed without a judge step is just faster wrong answers.

This sits squarely in D1 - Agentic Architecture & Orchestration, the heaviest domain at 27%, and overlaps D3 (Claude Code Configuration & Workflows, 20%) and D4 evaluation via the judge step.

The proprietary read you won't get from a launch recap: Dynamic Workflows changes what D1 questions reward.

• Old D1 instinct: write the loop - stop_reason then tool_use then tool_result. (Still foundational; see agentic loops.)
• New D1 instinct: design and bound the fleet - decompose, set subagent scope, define judge criteria, cap the fan-out, decide what merges.

The distractor pattern to memorize. On D1 scenario questions, the trap answer is almost always "switch to a more capable model" or "add more few-shot examples." When a scenario describes a large, decomposable job producing inconsistent output, the architecturally correct move is one of:

1. Decompose into independent sub-tasks and fan out, or
2. Add a judge / verification gate, or
3. Bound the loop (concurrency and total caps) to control cost and runaway behavior.

The multi-agent research system scenario is the canonical shape; expect it in several disguises.

1. Decompose before you fan out. If you can't name the independent sub-tasks, you're not ready to orchestrate - you're ready to confuse. Write the work-list first.
2. Default to a pipeline, not a barrier. Only force a barrier when a stage truly needs all prior results. Otherwise you're paying the Orchestration Tax for nothing.
3. Define judge criteria up front. Decide what "correct" means per sub-agent before the run. The verifier is the point, not a nicety.
4. Bound the fleet deliberately. 16 / 1,000 is a ceiling, not a target. Match fan-out to the real parallelism in the work.
5. Return results, not transcripts. Have sub-agents hand back tight structured output so the orchestrator's context stays clean across large jobs.
6. Know when not to. Single linear edits don't need a fleet - that's pure Orchestration Tax with no payoff.

The meta-skill - and the D1 exam skill - is identical: stop evaluating these models on single-turn output, and start evaluating whether they can decompose, verify, and recover.