TL;DR
A main agent (Claude Code, Cursor, Codex) that can hand subtasks to sub-agents doesn't win anything automatically. A sub-agent works in its own context "window" and returns only a short summary to the main agent. This study checked how sensibly agents actually delegate and what that buys in quality, speed and money. The clear winner: narrowly specialized sub-agents (scoped by subject area) instead of generic "researcher / coder" roles.
The pain point is that agents delegate either too little or too much. With generic sub-agents, the agent gets shy about delegating: in more than half of the tasks where help was needed, it goes it alone and clogs its own context. Force it to call a planner first, and it starts delegating even trivial tasks, burning money for nothing. One of the top models spun up sub-agents on almost every task and gained nothing. The reason: a model has no internal "is this worth it?" meter. Its behavior is set by the instructions.
The bottom line: describe sub-agents narrowly, by subject area, don't force mandatory planning, and spell out when to delegate and when not to. Even with perfect delegation, sub-agents in the test bought speed, not quality, and you paid for it in cash.
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.
Method Blueprint
This is a finding about agent configuration, not a step-by-step technique. Here's the working setup distilled from the results:
LAYER 1: Main agent (instructions) → "when to delegate / when not to" rules + examples
LAYER 2: Sub-agents → narrow roles by subject area
• reconnaissance (read-only): literature, company data, financial markets, web
• changes (write access): external systems, reports/documents
LAYER 3: Planner → a separate sub-agent, but NOT a mandatory first step
LAYER 4: Sub-agent → returns a short summary, never calls "task complete"
All of this is configured in plain text: the system prompt, the instructions file, the sub-agent descriptions.
Example in Practice
Task: You run marketing for an online whole-bean coffee shop. Every Friday you need a rundown: competitor prices and reviews on Amazon and Etsy, search rankings, and a ready-to-go one-page report. The work happens in Claude Code with data sources connected. Simple requests like "rename the file" or "fix one number" the agent should just handle itself.
Prompt (a snippet for CLAUDE.md):
## Delegating to sub-agents
When to delegate:
- The subtask requires reading lots of material (reviews, listings, exports),
and I only need a summary.
- There are 2+ independent subtasks that can run in parallel
(for example, Amazon and Etsy).
When NOT to delegate (do it yourself):
- Editing a single file or a single number.
- Answering a question about data that's already loaded.
- The task takes 1-3 tool calls.
Sub-agents (use only these, don't create others):
- Marketplace-Researcher (read-only): collects competitor listings, prices and reviews
on Amazon and Etsy. Returns a summary of up to 300 words.
- Pricing-Analyst (read-only): compares prices and trends from the export.
Returns a table and 3 takeaways.
- Report-Builder (write): assembles the final 1-page report from the summaries.
Rules for sub-agents:
- Work only in their own folder.
- Return a short summary, not raw data.
- Never close the task themselves. Only I finish it.
Examples:
- "Analyze 5 competitors on two marketplaces" → two Marketplace-Researchers
in parallel (Amazon and Etsy), then Pricing-Analyst, then Report-Builder.
- "What's our average price in the export?" → I answer myself, no sub-agents.
Result: On a big task, the agent launches two researchers in parallel, then the analyst and the report builder. The main context stays clean because the raw reviews stay with the sub-agents. On small questions, the agent answers on its own without spinning up sub-agents. Test this on your own tasks: in the study, behavior varied a lot by model.
Why It Works
The weakness: an agent has no built-in sense of proportion. Without explicit rules, models swing to extremes. Some under-delegate: with vaguely described generic sub-agents, the agent can't tell what to hand off or to whom. Others over-delegate: after a mandatory "plan first," planning turns into a ritual and every little thing gets shipped to a sub-agent.
The strength: models follow a clear role with well-defined boundaries really well. If a sub-agent is called Marketplace-Researcher and does one kind of work, it's obvious to the main agent when it's needed. A generic "Explorer" offers no such hint.
The payoff: narrow roles turn a fuzzy "should I delegate, maybe?" into a simple choice. Explicit "when not to delegate" rules trim the excess. And reconnaissance happens in isolation, so the main context doesn't get clogged.
Control levers: - Delegation criteria ("only if there's a lot of reading or parallel parts") → stricter: less spend, looser: more help. - Sub-agent permissions (read-only / write) → the narrower the permissions, the safer. - "Delegate / don't delegate" examples → calibrate the model's tendency. This matters most for models that delegate at the drop of a hat. - Summary length limit → protects the main agent's context. - Sub-agent lineup → remove the ones that overlap in meaning.
Prompt Template
The authors' actual prompt texts aren't included in the main body of the paper (they're in the appendix). Per the description, the main agent received delegation norms, sub-agent profiles and a few examples. The template below follows that structure.
## Delegation rules
Delegate if:
- {condition_1: e.g., lots of material to read, but only a summary is needed}
- {condition_2: e.g., there are independent subtasks that can run in parallel}
Don't delegate if:
- {condition_3: e.g., the task takes 1-3 steps}
- {condition_4: e.g., the answer is already in the loaded data}
## Available sub-agents (don't create others)
- {Name_1} ({read-only / write}): {narrow area of work}.
Returns: {summary format, length limit}.
- {Name_2} ({read-only / write}): {narrow area of work}.
Returns: {summary format, length limit}.
- {Name_3} ({read-only / write}): {narrow area of work}.
Returns: {summary format, length limit}.
## Rules for sub-agents
- Work only in {their_folder/area}.
- Return a short summary, not raw data.
- Never finish the overall task. The main agent finishes it.
## Examples
- "{big_task_example}" → {whom to launch and in what order}.
- "{small_task_example}" → I do it myself, no sub-agents.
What to fill in: pull your delegation conditions from your own pain points (where the context bloats, where there are independent parts). Name sub-agents by subject area, not by action ("Competitor-Researcher," not "Explorer"). Take the examples from real tasks.
🚀 Quick start — paste into the chat:
Here's an instruction template for a main agent with sub-agents. Adapt it to my task: [your task].
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask about your typical tasks, where your context bloats, which sources and tools you use, and which tasks are definitely simple. It needs this to tightly scope the sub-agent roles and write honest "delegate / don't delegate" criteria. It'll take the pattern from the template.
Limitations
⚠️ Delegation doesn't raise quality on its own: even with near-perfect delegation, the final success rate landed at the level of a single agent. Sub-agents delivered speed, not accuracy, and cost more.
⚠️ It's expensive: for most models, delegation drives up costs. For the closed models in the test, it came with both higher spend and worse results.
⚠️ Model-dependent: models differ wildly in how eager they are to delegate. Some hand off almost everything, others are shy. You'll have to calibrate the instructions for your model.
⚠️ Narrow test bed: all experiments ran in a single agent framework on tasks with MCP tools (learning systems, data warehouses, e-commerce, stock exchange, video, railways, science, food service). Transfer to your tasks (code, writing) hasn't been tested.
⚠️ Conclusions about prompt variants come from one model: the "generic / specialized / planner-first" comparison ran on a single low-cost model. Results may differ for others.
⚠️ No ready-made prompts: the authors' instruction texts aren't in the main body; the template above is a reconstruction from the description.
How They Tested It
The authors took 166 work tasks from the Toolathlon-Gym environment: eight domains, long chains with real tools. For each task they hand-labeled a ground truth: whether to delegate, which sub-agents, and in what order. The result: 89 tasks where help is needed, and 77 where the agent can manage alone.
They compared a single agent against four delegation setups: generic sub-agents, specialized ones, a mandatory planner first, and an "oracle" (the agent was handed the ideal plan outright). They measured three things. First: does the agent delegate at the right moments, i.e., misses and unnecessary launches. Second: do the launched sub-agents match the ground truth. Third: what it yields in success, steps and money compared to a single agent. Everything was rolled into an MSQ index.
The results were surprising. The oracle, with near-perfect delegation, didn't raise success, only speed. So the main benefit of sub-agents is parallelism and context offloading, not "smarts." The mandatory planner didn't help; it hurt, triggering mass delegation where none was needed. Of the eight models, the top six were open-weight, while two closed flagship models ended up at the bottom. One launched sub-agents on nearly every task, and all its metrics sank below parity. The practical takeaway: don't leave the "should I delegate?" decision to the model; set it with rules and narrow roles.
Adaptations and Extrapolations
🔧 Technique: drop "planner first" → fewer unnecessary launches
Instead of a mandatory planning step, write: "Plan yourself, briefly. Call the planner sub-agent only if there are more than three subtasks." The paper showed that a mandatory planner inflates delegation. A soft condition should remove that effect, but the authors didn't test this variant.
🔧 Technique: add a self-check block before launching a sub-agent → fewer pointless launches
Before launching a sub-agent, answer in one line: 1) Is there a lot of material to read? 2) Are there parallel parts? If both are "no" — do it yourself.This is my own extension based on the findings about under- and over-delegation. It hasn't been tested in the paper.
Extrapolation: audit your own sub-agents. Paste your list of sub-agents into the chat and ask:
Here are the descriptions of my sub-agents: {list}. Find overlaps in meaning,
roles that are too generic, and sub-agents without a clear launch condition.
Suggest how to narrow the roles by subject area and what to merge.
Resources
- MS-Eval: Benchmarking Sub-Agent Delegation and Orchestration in MCP-Intensive Working Scenarios (preprint)
- Code: https://github.com/LINs-lab/MS-Eval
- Authors: Bowen Ding, Qixin Wang, Lexing Yuan, Weiyi Lu, Qiwei Ge, Ruishan Fang, Tao Lin
- Affiliations: Zhejiang University, Westlake University (School of Engineering; Institute of Advanced Technology, Westlake Institute for Advanced Study)
- Benchmark basis: Toolathlon-Gym; framework for runs: Kimi-Code