An internal tool for the last mile. A build works, passes its tests, and still does not feel finished. Gauntlet Loop splits that finishing work into small independent pieces, gives each piece its own agent, and gives each agent its own critic.
The Problem
There is a technique going around for parallel agent work: break a goal into the smallest pieces, run one agent per piece, pair each with a critic that reviews the result, and loop until every critic is delighted.
The fan-out is a genuinely good idea. Everything around it is a way to lose a weekend.
“Loop until delighted” has no bound and no off switch. Critics given no standard optimise toward their own taste, which is not the taste the project was designed with. Agents writing to the same directory at the same time corrupt each other’s work. And nothing stops two of these running at once.
What It Does Instead
The fan-out survived. The rest was replaced.
Rounds are capped and gated. A run is one to five rounds, never more. Every round ends with a written report and stops dead until a human says continue. The loop never decides to keep going.
Critics judge against a brief, not a mood. The brief is assembled in a fixed priority order: the project’s own brand and token files first, then its documented bans, then its stated non-goals. A critic’s own design opinion ranks last and is explicitly advisory. When a general design rule conflicts with the project’s brand file, the brand file wins and the critic has to say so.
Writers are isolated. Each worker agent runs in its own git worktree, so parallel writers cannot race. Critics are read-only by construction and hold no write tools at all.
One run at a time. A run takes a lock shared with the vault’s other execution engine, so a polish pass and a queued job can never fan out over the same branch simultaneously.
The Part That Earned Its Keep
The first real run went against a live recipe app with 1,049 passing tests.
All three critics overturned their own worker.
One worker reported its assigned rule as already satisfied. Its critic checked the CSS cascade rather than the file’s text and found a real bug shipping to real users: a reduced-motion setting that never took effect, because a later rule quietly re-declared the value the accessibility rule had just set. Every test guarding it passed, because every test read the file as text and none of them resolved what the browser would actually compute.
Another worker fixed six genuine touch-target violations. Its critic worked out that the fix would push a book’s table of contents past a fixed-height container and silently clip about a third of its entries on tablets and desktops. A real fix, traded for a worse bug.
Without the critic layer, all of that ships as a clean pass.
What The Run Taught About Its Own Tooling
The visual critic reviews screenshots and never sees the code, so it cannot be talked into agreeing with the worker. It also cannot see which things on a page are actually clickable, and confidently failed a row of decorative badges that merely looked like buttons.
That produced the rule the tool now runs on: every criterion is assigned to the method that can actually observe it. Hit areas get measured in a browser. Contrast and visual polish go to the screenshot critic. Anything on a screen that needs data to appear gets read in the source, because a camera pointed at an empty app sees nothing worth judging.
The run also found three defects in the screenshot tool itself, including the worst kind: it accepted an HTTP 200 as proof a page existed. On a single-page app every URL returns 200, so a mistyped route rendered a completely different screen and the tool reported success. It now probes a deliberately impossible path, learns what the app shows for nothing, and fails anything that matches.
Honest Limits
A run is expensive: roughly 750,000 tokens and forty minutes for three pieces. It is triggered by hand, never scheduled, and it refuses to run at all on a project with no build or no written brief. It cannot start something. It can only finish it.