Claude Code Workflows and Agent Teams
Every mechanism covered elsewhere in this track — subagents, /loop, /goal, plan mode — still puts one Claude session in charge, deciding turn by turn what happens next. That works well up to a point. Past it, two different problems show up: a task that genuinely needs more parallel workers than one conversation can juggle without flooding its own context, and a task where the value comes specifically from several independent perspectives arguing with each other rather than one perspective working faster.
This subject covers the two mechanisms Claude Code built for exactly those cases. Dynamic workflows move the orchestration plan out of Claude's turn-by-turn judgment and into an actual script — code a runtime executes in the background, coordinating dozens to hundreds of subagents while your session stays free. Agent teams move the opposite direction: instead of one script directing everything, a lead agent supervises peer sessions that each keep their own context, claim work off a shared list, and message each other directly — an experimental feature you must opt into explicitly.
Neither replaces subagents or a normal conversation. They're what you reach for once the shape of the task stops fitting inside one context window's worth of turn-by-turn delegation. Knowing which one — and knowing when the honest answer is "neither, a single agent is enough" — is the actual skill this subject teaches.
Who Holds the Plan
Four things in Claude Code can all run a multi-step task on your behalf: subagents, skills, agent teams, and dynamic workflows. They look similar from the outside — you ask for something, several things happen, you get a result — but they differ on one question that predicts almost everything else about how each behaves: who decides what runs next?
| Subagents | Skills | Agent teams | Workflows | |
|---|---|---|---|---|
| What it is | A worker Claude spawns | Instructions Claude follows | A lead agent supervising peer sessions | A script the runtime executes |
| Who decides what runs next | Claude, turn by turn | Claude, following the prompt | The lead agent, turn by turn | The script |
| Where intermediate results live | Claude's context window | Claude's context window | A shared task list | Script variables |
| What's repeatable | The worker definition | The instructions | The team definition | The orchestration itself |
| Scale | A few delegated tasks per turn | Same as subagents | A handful of long-running peers | Dozens to hundreds of agents per run |
| Interruption | Restarts the turn | Restarts the turn | Teammates keep running | Resumable in the same session |
With subagents, skills, and agent teams, Claude — or, for teams, the lead agent — is still the orchestrator: something with a context window decides turn by turn what to spawn or assign next, and every result eventually has to land in a context window to be used. A workflow differs in kind, not just degree: the plan itself lives in code. The script holds the loop, the branching, and the intermediate results, so Claude's own context only ever holds the final answer, not the working data of a 200-file audit.
That single distinction — plan-in-a-context-window vs. plan-in-code — is why workflows scale to a place the other three structurally can't: the same reason a for-loop replaces manually repeating a line of code ten times. At small scale they produce the same result, but only one is inspectable, rerunnable, and doesn't fall over once the count gets large.
The rest of this subject covers the two structures at the far ends of that spectrum: workflows, where a script holds the plan, and agent teams, where several independently-contexted peers hold it together.