The Conductor Prompt: Ten Specialist Roles, Five Workers in Flight

Anthropic's production research swarm typically spins 3-5 subagents in parallel. Claude Code Agent Teams tell you to start at the same range. Microsoft's Magentic-One ships five named agents: Orchestrator, Coder, Computer Terminal, File Surfer, Web Surfer.

The paste prompt circulating this week ("spawn ten specialists, merge results") treats a catalog as a runtime. Token cost scales linearly with teammates. Independent agents amplify errors 17.2x; a central manager cuts that to 4.4x (Kim et al., arXiv:2512.08296). You can list ten roles. You should rarely run ten.

A conductor prompt is a control plane in prose. It decomposes, names who can do what, routes, fails closed, then answers the parent task. The lead never does the work. Workers never invent the plan. Concatenating child logs is not aggregation.

Ten in the catalog, five in flight

oh-my-claudecode is the closest thing to a public "ten specialists" system people actually run. The agent catalog under .claude/agents/ can list 30+ roles (explore, planner, architect, executor, verifier, security-reviewer, code-reviewer, test-engineer, designer, writer). Each row maps to a model tier. The main session is a singleton orchestrator that must not write files. Concurrency stays small. The executor has to escalate to architect after several failed attempts.

That is the pattern. Capability descriptions live as rows a cheaper model can follow: name, when to use, when not to use, tools, output schema, model tier. If you cannot write the "when not" line, you do not have a specialist. You have a vibe.

CrewAI's hierarchical process encodes the same split in flags: the manager gets allow_delegation=True, workers get False. Production write-ups of the auto-manager (no custom routing table) show it handing work to the wrong person. The backstory is not flavor text. It is the routing table.

Anthropic learned the same lesson the hard way. Vague "research X" packets produced three subagents running the same search. Every packet needs an objective, an output format, tools and sources, and task boundaries. Tool descriptions are routing. Bad ones send the swarm down the wrong path.

Subagents and agent teams are different graphs. Subagents are a hierarchy: results flow up to the lead. Agent Teams are peers on a shared task list, messaging each other, with no central router per turn. Pick one. Mixing them in a single prompt is how you get nested spawn.

Decomposition that a cheaper model can follow

A subtask is atomic if one specialist can finish it against a closed output schema in one pass. If they cannot, it is not a worker task yet. Split it again. (ROMA names this the Atomizer test. Steal the test, skip the brand.)

A subtask is independent if two workers can run it without sharing uncommitted writes. Cognition's working pattern after they walked back a blanket ban on multi-agents: many readers, one writer. Parallel writers still collide on style, edge cases, and APIs. Two agents on the same file is a race, not a team.

Anthropic baked effort scaling into the lead prompt because models over-spawn:

• Simple fact: 1 agent, 3-10 tool calls
• Comparison: 2-4 subagents, 10-15 calls each
• Complex research with divided labor: more than 10 subagents

Their early failure mode was 50 subagents for a simple query. Their internal research eval showed Opus 4 lead + Sonnet 4 workers beating single-agent Opus 4 by 90.2% on breadth-first research. They said coding was less parallelizable, and that agents were not yet great at coordinating on that class of work. Do not paste that 90.2% onto a refactor.

Google and MIT later measured the split across 180 configurations. Centralized multi-agent: +80.9% on parallelizable financial reasoning. Every multi-agent variant: -39% to -70% on sequential planning (PlanCraft). Once a single agent already clears about 45% on a task, adding coordinators starts to hurt.

The conductor's first job is refusing the swarm on sequential work.

Failure is a ledger, not a pep talk

UC Berkeley's MAST study annotated 1,600+ traces across 7 frameworks (ChatDev, MetaGPT, Magentic-One, OpenManus, and others). Swarms fail at the seams. The top modes are step repetition (~16%), reasoning-action mismatch (~13-14%), and agents that never notice they should stop (~12%). "Ignored the other agent" is rare (under 2%). Model capability is not even a category.

Magentic-One put failure handling in JSON. The Orchestrator keeps a Task Ledger (facts + plan) on the outer loop and a Progress Ledger on the inner loop. Every round it fills structured fields: is_request_satisfied, is_in_loop, is_progress_being_made, next_speaker, instruction_or_question. next_speaker must be an exact agent name. Stall counter trips, it resets and replans. The manager never inspects a worker's internal tool state. It only sees what got written into shared history.

Community Claude Code routing has a matching ops lesson. Unbounded nested spawn has burned a 5-hour cap (millions of subagent tokens) on one "analyze this repo" prompt. The patch that actually works: hard cap N, forbid workers from spawning workers, require valid schema or the literal Failed:. Cancel walks an abort tree. Parent kills children.

Retry twice with the same packet plus the last error. Escalate after N failed executor attempts. If the output is not valid schema, treat it as Failed. Do not paraphrase a broken worker into a success.

Aggregation is a job

CitationAgent in Anthropic's research system does one thing: attribute claims. The lead synthesizes. The citation specialist does not rewrite the report.

Answer the parent task. Compress on the way up. Resolve conflicts against the packet, not by voting. Cite which worker produced which claim. If is_request_satisfied is false, replan. Do not append a random eleventh specialist.

Sakana's Conductor (a Qwen2.5-7B trained with RL, arXiv:2512.04388) is the other end of this: a small model that writes the worker prompts -- which worker, what instruction, which prior messages they may see. At publication it reported 83.9% LiveCodeBench and 87.5% GPQA-Diamond in about 3 steps, cheaper than Mixture-of-Agents on their mixed set. Simple facts got one call. Hard coding got planner, then coder, then verifier, on its own. You do not need to train a 7B. You do need the same discipline: the conductor outputs a workflow, not an essay.

When the prompt should become YAML

Microsoft's open-source Conductor CLI (14 May 2026, MIT) takes routing out of the LLM. YAML graph, Jinja2 conditions, zero tokens in the orchestrator. Parallel groups with fail_fast, continue_on_error, or all_or_nothing. Context modes: accumulate, last_only, explicit. Human gates are first-class. Mix a cheap model for classify, a mid model for research, a strong model for design.

Their claim is the one to keep: an LLM-as-router is right for exploratory work and wrong for known structure (review loops, research-then-synth, plan-then-implement). Once your conductor prompt stops changing, promote the graph. Until then, keep it in prose so you can edit it today.

The conductor you can paste today

Drop this in as the lead's system prompt. Fill the catalog for your stack. Leave max concurrent at 5 even if the table has ten rows.

The Prompt:

# CONDUCTOR
You do not implement, write files, or browse. You decompose, assign, wait, verify, and answer the parent goal.

## Catalog (name | when | when-not | tools | output schema | tier)
researcher     | independent questions        | writing prose or patches     | search          | {findings[], sources[]}           | cheap
implementer    | isolated file scope          | architecture or multi-file   | edit, test      | {diff, tests_run, tests_pass}     | mid
reviewer       | after a patch exists         | greenfield design            | read            | {blockers[], nits[]}              | strong
architect      | cross-file design, escalation| a single-function change     | read            | {plan[], file_owners[]}           | strong
verifier       | after implementer or reviewer| exploring a new question     | test, read      | {pass: bool, evidence}            | mid
security       | auth, input, secrets, deps   | copyedits                    | read            | {findings[], severity[]}          | strong
debugger       | a failing test or stacktrace | "make it nicer"              | read, test      | {root_cause, fix_scope}           | mid
writer         | docs, changelog, PR body     | code                         | read            | {markdown}                        | cheap
explorer       | locate files, map a repo     | editing                      | read, search    | {paths[], notes}                  | cheap
citation       | claims need sources          | generating new facts         | read            | {claim, source, quote}            | cheap

Max concurrent workers: 5. Catalog size is not concurrency.
Never assign two writers (implementer, writer) to the same file.
Prefer the cheapest tier that can satisfy the schema.

## Decomposition
Atomic if one catalog row can finish it against its schema in one pass.
Independent if two workers need no shared uncommitted writes.
Sequential dependencies stay on you as a pipeline. Do not swarm them.

## Task packet (every assignment)
objective, success_criteria, scope (files or urls), forbidden_actions,
output_schema, budget (tool_calls, seconds), parent_goal_id
Workers do not invent the plan. They execute the packet.

## Routing
Match the domain to exactly one catalog row.
next_speaker must be an exact catalog name.
Workers must not spawn workers.

## Failure
Retry 2 times with the same packet plus last_error.
After 3 failed implementer attempts, escalate to architect.
If output is not valid schema, record Failed. Do not paraphrase.
Cancel walks the abort tree: parent kills children.
If is_in_loop or is_progress_being_made is false for 2 rounds: replan the Task Ledger.

## Progress ledger (emit this JSON every round)
{
  "is_request_satisfied": false,
  "is_in_loop": false,
  "is_progress_being_made": true,
  "next_speaker": "researcher",
  "instruction_or_question": "...",
  "steps_completed": [],
  "final_answer": null
}

## Aggregation
Answer the parent goal. Compress. Resolve conflicts against the packet, not by voting.
Cite which worker produced which claim.
If is_request_satisfied is false, replan. Do not add a random specialist.

Why This Works: The lead is forbidden from doing the work, so it cannot short-circuit the catalog. Each row has a when-not line, so a cheaper model can refuse a bad assign. The progress ledger makes termination and routing machine-checkable, which is how Magentic-One stops step-repetition and "never halt" failures.

Expected Output:

{"is_request_satisfied": false, "is_in_loop": false, "is_progress_being_made": true, "next_speaker": "explorer", "instruction_or_question": "Map src/auth/**. Return {paths[], notes}. Do not edit. Budget: 8 tool calls. parent_goal_id: auth-lockout.", "steps_completed": ["packet written"], "final_answer": null}

Next round, after explorer returns paths: assign debugger on the lockout test, then implementer on one file, then verifier. security only after the patch exists. Five workers max. Parent answer is a lockout that holds, with the test transcript cited, not a dump of five agent diaries.

If your team is wiring multi-agent orchestration and the lead keeps doing the work (or the swarm never stops), we run live prompt engineering sessions on this. Connect with Kief Studio on Discord or schedule a session. New techniques also land at qurtoo.com.