Orchestrator–Executor: A Two-Agent Split That Beats a Solo Model on SWE Tasks

Most coding agents are a single model doing everything at once, exploring the repo, deciding on an approach, writing the code, and checking its own work. That works until the task has a hidden correct procedure the model can't see, and it confidently ships something that looks right and fails the grader.

We ran an experiment with a different shape: split the agent into two roles. A strong orchestrator explores, reasons, and writes a precise plan. A cheaper but capable executor does the hands-on implementation. Here's what that division of labor actually buys.

The split: a planner and a worker

The architecture is an orchestrator agent that delegates to a stateful executor subagent. The orchestrator runs four jobs the solo model tends to rush:

Explore. The orchestrator (Opus 4.8) reads the environment, disassembles binaries, checks library versions, and aligns the data before committing to anything.

Lock the plan. It commits to a specific algorithm or procedure, often rejecting the naive approach. On one cryptanalysis task it derives a 2²⁰+2²⁰ meet-in-the-middle attack instead of a 2⁴⁰ brute force.

Delegate a precise brief. It hands the executor an implementable spec with hard constraints: do NOT redesign the algorithm; implement what is specified, then verify.

Review against the grader. On handback, the orchestrator verifies the artifact (an L2 image compare, od -c on the output file) and runs the tests before declaring the task done. If verification fails, the executor rectifies and the loop repeats.

The executor is a swappable, cheaper model that implements the brief and hands back a status plus test output. The interesting question is what each side is really contributing.

The results

Across the suite, the orchestrated stack with GLM-5.2 as executor cleared 10 more tasks than the same model running solo, at a higher per-task cost, but a measurably higher ceiling.

Two numbers are worth sitting with. The executor choice matters under the same orchestrator: GLM-5.2 beats Kimi K2.7 by +11.3 mean / +10 passes on identical tasks (51 both pass, 11 GLM-only, 1 Kimi-only). Kimi also timed out more (17 agent timeouts versus 10) and burned more on doomed long-horizon tasks, including $26.59 on make-doom-for-mips alone.

And GLM-5.2 solo ties the Kimi-executor stack at 45% of the cost. A cheaper model alone can match a more expensive orchestrated stack, which means the orchestrator only earns its keep if it lifts the ceiling, not just the average.

Where orchestration actually helps

The split pays off on tasks with a hidden correct procedure, where a solo model produces plausible-but-grader-wrong work, or never ships a deliverable at all. The orchestrator's job is to discover and compress the correct procedure into a brief, then gate "done" on a grader-shaped check rather than a local one.

The trajectory evidence is striking because it's the same executor model with opposite outcomes. The only difference is whether an orchestrator scoped the work first:

The unifying lesson: hidden verifiers check the reference procedure, not the result's surface plausibility. A solo model that "optimizes the query" or "computes a similarity" gets the shape right and the grader wrong. The orchestrator discovers the right procedure and verifies against the actual bar.

The executor is swappable; the orchestrator is not

This is the asymmetry that makes the architecture practical. The executor seat is a commodity: rank candidates by productivity-per-dollar and swap freely. Under a fixed Opus orchestrator, GLM-5.2 > Kimi K2.7 > MiniMax ≈ Nemotron.

The orchestrator seat is where the passes live. Swap Opus for a cheaper planner (Opus to GPT-5.5) and the score roughly halves while winning nothing new. Planner reasoning is what discovers the hidden procedure; you can't buy it back with a stronger executor.

Why this matters for Blackbox

This is exactly the division of labor Blackbox's multi-agent execution is built around. You can seat a frontier model as the orchestrator, run a cheaper model as the executor, and swap that executor per task to tune productivity-per-dollar, all without rewiring your workflow.

The takeaways are clean. Split planning from execution and you buy roughly +11% mean and +10 passes on Terminal-Bench 2.0. Treat the executor as swappable and rank it by cost-efficiency. Keep a strong planner in the orchestrator seat: that's where the wins come from. And cap the budget, because a higher ceiling doesn't mean an unlimited one.