Two Shapes of Agent Orchestration: The Advisor and the Fan-Out

The problem both shapes solve

Agent loops are token furnaces. Every turn re-reads context, every tool call round-trips the model, and long sessions compound it. Frontier models give you the best judgment per turn but cost the most per token; small fast models are nearly free but will confidently walk off a cliff on an architectural decision. So the real design question in any multi-agent system is not "which model is best" — it is "where does the judgment live, and how often do you pay for it."

The two shapes answer that question from opposite directions.

Shape 1 — Executor + Advisor: cheap loop, expensive judgment

Here the small model is the protagonist. It runs the main loop, edits the files, runs the tests — every turn, all session long. The frontier model is exposed to it as a tool: when the executor hits something above its pay grade (an architectural fork, a gnarly race condition, "should this be a migration or a new table?"), it makes a tool call, the advisor thinks hard once, sends advice back, and goes dormant again. You pay frontier prices only at the moments that deserve them.

• When I reach for it: long grinding sessions where 90% of turns are mechanical — refactors with a known recipe, test-fixing marathons, dependency upgrades. The executor grinds; the advisor referees.
• Same-provider version I run: a Sonnet-class executor in the harness loop with a Fable-class advisor behind a tool call. One SDK, one auth, shared conventions — the cheapest version of the pattern to set up.
• The failure mode: an executor that never calls the advisor (small models are overconfident) or calls it for everything (then you built the expensive shape with extra steps). The fix is explicit escalation triggers in the executor's instructions: "any schema change, any auth code, any decision you would describe with a tradeoff — call the advisor first."

Shape 2 — Orchestrator + Workers: expensive plan, cheap parallel hands

The inversion: the frontier model is the protagonist and never touches the grunt work. It decomposes the task, writes a brief per work item, fans out to N small workers — each running its own loop in isolation — then adversarially reviews what comes back and merges only what survives. The expensive model spends its tokens exclusively on the three things it is uniquely good at: planning, judging, and synthesizing.

• When I reach for it: anything parallelizable with verifiable output — repo archaeology across dozens of repositories, research sweeps, migration campaigns, multi-dimension code review, UI audits.
• Real example: the case studies on this blog were researched exactly this way — an orchestrator fanning out workers to excavate years of PR titles, contributor stats, and eval corpora across four GitHub orgs, then verifying every claim before a single line got published.
• The failure mode: trusting worker output. Small models return plausible garbage with total confidence. The orchestrator's review gate is not optional — it is the pattern. If nothing gets rejected, your review gate is theater.

Crossing providers: the harness is the interface

Nothing in either shape requires one vendor. The trick that makes cross-provider orchestration practical is realizing that a coding-agent CLI is just a tool call: almost every harness ships a headless mode with structured output. I regularly run a frontier model from one provider as the orchestrator while a different vendor's harness plays executor — a GPT-class planner directing Grok Build, or my Claude-side setup delegating mechanical sweeps to Grok running Sonnet-class workers in parallel. The harness CLI becomes the worker protocol.

This very site is maintained that way: one frontier agent as design lead and architect, delegating monotonous work — CSS dead-code sweeps, mechanical restyles — to Grok Build in headless mode. Each delegation ships as a written brief with acceptance criteria, runs in an isolated git worktree, returns structured JSON, and passes a review gate before anything merges. The delegate once caught orphaned styles the architect had missed; the architect regularly rejects delegate output. Both directions of that skepticism are the point.

Pick the shape by where the judgment lives. If judgment is occasional, make it an advisor. If judgment IS the job — planning, reviewing, merging — make it the orchestrator and never let it touch the grunt work.

What I would tell anyone doing this

1. Start with the advisor shape. It is one tool call away from a normal agent session and teaches you where your executor's judgment actually breaks.
2. Give executors explicit escalation triggers. "Ask when unsure" does nothing; "ask before any schema, auth, or dependency change" changes behavior.
3. In fan-out, the brief is the product. Every bad worker result I have ever gotten traced back to a lazy brief — underspecified acceptance criteria, missing context, no output contract.
4. Isolate with worktrees from day one. The first time two agents fight over the same working tree costs you more than every worktree you will ever create.
5. Meter it. Orchestration is an economics play — if you are not tracking cost per shape per task, you are guessing. I learned this building AI cost-tracking for a client platform before applying it to my own fleet.
6. Review like the output came from a stranger, because it did. The pattern is not "agents do the work" — it is "agents do the work, and the judgment layer earns its price by rejecting some of it."