The news. On June 29, 2026, LangChain introduced dynamic subagents in Deep Agents. The idea: give the agent a code interpreter, and when subagents are configured, expose a
task()global inside it. The agent then writes a short JavaScript program — loops, branches, a single fan-out — that dispatches subagents itself, instead of the model emitting one tool call per turn. The headline pattern runs one summarizer subagent per page of a 300-page document, all dispatched together. It runs inside a QuickJS interpreter (deepagents[quickjs]) and in the dcode coding agent. LangChain's framing: "Coverage becomes a structural guarantee, not a prompt engineering problem." Read the announcement →
Picture a dispatcher with 300 delivery stops. The slow way is to radio one courier, wait for them to come back, then radio the next — and to keep it all straight in your head, so if you lose count, stop 214 quietly never gets a courier. That is exactly how an agent covers 300 pages with sequential tool calls: one tool call per turn, the model itself deciding each time who to send next, and remembering to send all 300. The coverage of the whole job rides on the model not forgetting — which is why LangChain calls it a "prompt engineering problem."
Dynamic subagents hand the dispatcher a different tool: a route sheet they write once. LangChain gives the agent a code interpreter, and — when subagents are turned on — drops a single command into it, task(), that means "send a courier." Now the agent doesn't radio anyone; it writes a short program — for (const page of pages) task(summarize, page) — and runs it. Because the loop physically walks the whole list, every stop gets assigned in one pass, and because the calls are launched together rather than one-after-another, the couriers all leave at once. The interesting move is where the work lives: dispatching stops being a sequence of model decisions and becomes a property of a few lines of code.
That code doesn't run just anywhere. It runs inside QuickJS, a tiny, embeddable JavaScript engine. Running an agent's freshly written code inside a small, separate interpreter — instead of your own process — is how you scope what that code can reach, the same instinct as a route sheet that only says send a courier, not open the safe. Letting an agent write and run code is powerful, and it opens a real attack surface, so where the code executes is part of the design, not an afterthought.
Why the loop beats the list
Hold the job fixed at 300 pages and watch the two shapes diverge. With sequential tool calls, the model takes one turn per page: it reads the state, decides "summarize page 1," waits for the result, then decides page 2, and so on — up to 300 separate model turns, each one a full round-trip, and each one a chance to lose the thread. To put rough numbers on it (illustrative): if a single turn is ~2 seconds of the model just choosing what to do next, that is ~10 minutes of pure dispatch overhead before you count the summarizing itself. With dynamic subagents, the model takes one turn to write the script; the loop then issues 300 task() calls in a single pass, launched together. 300 model decisions collapse to 1, and as long as the loop runs over the full page list, coverage is 300 / 300 by construction — not by the model remembering. The parallel dispatch is the speed win; the loop is the coverage win.
| Dimension | Sequential tool calls | Code-driven fan-out (dynamic subagents) |
|---|---|---|
| Who decides the dispatch | The model, one tool call per turn | A short program the model writes once |
| Coverage of N items | Rides on the model remembering all N | Structural — a loop written over the full list of N |
| Concurrency | One at a time, each waits on the last | Fanned out — all dispatched together |
| Model turns for N dispatches | ~N turns | ~1 turn (write the script) |
| Where the risk moves to | Forgotten items, slow serial chains | Running generated code — hence the QuickJS interpreter |
The honest caveat is that this shifts the problem rather than deleting it. Fan-out is only free when the slices are independent — 300 page summaries don't need each other, but a task where step 2 depends on step 1 can't be sprayed out at once. And the loop is only a coverage guarantee when it actually iterates the right list; generated code can still be wrong. Letting an agent write and run code is also exactly why where it runs matters — the payoff of code-driven orchestration comes bundled with the duty to contain that code. What LangChain has really done is move coverage and concurrency out of the prompt and into a place a program can express them — a small, sharp idea, with the containment attached.
Goes deeper in: AI Agents → Workflow Patterns → Orchestrator-Workers + Subagents
Related explainers
- Claude Opus 4.8 — Parallel-subagent dynamic workflows — the model-native cousin: parallel subagents built into the model, where wall-clock is set by the slowest subtask
- SpatialClaw — code-as-action vs structured tool-calls — the same "write code instead of emitting tool calls" idea, applied to a single agent's own actions
- Microsoft FastContext — explorer-subagent context offloading — why you reach for subagents at all: to keep the parent's context small