Dynamic Subagents

Deep Agents already have subagents, and they're great. Their main gift is context isolation: each subagent runs in its own context window, does a piece of the work, and hands back just the results — so the main agent's context stays clean. That's still true here.

So why do we need anything more? Because normally the main agent orchestrates its subagents itself. It calls the subagent tool (the task tool), looks at what comes back, decides what to call next, and repeats until it thinks it's done. That's totally fine for a handful of calls — but all of that orchestration lives in the agent's own reasoning and context. The moment the task gets big or repetitive, it becomes unreliable: the agent loses track, skips things, decides it's done early, and sometimes takes a bad trajectory.

Dynamic subagents let the agent spawn and coordinate subagents programmatically by writing code. Back to the book: instead of firing the subagent tool a few hundred times in a row, the agent just writes a loop — a few lines that spin up one subagent per page and collect the results. The orchestration moves out of the agent's head and into code.

That's the whole idea: when the orchestration logic is easier and more reliable to express in code than to have the agent generate it turn by turn, let it write code. Two payoffs stand out:

Completeness stops depending on the agent's discretion, and it stops being a prompt-engineering problem you have to keep tuning.

The agent runs its code through the code interpreter middleware — a lightweight in-memory sandbox that gives the agent an eval tool. The agent writes a block of code, hands it to eval, the runtime runs it, and only the final result comes back. That's a big part of how the context stays clean.

The middleware also exposes a task global by default — a programmatic version of the task tool. Spawning a subagent from inside code is just a function call: await task(description, subagentType, responseSchema?). The optional response schema makes the result typed, which is exactly what lets the agent loop or branch on what a subagent returns. And because variables persist across eval calls, the agent can build up state and work iteratively.

The data flow

Once the middleware is attached, the agent can write code to orchestrate subagents — but it won't always decide to on its own. Putting workflow in your request is the signal that you want it to. So "review every file in this PR" may or may not fan out, while "run workflow to review every file in this PR" explicitly tells the agent to write the orchestration code.

Keep this in mind: it's exactly how you steer every one of the six patterns coming up — the phrasing of the workflow request shapes which pattern emerges.

Six patterns show up most often. They emerge naturally from the shape of the task, and you steer toward each with how you phrase the workflow request. (These were originally coined by Anthropic in their work on dynamic workflows — the same shapes appear in dynamic subagents.) Click each to see what it's for and the phrasing that gets you there.

You've seen all six. The skill is reading a request and recognizing the shape of the task — the trigger words tell you which pattern the agent will reach for. Try the six below.