Orchestrator and workers: the model loop that beats one big model
Pull-quote: “Delegating to a cheap worker stops being cheap the moment its failure rate forces a second attempt. The unit is cost per completed task.”
The emerging shape for hard agent tasks is one strong model that plans, delegates, verifies, and escalates, several cheaper models executing bounded subtasks in parallel, and a premium model held out of the hot path for judgment calls. What decides whether that shape works is the delegation contract, not which models you picked.
This post assumes the single-loop discipline covered in prompt looping and loops that close: stop conditions evaluated by the harness, a named exit reason on every run, oscillation detection, and verification as an independent read. All of it still applies to every loop here, and none of it is repeated. What follows is the layer above: more than one loop, who talks to whom, and how the money behaves. By the end you will be able to write a delegation contract a worker can execute without guessing, partition work so parallel workers do not collide, and calculate whether the arrangement is cheaper than one model.
What you will be able to do
- Say when an orchestrator-worker loop beats a single model, and when it only costs more.
- Write a delegation contract with the six fields a worker needs to run unsupervised.
- Partition parallel work so subagents neither duplicate each other nor leave gaps.
- Verify worker output structurally, evidentially, and independently.
- Set three escalation tiers so the premium model is called on judgment, not volume.
- Compute cost per completed task and find where a cheap worker stops being cheap.
What is an orchestrator-worker loop, and when does it beat one model?
An orchestrator-worker loop is one in which a central model decomposes a task at run time, delegates the pieces to worker models, and synthesises their results, with subtasks determined by the input rather than fixed at design time. Anthropic names the pattern in Building effective agents and draws the distinction that matters: it resembles parallelisation, but there the subtasks are predefined, and here the orchestrator invents them.
The published evidence for when it wins is unusually specific. Anthropic reported that a research system using Claude Opus 4 as the lead agent with Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on their internal research evaluation. Their analysis of what drove it is the more useful number: on BrowseComp, token usage alone explained 80% of the variance, with tool call count and model choice the other two factors, the three together explaining 95%.
Read that as the mechanism rather than a marketing claim. The pattern wins largely because it spends more tokens of reasoning on the problem, distributed across separate context windows so each worker can go deep without crowding out the others. That also tells you when it loses. Anthropic’s figures put agent token usage at roughly four times a chat interaction and multi-agent systems at roughly fifteen times, and they note that most coding tasks contain fewer genuinely parallelisable subtasks than research does.
| Good fit | Poor fit |
|---|---|
| Breadth-first questions with independent directions | Sequential work where step two needs step one’s output |
| Evidence that exceeds one context window | Tasks where every agent needs the same shared state |
| Many complex tools with distinct purposes | A single lookup dressed up as a research question |
| Tasks valuable enough to justify fifteen times the tokens | High-volume, low-value work priced per request |
What must be in a delegation contract?
Six fields: objective, output schema, tool allowlist, budget, boundary, and done-condition. Anthropic reports that without detailed task descriptions, subagents duplicate work, leave gaps, or fail to find what they were sent for, their example being two agents investigating the same supply chain while a third wandered into a different decade.
| Field | What it states | What happens when it is missing |
|---|---|---|
| Objective | The one question this worker answers | The worker restates the parent task and drifts |
| Output schema | The typed fields the orchestrator will parse | Prose the orchestrator has to re-read with another model call |
| Tool allowlist | Which tools this worker may call | A research worker reaches for a write tool |
| Budget | Maximum steps, tokens, and wall clock | One slow worker holds the entire synthesis |
| Boundary | What this worker must not cover | Two workers converge on identical searches |
| Done-condition | The observable state that ends the run | The worker keeps searching after it has the answer |
{
"worker_id": "w2",
"objective": "List every FDA warning letter issued to the three named sites in 2025, with dates and cited CFR sections.",
"output_schema": {
"findings": [{ "site": "string", "letter_date": "date", "cfr_sections": ["string"], "source_id": "string" }]
},
"tools": ["fda_search", "document_fetch"],
"budget": { "max_steps": 12, "max_tokens": 60000, "max_seconds": 180 },
"boundary": "Do not cover recalls or import alerts. Worker w3 owns those.",
"done_when": "Every site has either at least one letter or an explicit no-results record."
}Effort scaling belongs in the orchestrator’s own instructions, because models judge appropriate effort poorly. Anthropic embedded explicit rules: simple fact-finding gets one agent with three to ten tool calls, a direct comparison gets two to four subagents with ten to fifteen calls each, and complex research goes above ten. Your trajectories should replace those numbers eventually, but an explicit rule beats none, because the untuned failure mode is spawning dozens of workers for a question one lookup would answer.
How do you run workers in parallel without them duplicating each other?
State the partition in the negative and make it observable, because two workers handed adjacent descriptions converge on the same searches without knowing it. “Research the 2025 filings” and “research recent filings” are the same instruction to a model.
Three mechanisms carry most of the weight. Write exclusions into the boundary field, naming the sibling that owns the excluded slice, so a drifting worker has a reason to stop. Give each worker a claim row in a shared table, using the claim-and-skip pattern an approval queue uses, so the partition is a database fact rather than a hope in a prompt. And parallelise at two levels: Anthropic spins up three to five subagents at once and has each call three or more tools in parallel, which they report cut research time by up to 90%.
The information path back matters as much as the split. When workers return full outputs through the orchestrator, its context fills with material it does not need and the synthesis degrades the way any overlong context degrades. Anthropic’s alternative has subagents write output to a store and pass a lightweight reference back. Do that for anything longer than a page.
One structural limitation is worth knowing first. Anthropic’s lead agents execute subagents synchronously, waiting for a set to finish before proceeding. That simplifies coordination and costs two things: no mid-flight steering, and the system blocks on the slowest worker. If you build synchronously, give every worker a wall-clock budget and make partial synthesis a supported outcome rather than an error.
Who verifies the work, and against what?
The orchestrator verifies against evidence it can resolve itself, never against a worker’s claim of success. A worker reporting that it finished is the least reliable signal in the system, and the one most systems are accidentally built on.
Verification comes in three strengths and you want all three. Structural verification means the returned object validates against the schema you sent, which is free and catches the largest class of failures. Evidential verification means every finding carries a source_id the orchestrator can resolve to a real document, and rows that do not resolve are dropped rather than synthesised. Independent verification means a separate read of the world or a deterministic check, and it alone catches a worker that was confidently, coherently wrong.
Anthropic implemented the evidential layer as a role: after the research loop exits, a separate citation agent attaches specific citations to specific claims. Making it a distinct step rather than an instruction is what makes it auditable. What a model can and cannot check about its own output is the subject of agents that check their own work, and the short version applies here: a check is worth its cost only when the checker has information the generator did not.
When should the loop escalate, and to whom?
Escalate on judgment, not on volume, through three tiers. A worker escalates to the orchestrator when it hits its boundary, its budget, or a false precondition. The orchestrator escalates to an advisor model when the decomposition itself failed, when two workers returned contradictory evidence, or when the remaining decision is a trade-off rather than a lookup. Anything escalates to a human when the next action is irreversible or needs a permission the system does not hold.
| Trigger | Tier | What gets handed over |
|---|---|---|
| Budget exhausted with partial results | Worker to orchestrator | Findings so far, plus what remains unexamined |
| Precondition false, such as a missing record | Worker to orchestrator | The failed assumption, not a retry |
| Two workers contradict each other | Orchestrator to advisor | Both claims with their sources, and the question |
| Plan produced no progress across a window | Orchestrator to advisor | The plan, the trajectory, and the metric that stalled |
| Irreversible write, or a permission not held | Any tier to human | The exact action requested, ready to approve |
The advisor tier is where a premium model earns its price. It is called once per hard case rather than once per subtask, so its cost scales with the difficulty of the work rather than the volume. Putting that model in the hot path is the most common way to build something that demos well and is unaffordable at load.
What does the cost curve actually look like?
The unit is cost per completed task, and writing it out makes the cheap-worker intuition conditional. The expected cost of one delegated run is:
cost_per_task
= orchestrator_plan
+ n_workers x (worker_cost / worker_success_rate)
+ verification_cost
+ p_escalate x advisor_cost
+ p_human x human_review_costEvery term except the second is usually forgotten. Teams compare published per-token prices, which is only the numerator inside that term, then find the bill has not fallen.
The second term contains the crossover. If the orchestrator could do a subtask itself at cost O, and a worker does it at cost W with success rate s, delegating is cheaper only while W / s < O. A worker priced at a fifth of the orchestrator stops paying for itself once its success rate falls below one in five, and it was marginal well before that, because each failure also costs a verification pass and an orchestrator turn to notice. That is why worker success rate per subtask type is the most valuable thing to instrument.
The curve also says what parallelism buys. It does not reduce tokens, and Anthropic’s roughly fifteen times figure is the honest headline. It converts tokens into wall clock, which is why an hour of sequential work returns in minutes. If your constraint is budget rather than latency, fan-out is the wrong lever and a better single loop is the right one, an accounting worked through in LLM cost and latency engineering.
Log five fields per run and the curve stops being theoretical: orchestrator tokens, worker tokens by model, re-delegation count, escalation count and tier, and whether the task completed. Group by task type. The instrumentation is right when you can answer “which subtask type has the worst worker success rate” without opening a trace.
Where this goes wrong
Delegation by paraphrase. The symptom is two workers returning the same findings in different words. The cause is adjacent objectives with no stated exclusion. Write the boundary in the negative and name the sibling that owns the excluded slice.
The orchestrator reads everything. The symptom is a synthesis that degrades as more workers report. The cause is full outputs copied back through the lead. Have workers store artifacts and return references.
Verification by self-report. The symptom is a confident final answer citing findings that do not exist. The cause is an orchestrator that trusted worker prose. Require structured claims with resolvable source identifiers, and drop the rest.
Unbounded fan-out. The symptom is a simple question spawning a dozen workers and a bill to match. The cause is no effort-scaling rule. Put worker counts per query class in the orchestrator’s instructions and cap the count in the harness, because an instruction is not a limit.
Blocking on the slowest worker. The symptom is p95 latency tracking the worst subtask rather than the median. The cause is synchronous execution with no per-worker deadline. Give each worker a wall-clock budget and make partial synthesis a first-class outcome.
The premium model in the hot path. The symptom is advisor spend scaling linearly with subtask count. The cause is calling the expensive model per subtask instead of per escalation. Move it behind the escalation triggers.
Common questions
Is this the same as using a multi-agent framework?
No. The pattern is an architecture and a framework is one way to implement it, usually in a few hundred lines either way. Frameworks help with plumbing such as message passing and retries, and cost you visibility into the prompts and the exact delegation payload, which is what you will want to inspect when a worker misbehaves.
How many workers should I run in parallel?
Start with a rule per query class rather than a global number, then tune it from your own trajectories. Anthropic’s published starting point is one agent for simple fact-finding, two to four for a direct comparison, and more than ten for complex research, with three to five running concurrently.
Should the workers all be the same model?
Not necessarily, and the choice should follow the subtask rather than a preference. Extraction and comparison against a fixed schema are usually fine on a small model, while a subtask needing genuine judgment inside the worker either needs a stronger model or should not have been delegated. Measure success rate per subtask type per model, because that is what the cost equation consumes.
What is the first thing to instrument?
Worker success rate by subtask type. It is the denominator in the cost equation, it says whether a cheaper model is viable, and it is the earliest indicator that your delegation contracts are underspecified.
Next steps
Pick one multi-step task your agent handles today and write the delegation contract for its subtasks by hand, all six fields, before changing code. Most teams find they cannot state the boundary field, which is the finding rather than the obstacle.
Then read agents that check their own work, because an orchestrator verifying its own workers runs into the limits of model self-assessment, and knowing where those limits sit changes the verification step. For the mechanics inside each loop, prompt looping and loops that close is the prerequisite, and when failures start arriving in patterns, a failure taxonomy for production agents names them.
The orchestrator and worker split, with the advisor tier held back for escalation rather than run in the hot path, is the shape behind Aquil in geopolitical intelligence work, where breadth-first collection across independent sources is the task rather than a feature of it.