The Gauntlet Loop, tested: four runs of Matt Shumer's method

Last updated: August 11, 2026

TL;DR

• The Gauntlet Loop is Matt Shumer's method for getting agent output past "pretty good": the agent splits a goal into pieces, each piece gets a builder sub-agent and a blind critic, and the critic compares candidate against a real reference until the candidate wins.
• The viral 150-word prompt is a compressed artifact. The parts that decide success – reference material on disk, a live status page, the ratchet – live in your setup, not in the prompt text.
• I ran the method four times on WotAI Games: Snake (timing and lifecycle repair), Doodle Jump (physics and period-accurate feel), Wotnopoly (a new 3D property game, built from zero), and a full SEO/AEO overhaul with no pixels involved.
• The single biggest predictor of a useful run: whether the critic had something real to inspect. Measured numbers, period screenshots, official crawler docs. Adjectives get talked around; corpora don't.
• One round got rejected because Chrome's paint dropped half the screenshot. Evidence quality gates the loop the same way the critic gates the builder.

What is the Gauntlet Loop?

The Gauntlet Loop is a multi-agent prompting method named by Matt Shumer in late July 2026. A lead agent decomposes a goal into independently improvable pieces. Each piece gets a specialist builder sub-agent and a separate critic sub-agent. The critic starts with fresh context, never sees the builder's reasoning, and judges only the finished output against a real reference – unlabeled, in random order, forced to pick a winner. On a loss, the builder goes again. The loop runs until you stop it.

Shumer demonstrated the method with Claude of Duty, a 55,000-line Three.js first-person shooter built from a single prompt with no external assets, in the wake of the Claude Opus 5 launch. Decrypt covered it with the memorable framing that the "dumbest" prompt beat careful game design. It didn't. The prompt was short; the method behind it wasn't.

That gap is what this post is about. I researched the full method, rebuilt it as a working playbook, and ran it four times on WotAI Games – three browser games and one experiment that has nothing to do with graphics at all.

What the viral prompt leaves out

Shumer's own playbook page breaks the method into seven components:

1. Use an agentic harness. Claude Code or Codex – something with tool access, code execution, and sub-agents. Chat can't run this.
2. Define the goal, not the implementation. Say what you want. Let the model pick the architecture.
3. Establish a real bar. Concrete reference material the agent can open and inspect. This one is load-bearing.
4. Split into independently improvable pieces. The agent decomposes, not you.
5. Separate builder and critic. Different agents. The critic judges output, never reasoning.
6. Loop continuously. No artificial round caps.
7. Monitor transparently. A live status page showing candidate vs reference and each verdict.

Components 1 and 7 appear nowhere in the famous prompt text. That's exactly why reading only the prompt underdetermines the method – and why so many people who copied the prompt got expensive chaos instead of Claude of Duty.

The failure reports are worth taking seriously. Pieter Levels tried it and got "a total mess and chaos of unperformant code" and a $500 bill. Game developer Danny Limanseta made a sharper point: when a game arrives in one shot, you have no mental model of its systems, so every bug that surfaces afterward leaves you paralyzed.

Both failures share a shape. They ran the loop as a zero-to-one generator. The strongest evidence I found in the research says it's the wrong job for it: in a side-by-side comparison of two identical runs, one with reference photos on disk and one without, the run with references kept honestly failing rounds and grinding toward the target, while the run without produced a genuinely good website that missed the brand's actual design system entirely. Reviewing that comparison, : without a good minimum viable product to start from, the loop optimizes toward the wrong thing.

A high bar with no ground truth doesn't set a target. It amplifies the model's generic prior for "premium," at full token cost. The Gauntlet Loop is a polish amplifier, not a zero-to-one generator. Anchor first, amplify second.

So before running anything, I wrote a preflight with four checks:

• Reference material exists on disk, and the agent can open it.
• The starting point is already on-brief. The loop sharpens; it doesn't discover direction.
• The output is inspectable in its final medium – pixels, timings, or artifacts, not source code.
• The harness has a real budget. This takes hours, not minutes.

Then I picked four targets with those checks in mind. One note on tooling before the runs: I built the research playbook with Claude, started the first run in Claude Code – the same sub-agent machinery from the Claude Code 2.1.216 release – and handed the session off to Codex CLI mid-project to see how the method traveled. It traveled fine. Nothing below is harness-specific, which is Shumer's component 1 in practice: any agentic harness with sub-agents qualifies.

Run 1: Snake – the gauntlet without guesswork

WotAI Games had a Snake with real defects. An audit measured them: a two-second stall banked 19 movement cells and replayed them in a burst at 7 to 16 ms intervals. Hiding the tab for three seconds advanced the snake 21 cells into a wall it never saw. Resizing the window reset an active run to the start screen.

Timing bugs can't be judged from screenshots, so this run got a spec-led variant of the loop. The reference corpus came first:

• Google Snake, measured live. Standard mode is a fixed 17 x 15 grid. Opening cadence is 140 to 145 ms per cell. Rapid inputs 10 ms apart execute on successive cells, so the reference buffers at least two turns.
• The Nokia 6110 user guide, pages 50 and 51, as the authority for classic rules – growth, collision, pause, top score.
• Our own audit as the record of what was broken and what must not regress.

The corpus README includes a rule I'd now apply everywhere: do not infer timing, buffering, collision rules, or lifecycle behavior from still screenshots. Every claim needs a source that can actually establish it.

The critic held the builder to measured numbers. Post-loop, the opening cadence sits at 143 ms – inside the reference band. A long frame can no longer create a catch-up burst. Hidden-tab time is never replayed. Runs survive resizes.

Then came nine visual pieces – board fidelity, motion, presentation, HUD hierarchy, game-over, canvas rendering, pause, mobile touch controls, start screen – each ratcheted through blind A/B rounds against the reference captures. Verdicts were specific or they didn't count. The canvas round's control lost on "visible body seams." The game-over challenger won on a dominant final-score verdict and replay-first action.

My favorite moment in the whole project was a round that never happened. A challenger start screen reached the comparison stage, and the round was thrown out – not because the design lost, but because Chrome's paint intermittently omitted the left action panel from the capture while the accessibility tree claimed the card was complete. The evidence was bad, so the round was invalid, and the prior best stayed. The loop's honesty depends on gating evidence quality as strictly as output quality.

Run 2: Doodle Jump – a bar from 2009

Doodle Jump's bar couldn't be measured live, because the target was the original 2009 game. The corpus became an exercise in source criticism: period AppSpy gameplay footage from September 2009 for motion and camera, the June 2009 Macworld review for rules and feel, Lima Sky's own store listings for publisher-stated mechanics, and MobyGames' original 320 x 480 iPhone captures for layout and art. Each claim type got an authority ranking. Motion claims cite the period footage or stay marked unknown.

The baseline audit failed immediately on motion integrity: physics was tied to refresh rate. On a 120 Hz display, the game was literally a different game.

Five rounds later the loop converged. Round 1 fixed the simulation to 60 Hz; the blind critic verified identical game state at 60 and 120 Hz before passing it. Round 2 locked active-run coordinates through lifecycle interruptions. Round 3 was my favorite kind of round – an adversarial pass where the critic hunted for a counterexample and found none, so the control survived. Round 4 restored the hand-drawn graph-paper character of the original. Round 5 made the desktop engine coordinates scale into mobile viewports. Terminal gates: 70 of 70 unit tests, 2 of 2 focused Playwright runs, clean build.

Run 3: Wotnopoly – deliberately breaking my own rule

Wotnopoly is a new game – a 3D property strategy game in the Monopoly family, two to four hot-seat players plus deterministic AI rivals. Building it with the loop meant doing the exact thing the research warns against: running a polish amplifier from zero.

So I cheated on the "zero" part. Before any gauntlet round, the project got an architecture contract – a one-page ownership table stating that game rules live in pure logic, the Three.js scene owns rendering and nothing else, and screenshots for judging come from a seeded URL so every capture is comparable. It's the same discipline as a lean CLAUDE.md: give the agent the constraints that matter and nothing else. It got a visual bar document. It got procedural geometry only, no external art assets, same constraint as Claude of Duty.

The commit history tells you what the loop did anyway. The first build was a showy 3D board. The next three commits, in order: rebuild the classic square board, finish the readable fixed board, elevate the premium tabletop design. The blind critic dragged the game away from demo-impressive and toward readable-classic, then made it premium only after it was legible.

That's the zero-to-one lesson in miniature. The anchor documents did the directing; the loop did the sharpening. Without the contract and the bar doc, I'm confident I'd have gotten a beautiful board nobody could parse – the generic "premium" prior at full token cost.

Run 4: SEO and AEO – a gauntlet with no pixels

This is the run I was most curious about, because everything above judges pixels, and most work isn't pixels.

The question: does the loop survive when the "output" is crawl artifacts? The baseline said WotAI Games needed it either way. Public search returned zero indexed results for the domain. The home page's only H1 was the word "Games." Game pages had no H1 at all. FAQ structured data existed whose answers appeared nowhere on the visible page – which violates Google's structured-data policy, not just good taste. Two Open Graph images returned 404.

The reference bar had two halves. Three browser-game sites that actually rank stood in for the quality bar. Official crawler documentation stood in for the rules: Google's structured-data policies and AI-features guidance, Bing's recommendations for AI citation visibility, and OpenAI's crawl requirements for OAI-SearchBot.

The goal split into seven pieces – crawl and indexation, search intent, answer surface, internal discovery, entity graph, media, and regression safety – each with a gate a critic can verify from rendered HTML, robots.txt, the sitemap, and JSON-LD. Builders never graded themselves. A fresh critic confirmed each piece against the gates before it was retained, and the whole thing ran off the same live status page as the games.

It worked, and it shipped to production. The interesting part is why it worked: Shumer's "inspectable in its final medium" constraint never said the medium had to be visual. Rendered HTML is inspectable. Timings are inspectable. Crawl responses are inspectable. Any domain with a real reference and an inspectable artifact qualifies – which opens up far more than games. I'm running that theory against other project types now: brand assets, email templates, landing pages.

What actually decides whether the loop works

The four runs side by side:

Four runs in, the pattern is consistent:

1. The reference corpus is the whole ballgame. Measure, don't remember. Google Snake got measured live at 140 to 145 ms per cell; Doodle Jump got period sources with an authority ranking; SEO got official crawler docs. Every run's quality tracked the corpus quality, which matches the two-run comparison from the research exactly.
2. Evidence quality gates rounds. The rejected Snake round proved the loop needs a second gate: a verdict from bad evidence is worse than no verdict. If the capture pipeline can lie, the critic's blindness doesn't save you.
3. The ratchet does the compounding. Keep the best candidate; replace it only on a head-to-head win. Snake's start screen went through three rounds, and the one invalid round cost nothing because the prior best stayed. Without a ratchet, hours of iteration can drift sideways.
4. The critic stays blind, and you stay the brake. Unlabeled comparisons in random order, no access to the builder's reasoning, no round cap announced. Both game status pages carried the same line: the user is the brake. An uncapped loop is only safe because the status page makes it supervisable.
5. Cost scales with ambition, not with the method. The failure reports of burned budgets are real, and they're concentrated where people ran zero-to-one. On an existing product with an anchor, every one of my runs converged inside a day.

Try it on something that already exists

The minimal setup is smaller than it sounds:

• A refs/ folder per piece: screenshots, measurements, docs the agent can open.
• A one-page anchor if the target is new: what owns what, and where captures come from.
• A gauntlet-status.html the loop must keep updated: piece, round, candidate vs reference, last verdict with reasoning.
• A prompt that names the goal, the bar, the reference location, the blind-comparison rule, the ratchet, and the stop condition.

Pick a surface you already ship – a game, a page, a template – and give the critic something real to hold it against. Then go make coffee and watch the status page.

Snake, Doodle Jump, and the brand-new Wotnopoly are live at https://games.wotai.co – judge the four runs yourself. If you're doing this kind of agent work on a real product, the weekly notes go out at https://wotai.kit.com/ and the builds get discussed with 760+ builders at https://skool.com/wotai.

Frequently asked questions

What is the Gauntlet Loop?

The Gauntlet Loop is a multi-agent method where a lead agent splits a goal into independently improvable pieces, each piece gets a builder sub-agent and a separate blind critic, and the critic compares the candidate against a real reference until the candidate wins. It was named by Matt Shumer in July 2026.

Who created the Gauntlet Loop?

Matt Shumer named and popularized the Gauntlet Loop in late July 2026, after his Claude of Duty demo – a 55,000-line Three.js first-person shooter built from a single short prompt. The underlying builder-critic pattern predates the name, but Shumer's version specifies the blind comparison, the real bar, and the uncapped loop.

Do you need Claude Code to run a Gauntlet Loop?

No. You need an agentic harness with tool access, code execution, and sub-agents – Claude Code and Codex both qualify, and I've run the method in both. A chat interface can't run it, because the loop needs to execute code, capture output, and spawn fresh-context critics.

What is Claude of Duty?

Claude of Duty is Matt Shumer's demonstration project for the Gauntlet Loop: a browser-based first-person shooter of roughly 55,000 lines of Three.js, built from one short prompt with no external art assets. It went viral because the prompt looked trivially simple while the output didn't.

Why does the critic have to be blind?

A critic that can read the builder's reasoning gets argued into passing. The Gauntlet Loop gives the critic fresh context and only the finished outputs – candidate and reference, unlabeled, in random order – and forces a pick. In my Snake run, blind critics rejected challengers for specifics like visible body seams.

What is the ratchet in a Gauntlet Loop?

The ratchet is the rule that the best candidate so far is kept and only replaced when a new one beats it head-to-head. It converts an open-ended loop into monotonic progress. When one of my Snake rounds was invalidated by a bad screen capture, the ratchet meant the failed round cost nothing.

Does the Gauntlet Loop work for brand-new projects?

Poorly, on its own. With no reference and no starting point, the loop amplifies the model's generic idea of "premium" at full token cost – that's the shape of most reported failures. It works on new projects only when you anchor first: my Wotnopoly run used an architecture contract and a visual bar document before the first round.

How much does a Gauntlet Loop run cost?

Hours of agent time and heavy token volume – reported failures include a $500 run that produced unusable code. Cost concentrates where people run zero-to-one with no reference. Scoped to an existing surface with a real corpus, each of my four runs converged inside a day.

Can the Gauntlet Loop be used outside of games?

Yes. The method requires an inspectable output and a real reference, not graphics. My fourth run applied it to SEO and AEO: critics verified rendered HTML, robots.txt, sitemaps, and structured data against official Google, Bing, and OpenAI crawler documentation, across seven pieces, and the result shipped to production.

What goes in a Gauntlet Loop reference corpus?

Material the agent can open and inspect: measured behavior (Google Snake's 140 to 145 ms per cell cadence), period screenshots and footage, publisher documentation, official policy docs. The rule that matters most: never let the critic infer behavior from evidence that can't establish it – timing claims need timing sources, not still images.