People keep arguing about which AI model is smartest. That is the wrong test.

A model can score well, reason impressively in isolation, and still be the wrong system to put in charge of consequential work. The more useful question is whether an orchestrator can look at a job, divide it properly, choose the right model for each part, and keep the whole operation moving until something usable is delivered. Intelligence matters. The ability to allocate intelligence matters more.

I ran a same-day bakeoff with three orchestrators: Claude in the Fable family, Codex on GPT-5.6, and Grok Build. Each received the same handover. Each had to build a truth-first multi-agent storytelling production system, run it on three raw product-origin transcripts from the same teller, and ship finished sales-story pages with provenance. This was not a content-generation demo. It was a production race with two products: the harness and the stories.

The shared mission

The brief was identical across platforms. Build a team that receives stories rather than invents them. Differentiator: structural provenance, not prompt politeness.

Shared constraints included:

  • a provenance-locked fact ledger
  • one CLI-dispatch skill rather than four wrapper agents
  • a multi-model roster that could call Claude, Codex, AGY, and Grok
  • a filesystem state machine from inbox through in-process to handled
  • finished, true, arc-complete brand stories with every claim traceable

The handover even named a default roster: Analyzer/Interviewer, Purpose Strategist on Gemini Flash, Arc Architect on GPT-5.6 Sol, Voice Writer on Opus, Truth Custodian on GPT-5.5, Resonance Critic on Grok 4.5. Loop cap three, then escalate.

That shared framing is what makes the result interesting. Same mission. Same day. Different architecture decisions under time pressure.

The decision that split the race

FABLE and GPT stayed closer to the handover roster and both built full four-CLI dispatch. GROK did not implement the roster as written. It redesignated roles, defaulted much of the routing through AGY/Gemini, and never wired Codex.

That choice is load-bearing. One horse followed the prescribed team. One redesigned the team under the mission. The article is not “which model is best.” It is what happens when three orchestrators, given the same brief, choose different architectures and then have to ship.

What the clock actually said

All times below are from the operator bakeoff dossier on 2026-07-11 in Mountain Daylight Time. Client names are stripped.

Start of work

| Orchestrator | First evidence of work | |---|---| | FABLE | 05:40 | | GPT | about 05:56 | | GROK | 06:39, roughly an hour after the others |

First three-story package on disk

| Orchestrator | Elapsed from own start | Marker | |---|---|---| | GROK | about 1 hour 11 minutes | Full pipeline plus finals for all three stories | | FABLE | about 9 hours 55 minutes | Escalation package; gates not fully clean | | GPT | about 10 hours 20 minutes | Review packet for all three; L3 marked source-constrained |

GROK started last and still produced the first three-story delivery by a margin of roughly nine hours on raw wall-clock to package.

Later stopwatches tell a more careful story. GROK’s stronger named-destination and public-horizon passes landed later the same day. FABLE’s cleaner handled ship arrived the next morning. GPT stayed incomplete on L3 and held human approval as pending rather than inventing missing source.

Defensible headline times for the first complete three-story package under the bakeoff inputs: GROK about 1.2 hours; FABLE and GPT about 10 hours; GPT’s L3 still incomplete.

That is the speed result. It is not the only result.

Dual scoreboard: stories versus harness

Independent bakeoff judging on 2026-07-12 split the products.

Stories. A blinded Gemini judge ranked the story sets GROK first, GPT second, FABLE third, largely because only GROK delivered complete, skimmable, gift-plus-invitation structure on all three levels. A secondary Opus judge, with disclosed Fable-family conflict, also put GROK first. Per-level notes were less simple: FABLE often had the best individual prose while remaining under-structured for sales skim; GPT produced the best single L2 architecture and the most honest refusal to invent missing L3 source; GROK was the only complete set that was ready to operate as a package.

Harness code. The dispatcher ranking ran the other way. Analyst scoring put FABLE highest, GPT close behind, GROK last. FABLE’s CLI dispatch validated error surfaces, multi-artifact identity, and evidence retention. GPT’s PowerShell path was strongest on Windows process hygiene and Grok isolation. GROK’s multi-CLI skill was ergonomic and fixed real Windows encoding traps, but it never wired Codex, missed important stop-reason checks, and collapsed many roles onto AGY.

There is a sharper operator note under that ranking. All three AI assessments agreed that Fable wrote the best harness code, with GPT second and Grok third. When I looked at the code myself, something important was missing from that judgment. Grok’s code worked. The AI scoreboards weighted structure, completeness of traps, and polish. They underweighted whether the harness actually ran and produced the result under the same day constraint. That is another place where model assessment and operator truth can split.

Net for the operator:

  • GROK won the story race and lost the AI-judged dispatcher code race.
  • FABLE ranked highest on harness design quality and paid for foundation work in wall-clock.
  • GPT built serious compliance machinery, stayed honest about incomplete L3, and never closed the set.
  • Working code still matters more than the prettiest scorecard. Grok’s thinner harness still ran.

That split is the thesis worth keeping. Under a one-day constraint, product judgment and infrastructure rigor can disagree. AI code beauty contests can also disagree with code that works. Pretending they are the same score is how people overclaim.

What I think the mechanism was

The useful difference was not a single intelligence ranking. It was judgment under mission pressure.

GROK behaved like a ship-first operator that was willing to redesign the team when the prescribed roster did not match the path to finished stories. That produced speed and completeness on the story product. It also produced a thinner harness.

FABLE behaved like a foundation-first engineer. Hours of scaffold, live environment proof, and validation before serious prose. That produced better dispatcher discipline and slower story shipping.

GPT behaved like a compliance-first architect. Strong process artifacts, strong honesty about missing source, incomplete finish, and no git history that would have made the timeline cleaner for later auditors.

I am careful about scope. These are the results of this bakeoff: this mission, these three transcripts, these three orchestrators, this day. Different task types could reverse the ranking. A harness-heavy systems job might favor FABLE or GPT. A pure prose job might favor FABLE’s sentence craft. A deadline-driven multi-deliverable package favored GROK’s outcome orientation.

My earlier public impression was directionally right and too coarse. I said Grok finished in about an hour while the others failed across a day. The dossier shows something more precise: GROK started late, still reached the first three-story package in about 1.2 hours, and the others took about ten hours to comparable packages, with GPT incomplete on L3. That is enough to matter. It is not a permanent coronation.

The protocol I recommend

Anyone with access to comparable systems can run a better test than isolated prompts.

  1. Give each orchestrator the same consequential multi-agent mission.
  2. Require a real second product, not only infrastructure.
  3. Allow each system to choose or redesign its team.
  4. Keep a decision record: who started when, what shipped when, what was incomplete, and why.
  5. Score at least two boards: operator product quality and harness correctness.
  6. Allow refusal. An orchestrator that cannot leave a model unused is not routing. It is complying.

Then ask the only questions that matter. Did it finish? Was the work true? Could an operator send it? Did the infrastructure survive scrutiny? Where did the architecture diverge from the brief, and did that divergence help or hurt?

Operating implication

The next advantage is not only access to the model at the top of a leaderboard. Access is becoming abundant. The scarce capability is a control system that can translate an objective into roles, select the right intelligence for each role, inspect the work, and continue until delivery.

A company does not need a permanent answer to “Which model is best?” It needs a repeatable way to ask, “Which model is best for this job, under these conditions, inside this operation?” The answer should be allowed to change by task and by release. The protocol stays while the roster changes.

If you look closely at what was built in this bakeoff, the next step is small. Put a database in the middle that maps activity to vendor to model, and therefore to CLI. The model picker can then run a wide range of dynamic, current tasks against that map. After enough runs, it only needs a simple judgment loop: which model did this class of work best.

For every task class you should hold a primary, a secondary, and a tertiary model. Every now and then, run the same task through all three to see whether another model has taken the lead. Update the list. Operate off the list. That is continuous improvement of routing, not a one-time coronation.

If that ranking loop were published as a service, other operators would get dynamic model acquisition as a side effect of simply running this kind of test. The bakeoff is not only a winner announcement. It is the seed of a living routing table.

On this bakeoff, GROK was the best judge of how to finish the story product under time pressure, including willingness to abandon parts of the prescribed roster. FABLE and GPT were better at parts of the infrastructure problem. That is an operator result, not a religion.

My invitation is simple. Run a three-orchestrator test yourself. Preserve the decision record. Score product and harness separately. Judge what gets delivered. Then, if you want the durable version, keep the map.

More of Stephen’s work on engineered AI operations is available on his [profile](/stephen-nickerson/) and in [AI Latest](/ai-latest/).

_This article was researched and drafted by Mike, AI Chief of Staff for Stephen Nickerson, as part of StephenNickerson.com’s AI Latest foundation layer. Timeline and scoreboard details were updated from the independent bakeoff dossier after the first public version._

Sources

  • Stephen Nickerson’s three-orchestrator bakeoff dossier (client names stripped), private operator evidence package, 2026-07-11 to 2026-07-12.
  • Bakeoff unblinding and dual scorecards for stories and harness code under the storyteller evidence tree.
  • Public model release context for the model families named, 2026.

Stephen Nickerson.
Built for operators who need AI agents they can test, trust, and improve.