AI Loop Engineering in 2026: How to Build a Gauntlet Loop

What Is an AI Loop?

An AI loop is a repeating feedback cycle. The agent does not merely produce an answer and wait for you. It takes an action, examines what actually happened, compares the result with a target, changes its approach, and tries again.

For code, that may mean edit, run tests, read the failure, revise, and rerun. For a website, it may mean render, inspect screenshots at several screen sizes, compare them with reference sites, fix the largest visual gap, and render again. For a book, it could mean draft a chapter, check it against the outline and style examples, ask a fresh editor to find the weakest passage, revise, and continue.

The action-feedback pattern is not brand new. Research systems such as ReAct formalised cycles of reasoning and action years ago. What changed in 2026 is that mainstream agent tools made long-running goals, subagents, scheduled work, durable skills, and tool use much easier to combine. That pushed the conversation from writing a better individual prompt to designing the system that keeps prompting, checking, and continuing.

The Three Core Elements: Objective, Metric, Boundary

Use objective, metric, and boundary as the smallest useful design card for a loop. It is simple enough to remember and strict enough to expose vague thinking before an expensive run begins.

These three elements are the minimum, not the complete machinery. Serious loops also need tools, observable feedback, durable state, error recovery, permissions, and an escalation path. Without those, the loop may repeat, but it cannot reliably learn from the last attempt.

Prompt Engineering vs Loop Engineering

Prompt engineering asks, “What should I tell the model right now?” Loop engineering asks, “What system should decide what the model does next, how the result is checked, what it remembers, and when control returns to me?”

This is not the death of prompting. Every stage of a loop still needs clear instructions. The loop supplies the architecture; prompts tell the planner, builder, critic, and verifier how to perform their part.

What Is the Gauntlet Loop?

Matt Shumer calls his specialised builder-versus-critic pattern the Gauntlet Loop. He popularised it through the Claude of Duty experiment: one short orchestration prompt started a many-hour run that produced a technically ambitious browser-based first-person shooter in Three.js.

The pattern is simple:

1. Give a lead agent an ambitious goal and a concrete example of what great looks like.
2. Let it split the artifact into the smallest parts that can be improved and judged independently.
3. Assign each important part to a builder.
4. Give the actual output to a separate critic with fresh context.
5. Have that critic compare the output directly with the reference, ideally as a blind A/B test.
6. If your output loses, identify the largest meaningful gap and send it back for another round.
7. Repeat until the result reaches the bar, improvements stop being worth the cost, a boundary fires, or you stop the run.

The Original “Claude of Duty” Prompt

Shumer published the complete prompt with the project. Its strength is not architectural detail. It gives the agent a destination, an external quality bar, permission to decompose the work, independent critics, and permission to continue.

I want you to build a first-person shooter at the level of the most recent
Call of Duty games. It should be utterly perfect, visually beautiful, with
every single thing done at AAA quality—from textures to physics to anything
you could think of.

Fan out sub-agents and have sub-agents tackle each one individually so that
the game is utterly perfect. You should /loop on each item and have a separate
sub-agent check it visually to ensure it looks triple A. That separate
sub-agent should be a really harsh critic, and if it doesn't look triple A,
it should keep going.

Don't stop until each sub-agent is utterly wowed with the quality when compared
with the actual Call of Duty game. It should literally compare them side by
side blind and say which one looks better. Do this in ThreeJS. /loop until
it's utterly perfect. Fan out sub-agents and ultracode.

Why This Prompt Works

1. It specifies the destination, not the route

The agent is told what success should resemble, then allowed to choose the architecture and work breakdown. That leaves room for a capable model to discover systems the user may not know to request.

2. It uses a real, inspectable bar

“Make it amazing” is impossible to grade. Actual reference screenshots can be placed beside the rendered game. Code can use a test suite, performance budget, security checklist, or reference implementation. Writing can use an approved outline, fact sheet, and samples that demonstrate the desired clarity without asking the model to copy another author’s voice.

3. It decomposes the artifact

“Improve the whole game” is too large for useful feedback. “Compare these weapon hands with the reference and fix the largest anatomical gap” is small enough to attack repeatedly. Decomposition also makes genuinely independent work parallelisable.

4. The builder does not grade its own homework

A builder remembers every compromise and can explain why its choices are reasonable. A fresh critic receives the goal, rules, reference, and real artifact without the builder’s justifications. That separation reduces self-approval, although it does not make an AI judge infallible.

5. The critic inspects the artifact, not a summary

For visual work, inspect pixels. For software, run the product and tests. For research, open the sources and trace each claim. For prose, read the finished draft. A polished progress report is not evidence that the underlying work is good.

6. It does not impose an arbitrary final round

The loop continues while meaningful gaps remain. In production, pair that persistence with explicit time, token, money, permission, and diminishing-return boundaries. “Until perfect” is motivating language; it is not a safe stop condition by itself.

7. It can finish with an integration pass

When many builders improve separate pieces, local quality can rise while the complete artifact becomes inconsistent. A final fresh agent should inspect the whole result, resolve conflicts, and smooth the seams without redesigning everything.

Two Approaches, Kept Separate

The phrase “AI loop” is currently used for several related workflows. The clearest way to avoid confusion is to separate the immediate prompting pattern from the wider engineering discipline.

There is also a useful middle ground: a native persistent goal, where supported, keeps a completion condition alive across turns. A scheduled loop, where supported, runs a task on a cadence. Product commands change, so treat them as implementation shortcuts rather than the definition of loop engineering.

How to Run a Gauntlet Loop Without Building a Framework

Step 1: Use an actual agent

Do not paste the prompt into a normal chatbot and expect the full result. Use an agentic environment such as Claude Code or Codex that can inspect and edit files, run code or tests, render outputs, use tools, maintain project state, and create separate agents where supported.

Step 2: Supply the goal and the bar

Name the outcome and attach or link to references the critic can actually inspect. If you do not know the best benchmark, make finding a defensible benchmark part of the task.

Step 3: Declare boundaries before the run

State what the agent may change, what is forbidden, how long or how much it may spend, and which actions require your approval. For software, keep production deployment, destructive database changes, credentials, customer messages, and paid services behind explicit gates.

Step 4: Let the lead agent choose the decomposition

Ask it to divide the work into independently judgeable parts. Do not parallelise tightly coupled systems merely because more agents are available. The Claude of Duty repository notes that broad fan-out performed worse than sequential ownership for coupled visual systems.

Step 5: Require fresh-context criticism

The critic gets the specification, benchmark, and artifact—not the builder’s chain of decisions. It should name the largest remaining gap, provide evidence, and return a concrete correction target.

Step 6: Record progress and failed approaches

Keep a compact progress file or live workbench containing the current target, completed parts, failed approaches, evidence, next action, and remaining boundaries. Long chat histories rot; the project should remember even when an individual agent does not.

Step 7: Stop deliberately

Stop when the success criteria pass, improvement becomes too small to justify another round, the budget is exhausted, the same failure recurs without a new strategy, risk rises, or human judgment is required. Then run the integration pass and review the final artifact yourself.

Copy-Paste Gauntlet Loop Templates

Template 1: Minimal, transferable Gauntlet prompt

This keeps the spirit of Shumer’s original: a high bar, minimal prescription, agent-chosen decomposition, and independent critics.

I want you to create <DELIVERABLE> that achieves <OBJECTIVE> at the quality
level of <CONCRETE REFERENCE OR MEASURABLE BENCHMARK>.

Choose the approach. Break the work into the smallest important parts that can
be improved and judged independently. Fan out builders only where the work is
genuinely independent. Give every important part a separate, harsh critic with
fresh context.

Each critic must inspect the real output—not the builder's summary—and compare
it directly with the reference or metric, using a blind A/B comparison where
possible. If our result loses, identify the largest meaningful gap, return it
to the builder, and run another round.

Keep looping until the output meets <SUCCESS CONDITION>, improvements no longer
justify another round, or one of these boundaries fires: <TIME / COST / ATTEMPT /
PERMISSION / SAFETY BOUNDARIES>. Escalate blockers that require human judgment.

Finish with one fresh integration critic that checks the complete artifact for
consistency, correctness, and fit with the original objective.

For coding, use <PROGRAMMING LANGUAGE / FRAMEWORK>. Do not deploy, spend money,
use credentials, contact people, or make irreversible changes without explicit
approval.

Template 2: Objective, metric, boundary loop card

Use this version when reliability and cost matter more than dramatic language.

OBJECTIVE
<Write the exact outcome that should become true.>

INPUTS AND STATE
Use: <files, sources, tools, project, previous progress file>.
Record after every round: what changed, evidence, score, failed approach,
next action, and remaining budget.

METRIC / VERIFIER
Success requires all of the following:
- <objective test, benchmark, or factual check>
- <quality rubric or reference comparison>
- <integration, accessibility, safety, or editorial check>

PROCESS
1. Inspect the current state.
2. Choose the highest-impact unmet criterion.
3. Make one coherent improvement.
4. Run the real verifier.
5. If it fails, feed the evidence into a changed strategy and repeat.
6. If it passes, run a fresh independent final review.

BOUNDARIES
Allowed actions: <read, draft, edit, test, render>.
Forbidden without approval: <deploy, delete, purchase, publish, message, secrets>.
Stop and report when: success passes; <N> attempts finish; <TIME/COST> is
reached; the same blocker repeats; or uncertainty exceeds <THRESHOLD>.

Three Examples Beyond the Original Game

1. Write and edit a book

• Objective: Produce a complete 45,000-word practical guide that fulfils an approved chapter outline.
• Metric: Every claim traces to the supplied research; every chapter passes the outline, continuity, repetition, clarity, and target-reader rubrics; a fresh editor identifies no blocking issue.
• Boundary: Maximum five critic rounds per chapter, no invented sources, no copying the style of a living author, and human approval before the manuscript is called final.
• Gauntlet split: Research coverage, argument, chapter structure, examples, prose, fact-checking, and final continuity can have distinct reviewers.

2. Build a high-converting website

• Objective: Build a responsive product page that explains the offer and completes the existing signup journey.
• Metric: Compare screenshots with approved reference sites; pass accessibility and interaction checks; meet the performance budget; show no overflow at agreed viewports; keep all existing form behavior working.
• Boundary: Work locally, preserve analytics and legal copy, use the approved stack, do not deploy, and stop after the agreed budget or two rounds with no measurable gain.
• Gauntlet split: Information hierarchy, visual system, responsive behavior, copy, accessibility, performance, and end-to-end signup each receive the right kind of critic.

3. Complete a software feature

• Objective: Implement the scoped feature in <LANGUAGE / FRAMEWORK> without changing unrelated behavior.
• Metric: Acceptance tests, unit tests, lint, static analysis, security checks, and an independent review against the issue all pass.
• Boundary: No production changes, schema deletion, new paid dependency, or unrelated refactor; stop on missing requirements or exhausted time and report the evidence.
• Gauntlet split: Exploration, implementation, tests, security, usability, and final spec verification can be separated—but tightly coupled code should keep a coherent owner.

Where AI Loops Fail

• The goal is subjective. “Perfect” creates motion without a dependable finish line. Add inspectable evidence.
• The builder is the only judge. Self-critique tends to defend earlier decisions. Use a fresh verifier.
• The metric is gameable. Passing one narrow score may damage the real objective. Use several guardrails.
• There is no budget boundary. Unreachable bars can burn tokens, time, and tool costs indefinitely.
• The loop repeats instead of adapts. The same failed action with the same evidence is spinning, not learning.
• Context rots. Preserve compact state and prune stale history instead of carrying every token forward.
• Agents collide. Use isolated workspaces for independent changes and coherent ownership for coupled systems.
• Progress is self-reported. Require tests, screenshots, logs, diffs, citations, or another observable receipt.
• Permissions are too broad. Start read-only or reversible; gate deployment, deletion, spending, and communication.
• Humans surrender judgment. Autonomy increases the need for review, understanding, and accountability.

AI Loop Engineering Checklist

1. Write the outcome as a state that can become true.
2. Select evidence the agent can inspect directly.
3. Define success and failure separately.
4. Cap time, attempts, cost, permissions, and risk.
5. Give the loop the tools needed to observe real results.
6. Persist state outside the current conversation.
7. Separate builders from verifiers where the second opinion matters.
8. Parallelise only independent work.
9. Require a changed strategy after repeated failure.
10. Keep a human approval gate for consequential actions.