TL;DR
Dynamic parallelism is a mode in which the lead agent decides on the fly whether to launch helper sub-agents, what to assign them and how to assemble the result. It is not a pipeline written out in advance. In Claude Code it is Dynamic Workflow, in Codex it is multi-agent v2, in Kimi Code it is AgentSwarm. The researchers ran the same tasks with the mode on and off, with the same model, prompt and time budget.
The headline finding: more agents does not mean better. Token usage goes up by 1.4–3.3x. Quality does not improve consistently: on tasks like "fix one bug" the mode often hurts. For Claude Code and Kimi Code, the share of solved tasks on SWE-bench dropped from roughly 77–83% to 59%. The benefit shows up on long multi-stage projects that have independent chunks of work. Even there the results are mixed: one agent gains, another drops on the same task. The classic failure: the lead agent handed out the work, "fell asleep" waiting for every helper and left no time to assemble the result.
The practical takeaway in three rules. Turn on parallelism only for large tasks with independent parts. Turn it off for small tasks. If you do turn it on, spell out rules for the agent: timeouts shorter than the total budget, integration as pieces come in, and time reserved for the final assembly and checks.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Blueprint: deciding whether to turn on sub-agents
STEP 1: Size up the task
→ targeted fix / bug / one function → TURN OFF sub-agents
→ big project, many independent modules → go to step 2
STEP 2: Check that the chunks are independent
→ parts depend on each other, shared files without clear interfaces → risk of conflicts, be careful
→ parts are independent, interface is locked in → TURN ON
STEP 3: Set the rules (in the agent's instructions)
→ sub-agent timeout < total budget
→ do not wait for the whole batch, integrate as pieces are ready
→ reserve time for assembly and tests
STEP 4: Use parallelism where it actually helps
→ complementary work (different modules)
→ alternative solutions to the same task
→ independent code review by another agent
Example in Practice
Task: You run a small studio building a notification service for an online store. It needs modules: a Slack bot, email campaigns, SMS via Twilio, Stripe webhook handling, an admin panel, tests. There are many modules, and they are almost independent of each other. This is prime territory for parallelism: a greenfield project, wide scope, clear boundaries.
Prompt (in Claude Code with sub-agent mode turned on):
Task: build a notification service for an online store from scratch (Python, FastAPI).
Modules: slack_bot, email_sender, twilio_sms_client, stripe_webhooks, admin_panel.
Total time budget: 60 minutes.
Rules for working with sub-agents:
1. First write the shared core yourself: project structure, the sender interface
Notifier.send(user_id, text), config, launch script. Only after that
hand out the modules.
2. Give each sub-agent one module, specific files and the core interface.
Touching other modules' files is forbidden.
3. Maximum sub-agent time is 25 minutes. Do not wait for everyone to come back:
accept and integrate finished modules as they arrive.
4. No later than minute 40, stop delegating. The remaining time goes to
assembly, running tests, and finishing missing modules yourself.
5. If a sub-agent did not make it in time, finish its module yourself from the scaffold.
6. At the end, have a separate sub-agent review the assembled code: run the tests
and list any mismatches with the interface.
Result: The agent will first write the shared core, then launch several sub-agents, one per module. It will accept finished modules one by one instead of waiting for all of them. By minute 40 it will stop handing out work and switch to assembly. It will finish the lagging module itself. At the end, a separate sub-agent will check the result and return a list of mismatches. Token usage will be noticeably higher than with a single agent. That is the price of speed and independent review.
The counterexample, where parallelism is not needed: "Fix the bug: after a Stripe payment the order status does not update". This is a bounded task. Here the study showed quality losses and higher costs. Turn sub-agents off.
Why It Works
The weakness. The lead agent has to split the task, pass along context, wait for helpers and stitch the result together, all at the same time. It does all of this in a single thread. Any mistake in the split, in the interfaces or in the waiting breaks the overall result. On a short task, the coordination overhead outweighs the gain from dividing the labor.
The strength. Long projects have genuinely independent chunks: different modules, commands, tests. A model is good at working on one narrow part with a clear interface. A separate sub-agent without the "authorship" context is better at spotting someone else's mistakes.
How the method gets around the weakness. Delegation rules make the critical decisions explicit, so the agent does not "invent" them on the fly: module boundaries, timeouts, when to stop handing out work and a time reserve for assembly. Without them the agent tends to do the most natural thing: hand out everything and wait for everyone.
Control levers: - Sub-agent timeout → shorter than the total budget, so one stuck helper cannot eat all the time. - When delegation stops → earlier with a hard deadline, later with a generous budget. - Number of sub-agents → fewer to save tokens. In the study the number of agents spawned grew with task complexity. - Reviewer role → add a separate sub-agent for independent review. This is one of the conditions under which parallelism helped. - Alternative solutions → ask two sub-agents to solve the same task in different ways, and the lead to pick the best one.
Prompt Template
⚠️ The paper has no ready-made prompt. The researchers turned the modes on and off with toggles. The template below is my own assembly of rules based on the findings and the post-mortem of the failure on the seqtk task. It is a starting scaffold, not wording the authors tested.
Task: {project_description}
Total time budget: {minutes} minutes.
Rules for working with sub-agents:
1. First create the shared core yourself: {what_goes_into_the_core}
(structure, interfaces, config). Only then hand out the parts.
2. Split the work into independent parts: {list_of_parts}.
Each sub-agent gets one part, specific files and the core interface.
Touching other agents' files is forbidden.
3. Sub-agent timeout is {minutes_per_subagent} minutes (strictly less than the total budget).
4. Do not wait for all responses at once: accept and integrate finished work as it arrives.
5. At the {stop_minute} mark, stop delegating. The remaining time goes to
assembly, running tests, and fixing missing parts yourself.
6. If a sub-agent did not come back in time, finish its part yourself.
7. At the end, launch a separate sub-agent for an independent review:
run the tests, check the interfaces, list any mismatches.
If the task is small (one fix, one bug), do not launch sub-agents,
work on your own.
What to fill in: {project_description} — what we are building. {minutes} — the real budget. {list_of_parts} — the independent modules. {minutes_per_subagent} — roughly 40% of the budget. {stop_minute} — roughly 65–70% of the budget.
🚀 Quick start — paste into the chat:
Here is a template of sub-agent delegation rules. Adapt it to my task: [your task].
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask about the project size, the time budget and the list of independent parts. It needs these to figure out whether sub-agents are worth turning on at all, and to set the timeouts. It will take the pattern from the template and tailor it to your task.
Limitations
⚠️ Short tasks: on bounded tasks (fixing one bug) parallelism often hurts: quality drops while time and tokens go up. For these it is better to turn the mode off.
⚠️ Cost: token usage goes up by 1.4–3.3x. On the largest tasks that means tens of millions of tokens per run.
⚠️ No guarantee even on long tasks: on large projects the results are mixed. One agent gains, another drops on the same set. For Claude Code, the share of solved tasks fell on two of the long-horizon sets. There is no universal "yes".
⚠️ Coding only: the study is about writing code. The findings were not tested for writing, analytics or research.
⚠️ No recipe in the paper itself: the accessible excerpt has findings and failure post-mortems but no tested prompt wording. The delegation rules in the template are mine and need to be tested on your own task. The taxonomy of 28 error patterns and the analysis of when parallelism pays off are not spelled out in this excerpt: only the category names are given.
⚠️ The right settings depend on the tool: the mode is turned on with toggles (
ultracodein Claude Code,swarm_modein Kimi Code,multi_agentin Codex). Names and behavior differ across products and may change.
How They Tested It
The researchers took three flagship coding agents: Codex, Claude Code and Kimi Code. Each ran in its native harness at its strongest reasoning level. The agents were run on 354 tasks from five sets: four with long projects (rebuilding libraries in another language, programs from a spec, evolving a repository over many steps) and one with short tasks (SWE-bench Verified). Each task was run twice: with parallelism and without. Same model, prompt, environment and time. That came to 2124 runs for about $20K.
They compared the share of fully solved tasks and the share of passed tests, plus time, tokens and the number of shell calls. The key insight: parallelism helps when the project is big and long. The most noticeable gain was on the longest set, LoopsBench: for Claude Code the share of solved tasks rose from 7.1% to 21.4%. On short tasks the effect is zero or negative.
To analyze the failures, they manually annotated full agent trajectories (inter-annotator agreement of 0.77). This produced a taxonomy of four categories: task orchestration, execution management, shared context, and shared state and merging. In total, 13 subcategories and 28 patterns.
A telling case is the rebuild of the seqtk utility. The lead agent handed out 22 subcommands to 20 sub-agents at once and started waiting for all of them. It set the wait timeout to 2 hours on a 40-minute budget. Two sub-agents made it in time, and the lead never got back to integration. In the end the program built, but some commands were missing: 92 of 440 tests passed. The surprise was that the failure was caused not by a bad idea to parallelize, but by the lack of a simple "do not wait for everyone" rule.
Adaptations and Extrapolations
🔧 Technique: independent review → catch the lead agent's mistakes
One of the conditions under which parallelism helped: a separate sub-agent reviews someone else's work. Add a separate block to the instructions:
After assembly, launch a reviewer sub-agent. It has not seen the coding process.
Its job: run the tests, find mismatches with the task description,
return a list of problems. Fix only what it found.
For small tasks this is cheaper than full parallel mode: one extra sub-agent instead of twenty.
🔧 Technique: alternative solutions → pick the best one
The second condition for a payoff in the paper is exploring alternative solutions. For a tricky spot, ask:
For the {module} module, launch two sub-agents with different approaches:
the first — {approach_A}, the second — {approach_B}.
Compare the results on the tests and pick the best one.
Extrapolation: a check before turning it on. Before launching a big project, ask the agent:
Assess the task: how many independent parts does it have and where do they overlap
in terms of files? Is it worth using sub-agents? Answer "yes" or "no"
and explain in one paragraph, based on cost (tokens) and the risk of conflicts.
This is my idea, not a result from the paper. You need to test it yourself.
Resources
- Paper: When Sub-Agents Work in Parallel: The Promises and Pitfalls of Dynamic Concurrency in Long-Horizon Coding Tasks (2026)
- Authors: Han Li, HanHaoNing Li, Ziqian Jiang (Nanjing University / Central University of Finance and Economics), Yiling Lou (University of Illinois at Urbana-Champaign)
- Mechanisms studied: Codex multi-agent v2, Claude Code Dynamic Workflow, Kimi Code AgentSwarm
- Task sets: RepoZero, ProgramBench, NL2Repo, LoopsBench, SWE-bench Verified
- Data: the authors publish 2124 run trajectories, the error-pattern annotations and the analysis scripts