{"slug": "ai-loop-engineering-in-2026-how-to-build-a-gauntlet-loop", "title": "AI Loop Engineering in 2026: How to Build a Gauntlet Loop", "summary": "AI loop engineering, the practice of designing systems where AI agents act, observe, evaluate, and iterate until a success condition or boundary is met, has become a mainstream focus in 2026, according to a guide that outlines the three core elements of objective, metric, and boundary. The guide contrasts prompt engineering with loop engineering, noting that the latter involves a continuing process with multiple attempts, feedback from tests and tools, and durable state. It also highlights the Gauntlet Loop, a builder-versus-critic pattern popularized by Matt Shumer, as a specialized approach within this field.", "body_md": "## The Short Answer\n\n**AI loop engineering is the practice of designing a system in which an AI acts, observes the result, evaluates it against a defined standard, improves the work, and repeats until a success condition, safety boundary, budget, or escalation rule stops it.** You define the objective, metric, and boundary; the loop replaces your manual chain of follow-up prompts.\n\n## On this page\n\n## What Is an AI Loop?\n\nAn 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.\n\nFor 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.\n\nThe action-feedback pattern is not brand new. Research systems such as [ReAct](https://arxiv.org/abs/2210.03629) 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.\n\n## The Three Core Elements: Objective, Metric, Boundary\n\nUse **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.\n\n| Element | Question it answers | Weak version | Useful version |\n|---|---|---|---|\nObjective |\nWhat must become true? | “Make the site better.” | “Rebuild the pricing page so a first-time visitor can compare all plans and complete checkout on mobile.” |\nMetric |\nWhat evidence proves an attempt improved or passed? | “It looks professional.” | “No accessibility violations, no horizontal overflow at 360px, all checkout tests pass, and a fresh critic prefers our hierarchy to the approved reference.” |\nBoundary |\nWhat may it change, and when must it stop? | “Keep going until perfect.” | “Do not deploy or alter billing. Stop after four hours, £25 of model usage, three failed approaches, or any blocker requiring credentials.” |\n\nThese 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.\n\n## Prompt Engineering vs Loop Engineering\n\nPrompt 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?”*\n\n| Prompt engineering | Loop engineering | |\n|---|---|---|\n| Unit of work | One request and response. | A continuing process with multiple attempts. |\n| Who supplies the next step? | Usually the human. | The loop chooses the next action from evidence. |\n| Feedback | Often your written follow-up. | Tests, screenshots, benchmarks, tool results, critics, or approval gates. |\n| Memory | The current conversation. | Conversation plus files, logs, issue trackers, plans, or other durable state. |\n| Stopping | You stop prompting. | A success, failure, budget, safety, or escalation condition fires. |\n\nThis 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.\n\n## What Is the Gauntlet Loop?\n\n[ Matt Shumer](https://x.com/mattshumer_) calls his specialised builder-versus-critic pattern the\n\n**Gauntlet Loop**. He popularised it through the\n\n[Claude of Duty](https://github.com/mshumer/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.\n\nThe pattern is simple:\n\n- Give a lead agent an ambitious goal and a concrete example of what great looks like.\n- Let it split the artifact into the smallest parts that can be improved and judged independently.\n- Assign each important part to a builder.\n- Give the actual output to a separate critic with fresh context.\n- Have that critic compare the output directly with the reference, ideally as a blind A/B test.\n- If your output loses, identify the largest meaningful gap and send it back for another round.\n- Repeat until the result reaches the bar, improvements stop being worth the cost, a boundary fires, or you stop the run.\n\n### Credit and scope\n\nCredit Matt Shumer for the *Gauntlet Loop* name and this specific method. AI feedback loops and loop engineering are broader ideas with earlier research and practices behind them. The Gauntlet is one powerful pattern inside that larger field.\n\n## The Original “Claude of Duty” Prompt\n\nShumer 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.\n\n```\nI want you to build a first-person shooter at the level of the most recent\nCall of Duty games. It should be utterly perfect, visually beautiful, with\nevery single thing done at AAA quality—from textures to physics to anything\nyou could think of.\n\nFan out sub-agents and have sub-agents tackle each one individually so that\nthe game is utterly perfect. You should /loop on each item and have a separate\nsub-agent check it visually to ensure it looks triple A. That separate\nsub-agent should be a really harsh critic, and if it doesn't look triple A,\nit should keep going.\n\nDon't stop until each sub-agent is utterly wowed with the quality when compared\nwith the actual Call of Duty game. It should literally compare them side by\nside blind and say which one looks better. Do this in ThreeJS. /loop until\nit's utterly perfect. Fan out sub-agents and ultracode.\n```\n\n### The quality bar was a compass, not the final score\n\nThe prompt asked for Call of Duty quality, but the public project does not prove that a browser prototype reached AAA parity. Shumer’s own honest assessment says every blind comparison still preferred the real Call of Duty frame. The useful result is the process: the demanding reference kept a long-running agent improving instead of stopping at “good for AI.”\n\n## Why This Prompt Works\n\n### 1. It specifies the destination, not the route\n\nThe 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.\n\n### 2. It uses a real, inspectable bar\n\n“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.\n\n### 3. It decomposes the artifact\n\n“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.\n\n### 4. The builder does not grade its own homework\n\nA 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.\n\n### 5. The critic inspects the artifact, not a summary\n\nFor 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.\n\n### 6. It does not impose an arbitrary final round\n\nThe 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.\n\n### 7. It can finish with an integration pass\n\nWhen 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.\n\n## Two Approaches, Kept Separate\n\nThe 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.\n\n| Prompt-led Gauntlet Loop | Engineered recurring loop | |\n|---|---|---|\n| What it is | One orchestration prompt starts a split, build, criticise, and revise run. | A reusable operating system around one or more agents. |\n| Setup | No bespoke loop code if the harness already has tools, long-running goals, and subagents. | Usually needs triggers, state, connectors, permissions, verification, and recovery design. |\n| Best for | One ambitious, inspectable artifact: a game, site, design, chapter, report, or campaign. | Recurring work: issue triage, CI investigation, nightly tests, monitoring, migrations, and repeated reports. |\n| Quality signal | Fresh critics compare the real artifact with a concrete reference bar. | Automated tests, operational metrics, policies, logs, reviewers, and human approvals. |\n| State | May live mainly in the active project and run. | Must persist outside one conversation in files, databases, issue trackers, or queues. |\n| Stopping | The output wins, the user stops it, or a practical boundary fires. | Explicit success, failure, retry, budget, risk, and escalation rules. |\n\nThere 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.\n\n## How to Run a Gauntlet Loop Without Building a Framework\n\n### Step 1: Use an actual agent\n\nDo 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.\n\n### Step 2: Supply the goal and the bar\n\nName 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.\n\n### Step 3: Declare boundaries before the run\n\nState 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.\n\n### Step 4: Let the lead agent choose the decomposition\n\nAsk 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.\n\n### Step 5: Require fresh-context criticism\n\nThe 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.\n\n### Step 6: Record progress and failed approaches\n\nKeep 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.\n\n### Step 7: Stop deliberately\n\nStop 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.\n\n## Copy-Paste Gauntlet Loop Templates\n\n### Template 1: Minimal, transferable Gauntlet prompt\n\nThis keeps the spirit of Shumer’s original: a high bar, minimal prescription, agent-chosen decomposition, and independent critics.\n\n```\nI want you to create that achieves at the quality\nlevel of .\n\nChoose the approach. Break the work into the smallest important parts that can\nbe improved and judged independently. Fan out builders only where the work is\ngenuinely independent. Give every important part a separate, harsh critic with\nfresh context.\n\nEach critic must inspect the real output—not the builder's summary—and compare\nit directly with the reference or metric, using a blind A/B comparison where\npossible. If our result loses, identify the largest meaningful gap, return it\nto the builder, and run another round.\n\nKeep looping until the output meets , improvements no longer\njustify another round, or one of these boundaries fires: