If you build production agents, you might want to get familiar with a pattern that has a pretty unglamorous name: orchestrator-executor. An expensive model plans the work, delegates it to a team of cheap models, and checks what comes back. This just became the smartest way to build agents, not because we suddenly discovered this pattern (it’s 3 years old!), but because cheap models got good enough.
The flip happened in the last 13 months: in June 2025, Anthropic published an engineering post on their multi-agent research system, an Opus lead delegating to Sonnet subagents. Back then, their pitch was that quality is worth paying for, because the multi-agent version burned roughly 15 times the tokens of a normal chat. But recently, Anthropic published numbers for the same architecture with the opposite pitch: a Fable 5 orchestrator directing Sonnet 5 workers retained 96% of an all-Fable team’s score on BrowseComp, a benchmark of hard web research tasks, at 46% of the cost.
What is an orchestrator-executor agent architecture?
An orchestrator-executor system separates high-level control from bounded execution. The same shape appears under names such as orchestrator-worker, planner-executor, and coordinator-worker. The orchestrator decides how to break down the goal, which workers to call, what context each receives, whether the returned evidence is sufficient, and when the final result is ready. Executors handle narrower, token-heavy work such as search, document review, code inspection, test generation, extraction, or tool use.
Because each worker can have its own model, prompt, tools, and context, teams can match capability to role. Anthropic’s Managed Agents beta gives each agent an isolated thread and its own configuration. OpenAI’s GPT-5.6 ultra setting coordinates four agents by default, while the Responses API multi-agent beta lets developers run concurrent subagents and synthesize their work.
| Role | Owns | Select for |
|---|---|---|
| Orchestrator | Task decomposition, delegation, synthesis, verification, retries, and stopping decisions | Judgment, reliability, planning quality, and the ability to evaluate worker output |
| Executor | Bounded research, coding, extraction, review, and tool-heavy subtasks | Cost per successful task, latency, tool competence, and adherence to a precise brief |
- Plan: The orchestrator decomposes the goal and writes bounded briefs.
- Execute: Workers run independent tasks in parallel within isolated contexts.
- Verify: The orchestrator checks evidence, fills gaps, and synthesizes the result.
The separation matters because planning and execution have different cost curves. The orchestrator may consume a minority of the tokens, yet its decisions shape every downstream call.
Why did orchestrator-executor economics change in 2026?
In addition to Anthropic’s announcement, which came with API-level support for the pattern, OpenAI shipped the same shape two days later with a different sales angle. GPT-5.6 launched July 9 with an ultra tier “coordinating four agents in parallel by default,” pitched on speed rather than cost, alongside Luna at $1 per million input tokens, a model whose obvious job is to be the executor.
And if you’re looking for models to be executors, now’s a great time: Grok 4.5 on July 8, Cognition’s SWE-1.7 the same day at a reported $1.97 per coding task (Devin-only, so you can’t slot it into your own orchestrator), and a Databricks benchmark concluding GLM 5.2 is now a daily-driver coding model for their engineers.
This all landed in the same five days. That’s an architectural consensus, but it’s not a new architecture.
This is not a new pattern
There’s a bunch of papers about this pattern. HuggingGPT (March 2023) put an LLM in charge of a toolbox of specialist models, and Plan-and-Act (ICML 2025) formalized separate Planner and Executor models. FrugalGPT (May 2023) tried cheap models first and escalated to GPT-4 only on low confidence.
Then a paper with the slightly-too-cute title MinionS came out of Stanford in February 2025, with almost exactly the architecture Anthropic shipped this month. A frontier model decomposes a task by writing code that generates small jobs, local models execute the jobs in parallel and discard irrelevant results, and the frontier model aggregates and decides whether to loop. MinionS recovered 97.9% of GPT-4o’s quality at 5.7x less cloud spend, but it’s not an apples-to-apples comparison as they were running their executors on local hardware and not calculating the cost of those tokens.
The MinionS authors ran a retrospective and found their system wasn’t viable until mid-2024, because before that no small model could be trusted with a delegated subtask. The architecture has been waiting for better workers. How do you pick the model to be your executor?
Good executors are measured on cost per task, not per token
Models launched in July have been competing on a new metric, cost per completed task, that I’ve argued previously is the right way to judge a model. Arize’s own cost-per-successful-task benchmark makes the same point across ten models.
Artificial Analysis measured Grok 4.5 at rough parity with GPT-5.5 on their Coding Agent Index while using 1.9 million tokens per task, against 7.2 million for Fable 5 in Claude Code. That token efficiency, more than its token cost, is what lands it around $2.50 per completed task against roughly $12 for Fable. The big caveat: its measured hallucination rate roughly doubled against its predecessor, which is fine for a subagent being supervised, but not what you’d want running the whole show.
Databricks built a benchmark from their engineers’ real merged pull requests, graded by the original held-out tests rather than an LLM judge, and ran the model menu through it:
| Model | Task completion | Cost per task |
|---|---|---|
| Opus 4.8 | 87% | $1.94 |
| GLM 5.2 | statistically tied with Opus | $1.28 |
| Sonnet 5 | 81% | $2.09 |
Sonnet 5 is about 1.7x cheaper than Opus 4.8 per token, but it cost more per task because it read and reasoned through 1.9x more tokens to get there. The cheaper-per-token model was the more expensive model. That gap is why token costs alone don’t tell you if your AI is working.
So the executor tier isn’t “cheap models” in the price-sheet sense. It’s models that finish tasks cheaply, a property you have to measure (more on that in a second).
But if the executors are this good, why keep an expensive model in the loop at all?
Without a capable orchestrator, the executors perform poorly
Evidence that you can’t take the orchestrator out of the loop came from a Writer, Inc. paper posted July 8 that mostly isn’t about model choice. Writer ran the same 22 enterprise tasks on six models under two orchestration layers. They found delegation worked reliably only on the two strongest models in the panel, scoring around 0.85, and fell to unusable, around 0.45, on the fast tier. A 2025 planner-executor study called COPE found the academic version: larger planners improve smaller executors.
So cheap executors don’t mean you can cheap out on the orchestrator, because decomposing work, delegating it, and judging the results is precisely the capability with a floor.
Is there an alternative to the orchestrator-executor?
Yes, and it’s routing: instead of changing your architecture, get a router to send your “hard” queries to the most capable model, and the “easy” stuff to an executor-class model.
Unfortunately, the evidence for that in practice is currently poor. LLMRouterBench (ACL 2026 Findings) re-evaluated ten routing methods under one framework and found several, including the commercial router OpenRouter, fail to reliably beat simply using the single best model for your workload.
Orchestrator-executor currently seems to beat routing, though it’s worth noting that all the current evidence for that comes from vendors reporting their own numbers. Which brings me back to measurement: the only numbers that should change your architecture come from evals over your own tasks, with cost per completed task attached to every model in the system. That’s what we built Arize AX to do.
How can you build an orchestrator-executor agent today?
None of this requires waiting on a research preview. On the Claude API, Managed Agents is shipping today. In Claude Code, the pattern is a configuration choice: you can define subagents and specify what model they should use when they run. If you’re mapping this onto production agent shapes more broadly, start with three production patterns for AI agents and the role of the agent harness.
On OpenAI, you get the pattern by default at the top: GPT-5.6 ultra coordinates four parallel agents out of the box, and the multi-agent beta in the Responses API gives you the same shape with control over which model runs as which role.
The pattern spent three years in papers waiting for cheap workers that are good enough to trust. As of this week the workers are here, the tooling is a config file, and the price of finding out what it does for your workload is an afternoon. The expensive models deserve their place at the head of the team, but now you can stop paying them to do the typing.