Skip to content
Second Brain

Loop engineering: designing the loop around the model, not just the prompt

Loop engineering is the design discipline that turns a one-shot model into a system that checks its own work and iterates toward a correct result. As of 2026 it sits at the top of a progression — prompt engineering → context engineering → harness engineering → loop engineering — where each layer wraps the previous one. Prompt engineering tunes what you say; context engineering tunes what the model sees at each step; loop engineering tunes what happens between steps: how the agent observes results, verifies them, recovers from failure, and decides when to stop or escalate. The key mindset shift: two tools on the same model can differ wildly in quality purely from loop design, so you improve output by engineering the loop, not by prompting harder.

The canonical intuition is Kirupa’s dishwasher: Ralph scrubs each plate once and moves on; Lisa scrubs, inspects, re-scrubs until clean, and escalates the impossible cases. Same scrubbing skill, better process. Loop engineering is “restraint, self-awareness, and knowing when to escalate” — not raw intelligence.

The core cycle and the three stopping questions

Section titled “The core cycle and the three stopping questions”

Every loop runs Try → Check → Judge → Adjust: perform the work, observe the actual result, compare it against the goal, then modify the approach. Before building one, answer three questions (they define the loop’s boundaries):

  1. What counts as done? — testable success criteria.
  2. When does iteration stop? — an attempt cap / resource budget, so unsolvable problems don’t loop forever.
  3. When does a human step in? — recognizing stuck states and escalating.

The maturity ladder

Section titled “The maturity ladder”

LangChain’s framing of four levels is the useful mental model. Most setups live at Level 1; the 1→2 jump is where almost all the quality gain is.

Level Loop What it buys
1. Agent loop Model calls tools until done Basic autonomy
2. Verification loop Output scored against a rubric, retried with feedback on failure Consistency
3. Event-driven loop External triggers (cron, webhooks) run agents against real systems Agents as background infra
4. Hill-climbing loop Production traces feed an analysis agent that improves the harness config Self-improving setup

Best practices for the loops you already run

Section titled “Best practices for the loops you already run”
  • Verify with evidence, not assertions. The most common failure mode is the model declaring success without checking. Force it to show the test output, the command it ran and what came back, or a screenshot.
  • Use a fresh subagent as the grader. A second model that sees only the diff and the criteria — not the reasoning that produced the code — grades on its own terms and catches what the author rationalized away (adversarial review).
  • Protect context, because loops rot it. Recall degrades as the window fills (“context rot”). Counter with compaction (keep decisions + open issues, drop redundant tool output), external note-taking (a NOTES.md the agent maintains), and phase isolation via subagents (research → plan → implement → verify, each with clean context returning a ~1–2k-token summary).
  • Prefer deterministic checks over LLM judges. A linter, type-check, or passing test is a free, reliable grader. Reserve LLM grading for what code can’t check — tone, taste, “does this actually answer the question.”

Claude Code checklist

Section titled “Claude Code checklist”

A practical order of operations for raising your own loops from Level 1 to Level 2+:

  • CLAUDE.md: bake in verification. Add short, explicit loop rules — the verify command (e.g. Always run npm run build after editing content — it validates frontmatter), quality gates (Never consider a task done with a failing build), and what “complete” means. Keep it tight; long files get ignored.
  • Stop hook (highest impact). Before a turn ends, check tests/build pass; if not, inject the failures back and make Claude continue. This directly kills the “premature success” failure mode. Hooks are the only enforcement the harness guarantees — see [[2026-07-14-steering-claude-code]].
  • PostToolUse failure hook. Re-inject diagnostic context when a command fails so the model self-heals without a human. (This repo already runs a PostToolUse hook validating note frontmatter — extend that pattern from validating to gating.)
  • A /loop-style skill. Run task → verify → on failure analyze and fix → repeat up to N attempts. The attempt cap is the stop condition.
  • A /review skill. An adversarial self-review pass for edge cases, perf, and security before calling anything done — ideally run by a fresh subagent.
  • Embed verification in the prompt. Not “write the migration” but “write the migration, run it against dev, confirm the schema matches the model.” One habit turns a one-shot into a loop for free.
  • Allowlist safe repeated commands so the verify step doesn’t stall on approval prompts (the fewer-permission-prompts skill automates this).
  • Reach for subagents for high-volume grep/log work and the fresh-eyes review pass, keeping the main context clean.

Sources

Section titled “Sources”