Planning-First Delegation: subagents only scout and plan, the lead agent writes the code

STEP 1 (lead, strong model): splits the task into non-overlapping
        scouting questions → list of subtasks
STEP 2 (workers, a cheap model is fine): each studies its own piece
        in parallel → short report to the lead
STEP 3 (lead): waits for ALL reports, assembles a single plan → plan
STEP 4 (lead, alone): writes the code → implementation
STEP 5 (lead, alone): verifies the result → final output

Rule: workers operate only in steps 1–3.

All of this is set up through the agent's instructions. The steps run sequentially within the lead's single session. The workers are separate subagents with their own context.

Task: your company still runs an old command-line shopify-export.exe that exports orders for accounting. There's no source code, and the author left the company. You need to reproduce its behavior in Python. It's the same "black box + documentation" situation as the study's benchmark, just in a business setting. You launch Claude Code and give it this instruction.

Prompt:

Task: rewrite the shopify-export.exe utility (in ./legacy/) in Python.
There's no source code, only the file itself and readme.txt. I need a
program that behaves identically on any input.

Working mode: you are the lead. Delegate ONLY the scouting and planning
stage to subagents. Write and verify the code yourself.

1. Split scouting into non-overlapping questions, for example:
   — input file format and command-line flags;
   — format and encoding of the output CSV;
   — behavior on edge cases (empty file, broken rows, non-ASCII
     characters in product names, amounts in cents);
   — exit codes and error messages.
2. Launch all subagents in one volley. Give each one subtask and
   ask for a short report: what it ran, what it got, conclusions.
3. Wait for reports from ALL subagents. Don't start writing code based on
   partial results.
4. Assemble a single plan from the reports and write the implementation yourself.
5. Verify the implementation yourself: run it on the same examples and compare
   the output with the original.

After step 3, don't launch any new subagents.

Result: the agent splits scouting into several independent directions and launches the subagents in one volley. Then it waits for the reports, assembles a plan and writes the code itself. At the end it runs a comparison against the original. You won't see any new subagents after planning. Token usage will be noticeably lower than if the subagents were also writing modules.

The weakness. When several agents write code in parallel, each one sees only its own piece. They create extra files, duplicate functions and break each other's edits. The lead spends time and tokens stitching it together. Reviewer agents add almost nothing: after the first few, new information about the program runs out.

The strength. Scouting parallelizes well. Questions like "how does the program behave on edge cases" are independent, and the output is short text. Stitching reports together is easier than stitching code. On top of that, trying lots of different inputs is cheaper than writing coherent code. That's why you can keep adding planners and quality keeps rising, while for implementers and reviewers the gain plateaus at around four.

How the method uses this. Everything parallel goes into an early scouting volley, and everything that has to be coherent (code, integration, final verification) stays with one agent. A cheap model in scouting does no harm: the lead decides what to do with each report. In implementation, though, a cheap model drags quality down, because the lead receives code that needs fixing.

Control levers: - Delegation stage (scouting / implementation / verification) → scouting gives the biggest gain per dollar. For tasks where the structure is already set (say, there's a scaffold and tests), delegating implementation pays off better. - Worker model → use a cheap one for scouting, the same one as the lead for code. - Lead model → put your budget here. Cheap workers don't make up for a weak lead. - Number of workers → in scouting you can keep scaling. In implementation and verification, more than four is pointless. - Waiting for reports → the phrase "wait for all reports" matters. Without it, a lead running in parallel acts on incomplete data or wraps up the task too early.

In the study, the full instruction texts are in Appendix D, which isn't in the part we have. Below is a reconstruction based on the description of mode P (planning): workers only in planning, the lead does the rest.

You are the lead of an agent team. Task: {task}.

Materials: {what_the_agent_has}.

DELEGATION RULES
— Delegate ONLY scouting and planning to subagents.
— Do implementation and verification yourself.
— Subagent subtasks must not overlap.
— Each subagent sees only its own subtask, not the whole task.
  Phrase each subtask so it makes sense without context.

WORKFLOW
1. SCOUTING. Split the study of the task into {number_of_directions}
   independent questions: {example_directions}.
2. VOLLEY. Launch the subagents in one batch, before any work
   on the deliverable. Ask each to return a short report:
   what it did, what it found, what remains unclear.
3. WAIT. Wait for reports from ALL subagents. Don't act on partial
   results and don't finish the task until all reports are in.
4. PLAN. Assemble a single plan from the reports. Note contradictions and decide how
   to resolve them.
5. IMPLEMENTATION. Do it yourself.
6. VERIFICATION. Verify it yourself: {how_to_verify}.

After step 3, don't launch any new subagents.

What to fill in: - {task} — what you need as the output. - {what_the_agent_has} — files, access, documentation, source data. - {number_of_directions} — how many independent questions you can carve out (usually 3–6). - {example_directions} — scouting axes might be: interface, edge cases, data format, errors, dependencies. - {how_to_verify} — tests, comparison with a reference, a checklist.

🚀 Quick start: paste this into a chat:

Here is a Planning-First Delegation template. Adapt it to my task: [your task].
Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask what the agent has as input and how to split scouting into non-overlapping directions. That matters because the method depends on independent subtasks: overlapping questions lead to duplication. It will take the pattern from the template and tailor it to your task.

⚠️ Depends on the task: the method wins where the bottleneck is understanding the task. In the test, that was a "black box" to be figured out. If the structure is already set (there's a scaffold, tests, a clear spec), delegating implementation is more useful.

⚠️ Cheap executors hurt in code: if you hand code-writing to a cheap model, quality drops below a single strong agent while costs go up.

⚠️ A weak lead can't be rescued: cheap workers under a weak lead still lose to one strong agent. Don't skimp on the lead.

⚠️ A team still costs more than a solo agent: even the optimal setup costs noticeably more than one agent and usually takes longer. If one agent can handle the task, you don't need a team.

⚠️ The gain is bigger on easier tasks: on the hardest tasks, the boost from a team is smaller.

⚠️ Async mode without an instruction spoils the result: if the lead keeps working while the workers are still computing, it often acts on incomplete data or finishes too early. You need an explicit "wait for all reports".

⚠️ Tested on code: the conclusions come from programming tasks and mostly from one model family. Carrying them over to writing, research and analytics is a hypothesis.

The Cohere Labs team built a minimal "lab" multi-agent system: the lead receives a task, spawns workers via a delegate_agent tool and collects the results. Then they changed one parameter at a time: at which stage the lead delegates (plan, implementation, verification or all at once), which models are on the team and how many workers there are. The main test was ProgramBench: 200 tasks where the agent gets a working program with no source code (from simple utilities to FFmpeg and a PHP interpreter) and has to recreate it. Each variant was run three times. They also checked on Commit0-Lite (16 libraries) and on Claude and Gemini models.

The result was unexpected: "delegate everything" turned out no better than "delegate only planning", but twice as expensive. The logs showed why: with planning, all calls go out in one volley before the first line of code. The full setup added about 830 more calls for implementation and verification, and they contributed nothing. Planning delivers 2.4 times more quality per call.

The second surprising result: a cheap model on planning delivers roughly 13 times more quality per dollar than an expensive one. A strong lead with cheap planners gets 47.5% of the gain of an all-strong team for 13.9% extra cost. In implementation, the same swap wrecks the result. The lead sets the ceiling: switching the lead from cheap to mid-tier gives +21%, then to strong another +15%. On the number of workers: in planning, quality keeps rising, while implementers and reviewers plateau after four. Implementers fragment the code into more and more files, and reviewers add almost no new information about the program. The headline example: a heterogeneous team of 17 agents came within 1.4 points of a strong homogeneous team of 5 agents at 70% lower cost. The part about messaging between workers (section 8) is cut off in the available text.

🔧 Technique: add a waiting clause → protection against premature conclusions

In the study, during async operation the lead often acted on incomplete data without an explicit instruction. The instruction "first collect all reports" closed that gap. Add this to any prompt with subagents:

Don't start synthesizing until you've received a report from every subagent you launched.
If a report is missing, wait rather than fill in the blanks yourself.

🔧 Technique: a cheap model for scouting → savings without losing quality

In Claude Code or Cursor, where you can set a subagent's model, pick a lightweight model for scouting subagents (searching the repo, reading docs, trial runs). Your main strong model stays as the lead. For subagents that write code, pick the same model as the lead.

Extrapolation (not tested in the paper, just a hypothesis): the same principle, "parallel scouting first, then synthesis by one agent", can be tried outside of code. For example, for a market analysis:

You are the lead. We need to decide whether our delivery service should
expand to Denver. Launch subagents in one volley for scouting:
— competitors (DoorDash, Uber Eats, local players),
— courier unit economics in the city,
— regulation and rent,
— seasonality of demand.
Each returns a half-page report with sources.
Wait for all of them, then write the recommendation yourself. Don't launch
any new subagents after that.

• Scaling Inference-Time Compute with Teams of Coding Agents — Keenan Samway, Daniel D'souza, Omar Darwiche Domingues, Marzieh Fadaee, Tan Yi-Chern, Nouha Dziri (Cohere Labs / Cohere).
• Benchmarks: ProgramBench (Yang et al., 2026a), Commit0 (Zhao et al., 2024).
• Foundation of the "lab": mini-SWE-agent (Yang et al., 2024), ReAct (Yao et al., 2023).
• Full prompts for modes P, I, V, PIV are in Appendix D of the original (missing from the provided text).