Loop Engineering

Recent Updates

• 2026-07-26: Added elune's popularization thread to Sources (comprehensive beginner overview; no novel concepts beyond existing coverage).
• 2026-07-19: Added rari's popularization thread to Sources (comprehensive beginner overview; no novel concepts beyond existing coverage).
• 2026-07-19: Added Cherny's compound engineering pattern (CLAUDE.md as team correction file) to Memory, encoding rule to The Durable Asset, and plan-then-auto-accept to Open vs. Closed Loops.
• 2026-07-19: Added Perez's loops-to-graphs topology framework and anchors concept to The Four-Level Stack and What Loops Don't Solve.
• 2026-07-18: Added vision self-verification pattern to Verification, model routing for loop cost to Cost, Routines trigger taxonomy to Local vs. Cloud Scheduling, and classifier-block failure mode to Security.
• 2026-07-16: Added Warp's self-improving code review agent (Lloyd) to The Four-Level Stack and The Durable Asset Is the Skill.
• 2026-07-14: Added Anthropic free loop engineering course reference to Sources.
• 2026-07-07: Added Karpathy AutoResearch three-file architecture and Lutke results to A Loop Is a Generator Wired to a Verifier; added Bilevel Autoresearch meta-loop evidence to The Four-Level Stack.
• 2026-07-07: Added Claude Code team's four-primitive taxonomy to The Four Primitives and proactive composition pattern; added token-management guidance to Cost.
• 2026-07-05: Added loop-prompt-as-final-condition framing and starter template to The Build Order from AI Edge's beginner guide.

The Five-Stage Lineage

Boris Cherny, who created Claude Code as a side project in September 2024, gave the clearest definition: "I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops" source(https://www.youtube.com/watch?v=RkQQ7WEor7w). He describes three stages of progression: writing code by hand with autocomplete, running 5–10 parallel Claude sessions and prompting each one, then writing loops that prompt Claude while hundreds of agents read his GitHub, Slack, and Twitter and decide what to build next. He deleted his IDE in November 2025 and hasn't opened it since.

The concept has a real history, and conflating stages is what makes discourse around "loops" incoherent:

1. ReAct (2022) — The academic while-loop: reason, call a tool, read the result, repeat. One model, one loop, a human watching. Reflexion (2023) added the memory layer: when an attempt fails, the agent writes down why in plain language, stores the note outside the context window, and reads it on the next attempt. This is the academic seed of every persistent-memory pattern in production today — SKILL.md, agents.md, and cross-session lesson files all descend from it.
2. AutoGPT (2023) — Goal-driven self-prompting. Became famous for spinning forever doing nothing — seeding years of "agents are a toy."
3. Ralph loop (Huntley, Jul 2025) — A bash one-liner piping the same prompt file into the agent repeatedly, resetting context to fixed anchor files each iteration. Geoffrey Huntley built an entire programming language with it for $297. Ryan Carson's walkthrough of implementing Ralph in practice reveals the concrete workflow: write a PRD (often by voice-dictating into Whisper Flow and having the agent structure it), convert it into a JSON file of atomic user stories — each small enough to complete within a single context window — with verifiable acceptance criteria, then launch the bash script. The agent picks the first incomplete story, implements it, commits the change, marks the story as passed in the JSON, and logs what it learned before the next iteration starts fresh. Two memory layers make the loop durable: agents.md files (long-term, per-folder notes a new agent reads before touching code) and progress.txt (short-term, per-run log of which threads ran, what was implemented, and gotchas discovered — so later iterations can read earlier ones). Carson ran a 14-iteration session that shipped a full feature overnight for roughly $30 total ($3/iteration on Opus 4.5). The critical investment is upstream: spending an hour getting the PRD right and ensuring each user story is small, atomic, and has clear acceptance criteria — without that, ten iterations produce ten mediocre results.
4. /goal (spring 2026) — Productized ralph: both Codex and Claude Code ship a command that runs the loop until a small validator model confirms the task is done. A strong /goal reads less like a prompt and more like a contract specifying four things: the end state you want, the evidence that proves you reached it, the constraints the agent must not break getting there, and the budget of work it is allowed to spend. Leave any one vague, and the model fills the gap with the easiest reading — stopping early, taking a shortcut, or redefining success so the transcript looks done while the real system is broken.
5. Orchestration loops (2026) — The genuinely new layer. Loops supervise other loops concurrently and on a schedule. Scheduling replaces human kickoff. Durability becomes explicit — git-backed state and crash recovery — because these loops must survive a restart. Ralph assumed your terminal stayed open; the 2026 version assumes it doesn't.

The Four-Level Stack

Orthogonal to the historical lineage, Sydney Runkle (LangChain) frames loop engineering as four concentric loops, each wrapping the one inside it: (1) the agent loop — a model calling tools until a task is complete, the innermost primitive; (2) the verification loop — a grader (deterministic or agentic) that checks the agent's output against a rubric and sends feedback back for another pass when it falls short; (3) the event-driven loop — triggers (webhooks, cron, incoming messages) that invoke the agent automatically so it runs as a background component, not something you call manually; (4) the hill-climbing loop — an analysis agent that reads traces from prior runs, detects patterns of failure or inefficiency, and rewrites the harness (prompts, tool configs, grader criteria) so the next cycle is better than the last. The key structural insight: the return arrow of the outermost loop reaches inside the inner loops and modifies them — each cycle of the hill-climbing loop makes the agent, verification, and event layers more effective. This four-level taxonomy names the same concepts scattered across the rest of this page — the agent loop is the core primitive, verification maps to the maker/checker split, the event-driven layer maps to automations, and hill climbing is the self-improving agent pattern reframed as the outermost loop. Human oversight slots in at every level: requiring approval before sensitive tool calls (level 1), using a human as the grader (level 2), gating published output on sign-off (level 3), and reviewing proposed harness changes before deployment (level 4).

The Bilevel Autoresearch paper (2026) provides the sharpest empirical evidence for level four. Researchers took Karpathy's AutoResearch loop and wrapped a second loop around it: the inner loop proposes changes, trains, and evaluates as before; the outer loop watches the inner loop's traces, identifies where the search process is stuck, and generates new code that changes how the inner loop searches. On Karpathy's GPT pretraining benchmark, the bilevel architecture produced a 5× improvement over the single loop (-0.045 vs -0.009 val bpb). The gain came not from a smarter model — both loops used the same LLM — but from breaking the inner loop's search-pattern ruts. The LLM kept returning to the same optimization priors even when they stopped working; the outer loop forced exploration in directions the model's instincts avoided source(https://arxiv.org/abs/2603.23420).

Zach Lloyd (Warp) provides the production counterpart. His "cloud software factory" series builds a code review agent whose quality improves automatically over time. The inner loop is event-driven (level 3): a GitHub action triggers on PR state changes, gathers PR description, diff, and specs, then launches a cloud agent with a review skill that outputs structured review.json — which the action converts to inline GitHub comments. The outer loop is hill-climbing (level 4): once a day, a second agent reviews all PRs the reviewer touched, reads the human feedback threads (corrections, validations, style preferences), and opens a PR to update the review skill itself — so the next run of the inner loop incorporates what humans taught it. The skill deliberately ships without repo-specific coding conventions; the outer loop learns those conventions from human interaction over time rather than requiring them up front. Two design choices reinforce the pattern: the review agent runs with read-only PR permissions (the action posts comments programmatically, closing a prompt injection vector), and the outer agent's skill updates go through a PR rather than auto-merging — human approval at level 4 of the autonomy ladder source(https://x.com/zachlloydtweets).

Carlos E. Perez generalizes the multi-loop insight into an explicit topology framework. A single loop has four structural failure modes, each answered by a specific graph relationship: Goodhart's law (the metric detaches from the reality it stood in for — the support bot optimizes ticket resolution rate by deflecting customers) is answered by pairing — every optimizing loop gets a watching loop on a counter-metric that catches the cheap win; blindness upward (nothing inside a loop can question whether its reference is right) is answered by hierarchy — a slower loop owns the faster loop's target, and revising targets is itself a governed cycle; conflict (independently built loops fight — the speed loop undermines the thoroughness loop) is answered by arbitration — a loop above the fighting loops owns the trade-off; and measurement decay (sensors drift, data pipelines rot, the loop runs on numbers that no longer touch the world) is answered by audit loops whose only function is to check, periodically, that the other loops' measurements still correspond to reality. The four-level stack embodies these fixes: Runkle's verification loop is pairing, the hill-climbing loop is hierarchy (it revises the inner loops' parameters), and the held-out evaluation set in ML ops — a deliberately blinded loop the training loop never sees — is an audit loop. Perez's deeper claim: the unit of design is no longer the cycle but the network of cycles, and the skill shifting from "build one clean loop" to loop architecture — knowing that a metric must never travel alone, that references need owners, that speeds must be separated so fast loops cannot thrash what slow loops steward.

The Engineering Stack

Complementary to Runkle's concentric-loop taxonomy, HuaShu's IEEE paper frames the same territory as four layers of engineering concern, each minding a larger unit:

1. Prompt engineering — what to tell the model: wording, examples, role, tone. Boundary is one exchange.
2. Context engineering — what goes in the window so the model can crack the problem. Minds the model's entire field of view — what to retrieve, how to summarize, what stale information to clear.
3. Harness engineering — which tools, which actions, when to load context, how to recover from failure, what state counts as done. Arms one run.
4. Loop engineering — make it run itself, over and over. The loop wraps the harness: the harness below arms a single agent run; the loop above makes it run itself repeatedly.

Each layer up, the unit of concern grows one size: from one sentence, to one window, to one run, to a loop that runs itself. The change from layer three to four is one of identity — from the person who operates the agent to the person who schedules it. Value moves from "knowing how to direct" to "knowing how to build a loop that can say no." A single error at the prompt layer is caught within one exchange; at the harness layer it affects one run but the diff is visible; at the loop layer the same misreading is written into state, read back as established fact, and built upon across many turns. By the time anyone looks, the wrong assumption is load-bearing. This is the single most important intuition in loop engineering: every turn is a chance for an unnoticed mistake to entrench itself, and a loop is, by construction, a machine for maximizing the number of turns.

The Four Primitives

The Claude Code team's own taxonomy cuts the space by what triggers the loop and what stops it, mapping each type to a concrete CLI primitive:

1. Turn-based — triggered by a user prompt, stopped when the agent judges the task complete. This is the agentic loop: every prompt starts one. Best for shorter, non-recurring tasks. The lever for improving it is encoding your manual verification steps as a SKILL.md so the agent can check its own work end-to-end — the more quantitative the checks, the easier self-verification becomes.
2. Goal-based (/goal) — triggered by a manual prompt, stopped when a separate evaluator model confirms the goal is met or a turn cap is reached. Best for tasks with verifiable exit criteria. This is the productized ralph loop: the agent doesn't decide when it's done — an independent judge does. Deterministic criteria (test count, score threshold) are the most effective because they remove ambiguity about what "good enough" means.
3. Time-based (/loop, /schedule) — triggered on a time interval, stopped when cancelled or the work completes. Best for recurring work or interfacing with external systems. /loop runs locally (stops when the machine sleeps); /schedule moves the loop to the cloud for true autonomy. This maps directly to the local vs. cloud scheduling axis.
4. Proactive — triggered by an event or schedule with no human in real time, stopped when each task's goal is met (the routine itself runs until turned off). This is the orchestration loop tier: composing /schedule for the trigger, /goal for the exit criteria, skills for verification, dynamic workflows for multi-agent orchestration, and auto mode for unattended execution. Best for recurring streams of well-defined work — bug triage, issue handling, dependency upgrades, migrations.

The taxonomy maps cleanly onto the four-level stack: turn-based is the agent loop (level 1), goal-based adds verification (level 2), time-based adds the event-driven layer (level 3), and proactive composes all three with hill-climbing potential (level 4). The practical advice from the Claude Code team echoes the page's recurring theme: not all tasks require complex loops — start with the simplest primitive and escalate only when the simpler one falls short source(https://x.com/claudedevs/status/2074208949205881033/?rw_tt_thread=True).

The Cron Distinction

The sharpest skeptic line — "Cronjobs have funny re-branding rn" — deserves a straight answer. The scheduling layer is cron; Boris literally runs his on cron. What cron never had is the decision-maker in the body: a model that looks at current state, decides what to do, does it, checks whether it worked, and decides whether to keep going. The decision is the agent's, not a hardcoded branch. Stack those, let one loop dispatch and supervise others, give them durable shared state, and you have something cron cannot express. Loops are cron plus a decision-maker in the body, and the interesting engineering is everything you wrap around that decision so it doesn't run off a cliff.

The Orchestration Engine

Dan Farrelly (Inngest) reframes the agent loop as three explicit architectural layers: the loop (a cron plus a decision-maker — the scheduling heartbeat with an LLM in the decision seat), the skill (a durable workflow — multi-step, retryable, composable, independently deployable), and the orchestrator (the engine underneath that schedules crons, executes steps, manages retries, enforces concurrency limits, stores run history, and hot-deploys new functions without disrupting running ones). Most people think of agents as "LLM + tools"; the three-layer model reframes them as "loops + skills + orchestration," with LLMs and tools as swappable components inside the loops. The orchestrator is the layer nobody talks about because it's supposed to be invisible — but it's foundational. A while True in a terminal doesn't give you crash recovery, step-level checkpointing, or concurrency control. Neither does a long-running process on a VM. When a loop restarts without checkpointing, it re-fetches data it already had, re-calls the LLM for decisions it already made, sends duplicate notifications, and spawns duplicate sub-agents. The fix isn't better error handling — it's an execution model where each step is checkpointed, each decision is persisted, and recovery means resuming from the last successful step. Durable orchestration also provides step-level retries for transient errors (a metrics API timeout retries just that step, not the whole skill) and failure-handling hooks for non-recoverable errors (post to an ops channel, preserve the event, let the next scheduled run pick up). Step-level checkpointing is a cost feature as much as a correctness feature: without it, a transient error forces the entire skill to re-execute, burning LLM tokens on decisions already made — multiply that across 10–30 agents and the waste is significant source(https://x.com/djfarrelly/status/2067677007140278630/?rw_tt_thread=True).

Open vs. Closed Loops

The sharpest practical distinction in loop design is between open and closed loops. An open loop gives the agent a goal and lets it explore freely — choosing paths, discovering things, building beyond the spec. This is what senior engineers at OpenAI and Anthropic run with unlimited API access, and it burns tokens at rates that make normal budgets irrelevant (a fleet loop with orchestrator and specialists can consume 500K–2M tokens per run). A closed loop bounds the agent inside a human-designed path: clear goal, defined steps, an evaluation gate at each stage, and an explicit stop condition. The agent still loops — but inside a framework you built, and each pass feeds the next. For most real work, closed loops are the ones that pay off. The practical advice: start closed, build a tight system that works reliably, then open it up once quality gates are proven. Cherny's personal workflow is the minimal closed loop: iterate on a plan in Plan mode (no code yet) until it matches what's in his head, then flip to auto-accept and let the agent one-shot the implementation. "The reason one-shots fail for most people is bandwidth. You described a complex feature in a few words, so Claude built a different feature than the one in your head. Planning is how you raise the bandwidth before a single line is written" source(https://x.com/sunaborern/status/1945139236681904131). The "magic one-shot" is just a good plan cashing out — the closed loop is the planning conversation, and the open execution that follows is safe because the plan already bounded it.

Context Hygiene

Long loops rot from the inside. As turns accumulate, old tool outputs, dead-end reasoning, and stale intermediate results pile into the context window — a process called context rot. Model performance degrades as this noise grows, and in a loop the degradation compounds: a rotted context produces a worse decision, which adds more noise, which rots the context further. This spiral is the doom loop — the agent gets measurably dumber the longer it runs. The instinct is to keep everything in context just in case; the skill is knowing what to throw away. Three techniques form the standard defense:

• Compaction. Summarize the conversation when it gets long, then continue from the summary. The agent trades fidelity on old details for headroom on new decisions.
• Offloading. Push large tool outputs (build logs, API responses, search results) to a file and keep only the relevant slice in context.
• Sub-agents. Hand a messy subtask to a separate agent running in its own context window. Only the clean result returns to the parent loop. This is the same maker/checker split applied to context isolation — the parent never ingests the noise the child waded through.

Context hygiene is a prerequisite for the longer loops described in the autonomy ladder — a loop that can't manage its own context window won't survive long enough to reach level three or four.

The Planner-Generator-Evaluator Harness

Anthropic's applied AI team (Ash Prabaker and Andrew Wilson) builds long-running agents around three separated roles, each in its own context window: a planner that decomposes a one-line prompt into high-level sprints (deliberately not granular technical specs — a planning error at that level cascades through every sprint), a generator that builds code, and an evaluator that uses Playwright to actually open the live app, click around, test interactions, and score against a weighted rubric. The pattern is GAN-inspired: the generator produces, the evaluator grades, and adversarial pressure between them drives quality. If you squint, it's a PM–IC–QA org chart where each role gets its own context window.

The key mechanism that distinguishes this from a simple maker/checker split is contract negotiation. Before the generator writes a single line, the two agents negotiate what "done" means by passing markdown files on disk back and forth. The generator proposes: "I'll build X and you should verify by testing Y." The evaluator pushes back: "Scope is too big, those tests are too weak, you've missed edge case Z." They iterate until both agree. The generator then builds against the contract, and the evaluator grades against it — not the planner's original spec. This converts vague user stories into tangible, testable assertions without the planner having to over-specify upfront. It's the innovation the Ralph loop never had: Ralph had a fixed plan.md, but nobody on the other side argued with it.

Three implementation details matter:

• The evaluator must not see the generator's reasoning. Anthropic tried giving the evaluator the generator's traces and found it performed worse — the evaluator starts agreeing with the reasoning that produced the output instead of judging the output on its own terms. Let the evaluator say "this is broken"; let the generator figure out why from its own reflection.
• Design taste is gradable. The evaluator uses a rubric with four weighted criteria — design, originality, craft, functionality — calibrated with few-shot examples on reference sites. With Opus 4.6 already strong on functionality, the weights shift toward design and originality to suppress AI-slop aesthetics (purple gradients, generic layouts). The lesson: if you have a strong opinion on what good looks like, write it down as a rubric — "subjective" becomes tractable once the opinion is explicit.
• The model will throw everything away. With adversarial pressure from a separate evaluator, the generator willingly discards ten passes of work and restarts from scratch when it can't hill-climb against the rubric. This never happens in single-agent loops, where the generator is too proud of its own work to delete it. The evaluator sometimes gets fed up and tells the generator to just scrap the whole approach — a behavior Anthropic's team recognized as mirroring what human engineers do when they benefit from a fresh start.

Contract granularity drives critique quality. For a retro game maker demo, the agents negotiated 27 contract criteria. Vague criteria produce vague critiques and the generator shrugs; granular criteria tell it exactly which line to fix.

Concrete payoff. In that retro game-maker demo (~$200, ~6 hours, 5–15 rounds), the solo loop produced a working sprite editor but a broken play mode — arrow keys did nothing, because the agent had no way to test whether the game was actually playable. The PGE run shipped working physics, collision detection, arrow-key movement, and a live debug HUD that existed only because the evaluator needed it to test gameplay. Same prompt, same model; the adversarial split was the whole difference.

Greenfield vs. brownfield. PGE is primarily a greenfield technique — it shines building a new app from a one-line prompt. For brownfield work on an existing codebase, pair it with a different outer loop: autonomous monitoring → issue generation → agent PR → human review. The rubric-based evaluator still applies but needs per-project customization.

Trace Reading as the Primary Debugging Loop

The harness team's primary method for improving their system is not running more experiments — it's reading agent traces line by line, finding where the model's judgment diverged from human judgment, and tuning the prompt for that specific divergence. "It was the same kind of muscle as reading a stack trace." They pipe transcripts to files, sometimes point another agent at a batch of traces to surface issues, but the irreducible work is a human sitting with the traces and empathizing with what the model was trying to do. This is how they discovered, for example, that the QA agent was finding bugs and then marking them "fix later, might take two weeks" instead of failing the sprint — a sycophancy pattern invisible from the outside.

A complementary technique from the Claude for Chrome team: agent empathy — close your eyes, open them every ten seconds to glimpse a static page, then close them again and try to navigate. Putting yourself in the model's perceptual position reveals why it makes the choices it does; it is the same muscle as reading traces by hand.

Harness Co-Evolution

The agent harness doesn't disappear as models improve — it co-evolves. Anthropic tracks this with a "meter chart": minimal-scaffold task completion at 50% went from ~1 hour (Opus 3.7) to 12 hours (Opus 4.6) in one year. But the interesting pattern is what changes in the harness at each model generation:

• Context resetting — critical for Opus 4.5 (which had context anxiety near window limits) — was dropped entirely for Opus 4.6, which runs coherently in a single continuous session with compaction.
• Sprint decomposition — required for Opus 4.5, which needed to be force-fed one feature at a time — became optional for Opus 4.6, which can hold a 2-hour continuous build coherently.
• Evaluator cadence — shifted from running per-sprint to running once at the end of a full generation pass, because Opus 4.6 produces coherent enough output that per-sprint checking adds cost without proportional quality gain.

The lesson isn't that the harness was wrong — it was right for 4.5. The frontier moved, and the team ran a simplified version to see if it still needed the complexity. Some components get absorbed into the model; others evolve; new gaps appear. Every model release is a signal to re-evaluate which harness components earn their keep.

Model capability timeline for long-running agents (minimal scaffold, 50% task completion):

The Four-Box Test — When a Loop Is Worth Building

A loop earns its setup cost only when all four conditions hold: (1) the task repeats at least weekly — less than that and the overhead never pays back; (2) something can automatically reject bad output — a test, a type check, a build, a linter; (3) the agent can do the work end-to-end without handing half of it back to you; (4) "done" is objective, not a judgment call. Miss one box, keep it as a manual prompt. The honest version: most people don't need the heavy loop yet — the light version (a single prompt with built-in self-check criteria) covers the common case.

Two additional tactical criteria sharpen the test for a specific task: the loop must have a hard stop (token budget, iteration count, or time limit — without one, it runs until someone notices the bill), and a human must review before anything irreversible (merge, deploy, dependency changes). The four conditions decide whether to build a loop at all; these two decide whether it's safe to run one.

Concrete examples help calibrate. Good first loops are tasks where the work repeats, the gate is mechanical, and the blast radius is small: CI failure triage (nightly scan, classify causes, draft fix PRs for the easy ones), dependency bump PRs (weekly scan, test compatibility, open PRs), lint-and-fix passes (on every PR open event), flaky test reproduction (loop until a theory survives the test), and issue-to-PR drafts on codebases with strong test suites. Bad first loops are anything where "done" requires judgment: architecture rewrites, auth or payments code, production deploys, vague product work. If a junior engineer couldn't do the task from a checklist, a loop shouldn't be doing it unsupervised.

The Build Order — Prove, Harden, Automate

The practitioners who ship loops that survive in production all follow the same sequence: first prove the task works by running it manually (one good prompt, verified by hand), then harden it (add the verifier gate, the stop condition, the state file), then automate it (schedule, trigger, run unattended). Skipping ahead — scheduling something you haven't made reliable by hand — is exactly how loops blow up while you sleep.

The mental shift at the "prove" stage: a loop prompt is not an instruction, it's a final condition — you're telling the agent when to stop, not what to do. A practical starter template: /loop [verifiable end state], only touching [scope], stop after [N] iterations, use [skills], use verifier agents for [checkpoint], and keep a memory file of all your work. Three elements make or break the prompt: a verifiable end state, a scope constraint (which files, which folders, which tasks), and a stop rule (iteration cap or token budget).

The Autonomy Ladder

Orthogonal to open/closed, every loop sits on a four-level autonomy scale: (1) suggest only — the loop surfaces findings but a human acts on them; (2) draft — the loop produces changes for a human to apply; (3) apply with approval — the loop executes low-risk changes but gates publish or merge on human sign-off; (4) fully automatic with audit logs. Start every new loop at level one or two. Run it for a week, read its output, correct what it gets wrong. Once the loop consistently produces work you would approve without changes, promote it to level three. Level four is earned, not assumed. A useful heuristic for triage: runs that find something go to an inbox; runs that find nothing archive themselves silently — you should never have to open a loop's output to confirm that nothing happened.

The mechanism that makes levels two through four practical in production is a notification channel — Slack, iMessage, or any generic messaging path where the loop can post status updates and "I need a decision" prompts. Zakariasson treats it as a one-way notification channel, not full Slack access: the agent pings when it finishes or blocks, the human's reply becomes the next input to the loop. This turns babysitting into interrupt-driven review. With the notification channel in place, running multiple concurrent loops becomes manageable — Zakariasson typically runs three to five long loops plus shorter one-off agents, self-regulating with a simple heuristic: if three loops are waiting on him, he stops starting new ones and goes to review. The cloud is the other enabler — loops run on remote infrastructure rather than a laptop, so a multi-hour hill climb survives the machine closing source(https://x.com/ericzakariasson/status/2070493377267646797).

Single-Agent vs. Fleet

Loops operate at two scales. A single-agent loop runs the full discover–plan–execute–verify–iterate cycle in one model — one brain, self-improving, suited to focused tasks with limited scope. A fleet loop hands the goal to an orchestrator that decomposes it into pieces, dispatches each to a specialist agent, and those specialists may delegate further to sub-agents. Every agent in the tree runs the same five-stage cycle. The orchestrator owns the mission; specialists own the steps; sub-agents do the narrow work; eval gates between them prevent slop from propagating. This maps directly to the orchestration patterns — the fleet loop is orchestration with a recurring feedback cycle wrapped around it.

Five Building Blocks

A single turn of a loop makes five moves: discovery (figure out what this turn should do), handoff (isolate and dispatch the work to an agent), verification (check whether the result is right), persistence (land the result somewhere that survives the conversation), and scheduling (close the cycle — decide the next step and ensure the loop turns again). Drop any one move and the loop either won't turn or will turn in place. These five moves are realized by six parts — and the failures of a loop are simply those moves skipped:

1. Automations — Scheduled triggers that discover and triage work (cron jobs, CI hooks, /loop, /goal). The heartbeat that makes a loop a loop rather than a one-shot run.
2. Worktrees — Isolated git checkouts so parallel agents don't collide on the same files. Same principle as branch-per-engineer, enforced at the filesystem level.
3. Skills — Codified project knowledge (conventions, build steps, "we don't do it like this because of that one incident") that prevents the agent from re-deriving your entire project from zero every cycle. Without skills, loops accumulate intent debt — the agent fills every hole in your intent with a confident guess.
4. Plugins and connectors — MCP-based integrations that let the loop act inside your actual environment (issue trackers, staging APIs, Slack) rather than just proposing what it would do.
5. Sub-agents — The maker/checker split. The model that wrote the code is too agreeable grading its own homework; a second agent with different instructions catches what the first talked itself into. This is also how /goal works under the hood — a fresh model decides if the loop is done instead of the one that did the work.
6. Memory — Anything that lives outside the conversation and holds what's done and what's next. The agent forgets everything between runs; memory must land on disk. Memory is not context: context is what the agent sees this round and is flushed afterward; memory is what lets it pick up today where it left off yesterday.

The moves map to parts: discovery runs on skills, handoff on worktrees, verification on sub-agents, persistence on memory, scheduling on automations. Connectors (plugins) decide the loop's radius of vision — what the loop can see and act on in the outside world. With all six in place a loop has a skeleton: automation makes it move, worktrees keep it from fighting itself, skills keep it from redoing work, connectors let it see outside, sub-agents let it correct itself, and memory lets it remember.

Tool Design for Loops

A loop is only as good as the tools inside it, and tool design for loops has different priorities than tool design for single-shot agents. Three principles emerge:

• Keep the set small and non-overlapping. Pile on a hundred tools and the agent loses track of which one to reach for. Anthropic's rule of thumb: if a human engineer can't say with certainty which tool fits a given situation, the agent has no chance either.
• Make writes idempotent. Loops retry — by design (verification failures) and by accident (crashes, timeouts). If a retried "create customer" call produces a second customer, you wake up to duplicate records and double billing. Anything that changes state must be safe to call twice with the same arguments.
• Write error messages for the agent, not the human. In a loop, an error isn't a dead end — it's the next instruction. A good error tells the agent what to do next. Before shipping a tool, ask whether an LLM reading its error output would know the correct next move.

Memory

Memory Is the Spine

A markdown file, a Linear board, anything that lives outside the conversation and holds what's done and what's next. The agent forgets everything between runs, so state must live on disk. This is the same persistence pattern used by every long-running agent architecture. Anthropic's harness team prefers JSON files for persistent state over markdown — models are less likely to overwrite JSON than markdown, and the timestamped breadcrumb pattern (what was tried, what was evaluated, what was found, what was fixed) gives the next agent or human enough context to pick up where the last run stopped.

Compound Engineering

The most production-tested form of cross-session memory is not a vector database — it's a plain text file checked into git that every agent reads at startup and the whole team writes to. Boris Cherny's team maintains a shared CLAUDE.md (~2,500 tokens, deliberately lean) holding style conventions, design guidelines, PR templates, and landmines. The compounding mechanism: anytime the agent does something wrong, the correction goes into the file so it never happens again. Cherny's sharpest move is integrating this into code review — when a reviewer spots an anti-pattern in a PR, they tag the agent on the PR through a GitHub Action and have it write the lesson straight into CLAUDE.md as part of that same PR. The fix and the rule ship together. This is compound engineering: the codebase gets more intelligent with every merge, not through fine-tuning or RAG but through a flat file that accumulates the team's negative knowledge — the growing list of things that should never happen again source(https://x.com/sunaborern/status/1945139236681904131).

The pattern maps directly to Martin's five-stage memory progression: the team collectively fails (discovers a mistake), investigates (reviews the PR), distills (writes the rule), and consults (every future session reads it). The difference from individual memory is that the distillation happens at code-review time by a human, and the consultation is enforced structurally — the agent cannot start a session without reading the file. This sidesteps the verification gap that plagues automated memory: a human decides what becomes a rule.

Memory as an Outer Loop

Within-run persistence keeps a single loop on track; cross-session memory is an outer loop that lets the agent compound learning across runs. Martin tested Fable 5, Opus 4.7, and Sonnet 4.6 on Continual Learning Bench 1.0 (sequential questions against a SQL database, each question in a separate agent session with shared memory). Effective memory use follows a five-stage progression: fail (get something wrong and document it), investigate (figure out why before moving on), verify (turn the diagnosis into a checked fact), distill (turn verification into a general rule), and consult (read the rule instead of re-deriving it). Sonnet 4.6 exits around stage 1 — a list of failure notes and open guesses, rarely consulted. Opus 4.7 reaches stage 3 — schema references with uncertainty flagged but low verification coverage (~17% median). Fable 5 tends to complete the full progression, with verification coverage up to 73% and distilled rules that transfer to future tasks. The practical implication: less capable models need task-specific memory instructions to progress beyond note-taking, while stronger models can self-organize the fail-investigate-verify-distill-consult cycle with minimal scaffolding.

The Session-Mining Loop

The personal variant of the hill-climbing loop doesn't optimize a harness — it optimizes the practitioner. Cathryn's self-improvement loop reads your own Claude Code and Codex sessions as ops data and asks two questions: What should I create from this? and What should I fix so tomorrow is easier? The inner loop is the work you already do in the terminal; the outer loop watches those runs after the fact, not to redo the work but to extract what it revealed about your setup and habits.

The key contribution is a taxonomy of seven targets for each lesson the outer loop discovers:

1. Content idea — a workflow, shortcut, or judgment call another person would ask you to explain. The terminal is full of accidental curriculum invisible to you until someone watches over your shoulder.
2. Context file — a path, convention, or correction you told the agent twice; it should be written down once in CLAUDE.md or AGENTS.md.
3. Slash command — a multi-step instruction you typed from scratch; that's a command you don't have yet.
4. Skill — a skill that needs updating, or one that should exist because you keep doing the same thing by hand. Patch existing skills before minting new ones.
5. Hook — something that should happen automatically every time instead of depending on memory. Hooks never have a bad Tuesday.
6. Tool or CLI — a tool that stumbled: awkward syntax, unclear errors, missing flags, forcing three commands where one would do. A tool fix is permanent; a prompt workaround is not.
7. Config — a permission you keep approving by hand, an environment variable, a default that's wrong for how you work.

The design rule is strict: the scan stages proposals, the human approves. The loop stores evidence (not transcript dumps), detects real tool use (not mentions), separates durable lessons from one-off incidents, and requires approval before anything changes. Cathryn calls this controlled compounding — the system makes you slightly better at your own work tomorrow because of what happened today, without the agent quietly rewriting your setup. On its first production run, the loop found signals in 37 sessions and staged 7 proposals: one CLI fix, four skill reviews, one memory update, and one backlog item.

This sits at level one on the autonomy ladder — suggest only, human acts — and maps to level four of Runkle's four-level stack (the hill-climbing loop) but with the human as the final actuator rather than an automated rewrite. Schedule the scan, never the changes.

Production Patterns

Greyling's reference repo catalogs six named production patterns, each with a recommended cadence, starter kit, and token-cost profile:

The "week-1 level" column is the key operational insight: every pattern starts at L1 (report-only) or L2 (assisted), never L3 (unattended). This enforces the same prove-then-harden-then-automate discipline described above, but with a concrete promotion path per pattern rather than a general principle. A pattern picker decision guide helps teams choose which loop to build first — the recommendation is to start with a low-cost, high-cadence L1 pattern (Daily Triage or Changelog Drafter) before attempting the high-token-burn patterns like CI Sweeper.

Two CLI tools support the workflow: loop-audit scores a project's loop readiness against a checklist (scaffolding, state management, verification gates, stop conditions) and loop-init generates starter kits for a chosen pattern and tool (Grok, Claude Code, or Codex). The audit produces a score that climbs from empty → L1 → L2 as the developer adds the missing pieces — turning the abstract four-box test into a concrete, gradeable rubric.

A Concrete Loop Shape

An automation runs every morning, calling a triage skill that reads yesterday's CI failures, open issues, and recent commits, then writes findings to a state file. For each actionable finding, the system opens an isolated worktree, sends a sub-agent to draft the fix, and a second sub-agent reviews against project skills and tests. Connectors open the PR and update the ticket. Anything the loop can't handle lands in a triage inbox. The state file remembers what got tried, what passed, and what's still open — so tomorrow's run picks up where today stopped.

Loops in Production

Stripe: Enterprise-Scale Loop Architecture

Stripe's agent pipeline merges more than 1,300 pull requests per week, not one line written by a human. The trigger is light — @ the bot in Slack, or an automated event — but before the model wakes up, a deterministic orchestrator prepares all context. The core architectural principle: everything rule-bound is kept out of the probabilistic model. Letting the LLM find its own context is the least controllable part, so Stripe draws a sharp line between what is deterministic and what goes to a probabilistic model — where you draw that line decides the loop's reliability. The system is a fork of the open-source tool Goose, and its core claim is that reliability comes from the quality of the constraints, not the size of the model. Its architecture interleaves deterministic gates and creative LLM steps: if the linter runs and the agent cannot skip it, the agent fixes the lint rather than arguing about it. Environments run on EC2 on a "cattle not pets" basis — each environment is swapped out at will, so a thousand-plus agents run at once without stepping on each other. Notably, those 1,300 PRs are still human-reviewed — the loop executes but a human approves before merge.

Local vs. Cloud Scheduling

The choice between local and cloud scheduling is not a matter of taste; it follows from one question: is the loop's work glued to the local machine, or can it leave? Two concrete cases illustrate. A loop should watch a local dev server and rerun when it detects UI regressions — that must run locally, because the cloud cannot see a process on one's laptop. A loop should scan the repository's open issues at three in the morning — that must run in the cloud, because laptops get their lids closed, lose power, and get carried out the door. Local scheduling means "run a few extra rounds while I am here"; cloud scheduling means "run even when I am not." These are different capabilities — local buys tighter iteration while the machine is on, while cloud buys true autonomy at the cost of a more constrained environment. A mature loop often uses both: local for the tight feedback cycle, cloud for the overnight run.

Routines — saved Claude Code configurations (prompt, repos, connectors, permissions) running on cloud infrastructure — provide three trigger types, each mapping to a self-improvement pattern: schedule triggers for the morning-briefing pattern (daily at 7am: re-run yesterday's eval suite, distill new failure modes into skills, post the digest), API triggers for the fire-on-event pattern (CI fails → fire a routine to investigate; Sentry alert → fire a routine to triage), and GitHub event triggers for the learn-from-real-work pattern (on PR open, evaluate against latest skills; on merge, write new patterns the PR introduced back to the skill — keeping repository state and skill state in sync). The third trigger type is the mechanism that makes the hill-climbing loop practical in production: the system learns from real work as it happens, not on a fixed schedule source(https://x.com/0xcodez/status/2065089060104720776/?rw_tt_thread=True).

Tool Convergence

The five building blocks now ship inside both Claude Code and Codex — different names, same capabilities. Once you recognize the shared shape, you stop arguing about which tool and design loops that work regardless of which one you're sitting in.

Cost — The Loop Is Now the Expensive Part

Once the model writes code for almost nothing, cost migrates to the loop that runs it. Uber capped engineers at $1,500/person/tool/month for Claude Code and Cursor after burning its annual AI budget in four months source(https://x.com/mattvanhorn). The failure mode everyone in production fears is the loop that doesn't stop — without guardrails, infinite loops produce billing surprises orders of magnitude over budget. Every serious 2026 implementation converges on three hard stops: a maximum iteration count, no-progress detection, and a token or dollar budget ceiling. The metric that actually matters — and almost nobody tracks — is cost per accepted change, not tokens spent or loops run. If the loop gives you ten results and you toss six, you're doing the review work it was meant to save. Below a 50% accept rate, a loop costs more than it gives back.

The economics are not universal. The people calling loop engineering obvious tend to have unmetered tokens; the people for whom it's reckless are usually on a consumer plan trying to run heavy verification loops without hitting limits. Teams with repetitive, machine-checkable work and the budget to run it benefit first — continuous test triage, dependency bumps, lint-and-fix passes on codebases with strong test coverage. Solo builders on consumer plans, anyone working on code with no automated verification, and teams whose real bottleneck is review capacity rather than typing speed should skip it until the economics shift. For one-off tasks, exploratory work, or anything where "done" is a judgment call, a single well-aimed prompt still wins.

The cost-effective routing pattern converging across production teams: reserve the most capable model (Fable 5) for the orchestrator role — planning across days, delegating, checking work with vision, distilling rules — and route everything else down-tier. Hard-but-bounded subtasks (architecture decisions, complex debugging, deep code reviews) go to Opus 4.8. High-volume worker tasks (lint passes, simple refactors, test scaffolding, doc updates) go to Sonnet 4.6. Grader sub-agents and cheap classifiers go to Haiku 4.5, which gets an independent context window at the lowest cost — ideal for the verifier role. The pattern is: orchestrator on the top tier, workers on the mid tier, graders on the cheapest tier. Not every step in a self-improving system needs the most expensive model; routing by task complexity rather than defaulting to the top is what makes multi-day loops economically viable source(https://x.com/0xcodez/status/2065089060104720776/?rw_tt_thread=True).

The Claude Code team's practical token-management playbook adds five levers: (1) choose the right primitive and model for the job — smaller tasks don't need multiple agents or loops, and some tasks can use cheaper, faster models; (2) define clear success and stop criteria so the agent converges sooner; (3) pilot before a large run — dynamic workflows can spawn hundreds of agents, so gauge usage on a smaller slice first; (4) use scripts for deterministic work — running a script is cheaper than reasoning through the steps each time; (5) match the polling interval to how often the monitored system actually changes — don't run a routine every five minutes for something that changes once a day source(https://x.com/claudedevs/status/2074208949205881033/?rw_tt_thread=True).

The Durable Asset Is the Skill, Not the Loop

The loop is plumbing. A loop with no reusable skills inside it is a while-true around a stranger; a loop that calls a library of sharp, tested, named skills is a system that compounds. Steinberger's complementary point: if you do something more than once, turn it into an automated skill; if you do something hard, turn it into a skill afterward so next time is free. This aligns with the thin harness / fat skills pattern — the loop provides the rhythm, the skills provide the leverage. In practice, this yields explicit skill-chaining pipelines where each loop iteration invokes a named stage: planning skill → PRD skill → research skill → build skill → review skill → test skill. The loop's job is sequencing and gating between stages; all domain knowledge lives inside the skills themselves. Lloyd's self-improving code reviewer makes this concrete: the review skill ships generic (security, correctness, style) and deliberately omits team-specific conventions — those are learned by the outer loop and written back into the skill file via PR. The skill is the durable artifact that accumulates team knowledge across runs; the loop and the outer loop are just the machinery that feeds it.

Cherny's encoding rule operationalizes this at the individual level: "anytime you do a task, build the thing that will do it for you next time. Intent compounds. Prompting does not." In practice this means slash commands for every inner-loop task (his workhorse /commit-push-pr uses inline bash to precompute git status so the model skips a round trip), sub-agents to protect context (a Code Simplifier that cleans up after generation, a Verify App agent with end-to-end testing instructions — each returns just the result, keeping noise out of the main session), PostToolUse hooks for deterministic formatting (the hook auto-formats every edit so nothing trivial breaks CI), and permission allowlists over danger flags (/permissions checked into .claude/settings.json, shared with the team — everyone agrees on safe defaults once instead of each person typing --dangerously-skip-permissions). The first time something is done manually is research; the second time is a skill waiting to be encoded source(https://x.com/sunaborern/status/1945139236681904131).

Verification

Verification Is the Essential Feedback

A loop is only as trustworthy as its ability to check its own work. An open loop that writes code with no feedback is a machine for generating confident mistakes; a loop that writes, runs, reads the result, and corrects is the thing that actually works. The maker/checker split operationalizes this: the model that wrote the code is too agreeable grading its own homework, so a second agent with different instructions catches what the first talked itself into. Lance Martin (Anthropic) adds a specific mechanism: verifier sub-agents outperform self-critique because grading happens in an independent context window — the grader never saw the reasoning that produced the output, so it can't be talked into agreeing with it. Outcomes in Claude Managed Agents implements this by spawning a separate grader sub-agent automatically source(https://x.com/RLanceMartin/status/2072674851995906113). Anthropic's applied AI team takes this further: tuning a standalone critic to be harsh is tractable, but tuning a builder to be self-critical is not — the asymmetry is the same reason it's easy to critique a meal but hard to cook one. Self-evaluation is a trap; adversarial evaluation is the pattern that works (see Planner-Generator-Evaluator).

In practice, verification targets fall into a small number of categories, each with a natural gate. Eric Zakariasson's taxonomy: (1) model or eval work — target is a score; change the approach, run the eval, keep the change only if the number moved the right way; (2) web app or UI — target is a QA pass via Playwright or screenshot; (3) backend or refactor — target is the test suite, failing first then green; (4) speed or flakiness — target is a number (p95, a benchmark) that must stay under a threshold; (5) data or content cleanup — target is a count that must reach zero failed rows. The common thread: writing the loop is mostly writing how you'd check the work yourself. Zakariasson's heuristic for prompt specificity echoes the closed-loop advice above — start more explicit than you think you need, then loosen once you see what the model can infer source(https://x.com/ericzakariasson/status/2070493377267646797).

Model Quality Changes Loop Behavior

On Parameter Golf (an ML engineering challenge: best model in 16 MB, trained in under 10 minutes on 8×H100s), Fable 5 improved the training pipeline roughly 6× more than Opus 4.7 when both ran the same self-correction loop via CMA Outcomes. The divergence was structural, not incremental: Fable bet on architecture changes and showed resilience pushing through regressions to reach its biggest wins, while Opus 4.7's first experiment produced a small gain and nearly everything after followed the same template — adjust a scalar, measure, keep if positive. The implication for loop design: the same loop shape produces qualitatively different behavior depending on the model inside it. A loop built around conservative, scalar hill-climbing may work fine with one model class but leave an order of magnitude of performance on the table with a more capable one.

Vision Self-Verification

For visual output — UI, dashboards, charts — text-only verification misses the failure mode that matters. The pattern in production: the maker sub-agent writes code and renders the result to a screenshot; a verifier sub-agent reads the screenshot with vision, compares it against the goal description, design tokens in the project skill, and the previous screenshot from the state file; the verdict feeds back into the loop. Match marks the task complete; mismatch produces a structured diff handed back to the maker. This is the same maker/checker split applied to a modality the checker can actually see — and the same independence principle (the verifier never saw the maker's reasoning). Anthropic measured this in Parameter Golf: Fable 5 read training charts visually and decided whether the curve met the criterion, with no human in the loop reading the chart source(https://x.com/0xcodez/status/2065089060104720776/?rw_tt_thread=True).

"A Loop Is a Generator Wired to a Verifier"

Karpathy's AutoResearch (March 2026, 66K+ GitHub stars within a month) distills the generator-verifier architecture to three files: train.py (the only file the agent may touch), prepare.py (the evaluator the agent cannot touch — if it could, it would make the test easier instead of the model better), and program.md (the constraints). The agent proposes a change, trains for five minutes, checks whether the score improved, commits if it did, rolls back if it didn't, and repeats. Pointed at a model Karpathy had hand-tuned over two decades, the loop ran 700 experiments in two days and found 20 improvements he missed — including a missing scalar multiplier in the attention mechanism that made attention too diffuse across heads. Shopify CEO Tobi Lutke ran it overnight on an internal model and woke up to a 19% quality improvement in a model half the size of his previous one — the agent optimized for hardware instead of defaulting to "bigger is better." The locked evaluator is the structural guarantee: the loop cannot redefine success, only pursue it.

Samuel McDonnell's distillation cuts through the naming confusion: the generator was never the bottleneck — the verifier is. Output quality is capped by the quality of the verifier you gave the loop, not one point higher. A loop that goes green is not a loop that is correct; it is a loop that satisfied whatever check you wrote. The Bun-to-Rust port (Jarred Sumner, Jun 2026) demonstrated this at scale: ~750,000 lines of Rust, 99.8% of the existing test suite passing, built in under two weeks by hundreds of parallel agents. The architecture was layered verification — one pass mapped correct Rust lifetimes for every struct field, a second wrote behaviour-identical ports with two reviewer agents per file, a separate layer of agents existed only to refute what the others produced, then a fix loop drove the build and test suite until both ran clean. Verification was not a step at the end; it was the architecture. And then the caveat Anthropic wrote into its own announcement: the port is not yet in production. A 99.8% pass on an existing suite is a benchmark result — it reproduces the behaviour the old tests already described. Production is the behaviour nobody wrote a test for yet source(https://x.com/samuelmcdonnell). The practical corollary: instrument the gate before you scale the loop — without measurement, you are generating wrong answers faster.

Business Loops — Revenue Engineering

The same loop architecture applies beyond engineering. Eric Siu frames "revenue engineering" as pointing loops at the parts of a business that generate money — sales, content, recruiting, ops — using the same structural discipline. The business-oriented anatomy maps five parts: (1) a trigger — a signal that work needs to happen (a deal goes quiet for fourteen days, a lead fills out a form); (2) signal and context — the loop pulls account history, CRM state, recent interactions before acting, so the agent doesn't act blind; (3) the action — the agent drafts the output (a revival email, an outreach sequence), meaningful only because it sits inside the other four parts; (4) an eval gate — a definition of what good looks like, checked by a human or automated verifier before anything ships; (5) a stop condition — shipped, approved, or killed after N days with no reply. Missing any one part produces a broken loop. This five-part anatomy is the business equivalent of the technical building blocks above — trigger maps to automations, context maps to plugins/connectors, action to the agent call, eval gate to the maker/checker split, and stop condition to budget ceilings and no-progress detection.

The practical corollary is the broken loop audit: most teams already have proto-loops scattered across Slack threads and half-finished agent conversations — a trigger with no action behind it, an action with no eval gate, a thread with no kill criteria. Each is a workflow leaking time. The audit asks: which workflows eat the most time? Where does work sit idle? Who decides if the output is good enough? When does it stop? Does the next run improve from the last? Any workflow that can't answer those questions is a broken loop worth fixing before building new ones.

Failure Modes and Anti-Patterns

HuaShu maps five structural anti-patterns one-to-one onto the five moves of a single turn — each anti-pattern is one move skipped:

1. Self-approval loop (no verification) — the agent writes code and the same agent declares it good. The symptom is a loop that has never once said "no" to itself across hundreds of turns — a statistical impossibility for any real workload.
2. Amnesia loop (no persistence) — the loop discovers work, does it, then forgets it happened because the result lived only in a context window that was flushed. Each morning it starts from zero.
3. Show-once loop (no scheduling) — it works impressively the day it is built and silently stops contributing because it is a script the human runs by hand and then forgets to run. The last successful run was the day it was demoed.
4. Manual discovery (no discovery skill) — the human still hand-picks "fix these three bugs," so the loop has automated the doing but not the finding. Choosing what to work on is often the expensive part.
5. Collision mess (no worktrees) — parallel agents change the same working directory, so edits collide and the merge is untangleable. The problem appears only the first morning five agents run at once.

In practice these cluster: the hasty loop installs the two moves that produce visible output (handoff and scheduling) and skips the three that produce safety (verification, persistence, discovery).

Greyling's repo catalogs failure modes as an incident-style catalog and anti-patterns as design mistakes caught before production — a useful complement to the conceptual risks in What Loops Don't Solve. Three categories emerge: multi-loop coordination failures (when loops collide — two loops editing the same file, a CI sweeper and a dependency sweeper racing to fix the same build, or a triage loop spawning work that a cleanup loop deletes), operational failures (cost overruns from unmonitored loops, logging that either says too much or too little, and the question of when to kill a loop that's technically still running but no longer producing value), and design anti-patterns (skipping the L1 report phase and going straight to L3 unattended, building a loop for a task that doesn't repeat, or letting a loop auto-install community skills without auditing them — the last of which connects directly to the security concerns above). The operational guidance converges on a single principle: the loop must be cheaper to run than the human time it replaces, measured not per-token but per-accepted-change — the same metric flagged in Cost.

What Loops Don't Solve

Four costs accrue silently while a loop runs, none of which sounds an alarm:

1. Verification debt — the loop generates faster than the human reviews, so the saved time turns into unverified output. The problem hides where tests do not cover, accumulating until it blows up at once.
2. Comprehension rot — the more the loop writes, the bigger the gap between what exists and what the human understands. The codebase grows while the human's mental model falls behind.
3. Cognitive surrender — accepting agent output because forming an independent opinion costs attention you no longer have. The more reliable the loop, the easier it is to outsource judgment entirely.
4. Cost surprise — a loop that runs overnight may spawn helpers and retry freely, producing an unfamiliar bill rather than fixed code. The guard is hard caps set before shipping: per-run budget, daily budget, emergency stop.

These four form a reinforcing cycle: without an independent evaluator, verification debt accumulates; because the human merged twenty PRs without reading them, their mental model now lags by twenty changes (comprehension rot); because the loop ran so smoothly, the human stops reading the next morning's batch entirely (cognitive surrender); and because the loop spawned helpers and retried freely all night, the bill is triple what was budgeted (cost surprise). The result is a loop that generates mistakes, guarded by a human who has stopped looking, discovered only when one surfaces as a production incident.

HuaShu's central thesis: a loop is a faithful multiplier — the same loop, built by two people, yields opposite outcomes separated by one or two human checkpoints. Bring judgment and the loop amplifies judgment; bring laziness and it amplifies laziness. Three disciplines counter the erosion: sample regularly (read a representative sample of output every day — it need not be large, it needs to be regular and genuinely examined), cap budgets before shipping (per-run, daily, and emergency stop — a loop without caps has delegated its spending authority to the model), and keep the human checkpoint permanent (not a temporary scaffold to be removed once the loop is trusted — it is the permanent feature that keeps the loop trustworthy, and the day it is removed is the day comprehension rot begins in earnest).

Perez identifies a failure mode specific to the graph itself: even a well-structured network of loops can be circular — every loop watches another loop, every audit checks one report against another report, and no loop touches the ground. The graph is internally consistent and externally detached, and it will fail exactly as the single loop failed, only later and more expensively. The fix is anchors: some measurements must be the kind that cannot be argued with (revenue that landed in the bank, tests that actually executed, customers who actually stayed), some rules must be frozen — rules the optimizing loops are never allowed to tune, precisely because they are the rules the optimizer would weaken (this is why Karpathy's prepare.py is locked), and the root judgment of what "better" means must come from outside the graph entirely, supplied by people through contact with real failures. The durable axis is not loops versus graphs but grounded versus ungrounded — whether the improvement machinery, however shaped, keeps touching the reality it claims to improve.

These risks compound with the orchestration tax: the same review bottleneck that limits parallel agents also limits how much loop output you can meaningfully absorb. Gartner puts agentic AI at the peak of inflated expectations, with only ~17% of organizations actually deploying agents — the gap between the timeline discourse and production receipts remains wide.

Security — The Unattended Attack Surface

A loop running unattended is also an attack surface running unattended. Four threat vectors compound with autonomy:

• Generated code shipping unreviewed. The loop opens PRs faster than a human can read them. Without a gate that includes security checks (SAST, dependency audit, secret scanning), insecure code merges automatically.

• Skills as injection vectors. A loop that auto-installs community skills inherits every prompt injection hiding in their descriptions. Audit skill sources before installing — of 17,022 audited skills, 520 leaked credentials.

• Credentials in logs. Debug logging during a long-running loop scatters secrets across logs nobody monitors. Disable verbose logging in production loops; sanitize what does get logged.

• Permission scope creep. A loop tested with read-only permissions gets "just one" write permission added for convenience, then never re-audited. Re-audit permissions every 30 days.

• Classifier blocks as silent regressions. Models with built-in safety classifiers (Fable 5 declines in cybersecurity, biology, chemistry, and distillation domains) silently fall back to a less capable model or refuse entirely. In a loop running unattended, a classifier block looks identical to a real error — until you debug it. The design principle: treat the safety boundary as a known fallback, not a failure mode. Skills should document which task types may trigger the classifier, and the loop should route those tasks to an explicit fallback model rather than discovering the block at runtime source(https://x.com/0xcodez/status/2065089060104720776/?rw_tt_thread=True).

The security tax scales with the autonomy ladder — a level-one loop that only suggests is a low-risk surface; a level-four loop that merges and deploys without human sign-off is a high-risk one. Every promotion up the ladder should trigger a security review, not just a reliability review.

See Also

• Agentic Engineering — parent topic; harness design, self-improving agents, multi-agent orchestration
• Agent Harness — the harness layer a single agent runs inside; loop sits one level above
• Claude Code Skill Frameworks — the skill ecosystem that loops compose from

Sources

• "WTF Is a Loop? Peter Steinberger vs. Boris Cherny" — Matt Van Horn (Jun 2026) — Boris Cherny's definition of loops, five-stage lineage (ReAct → AutoGPT → ralph → /goal → orchestration), cron-vs-loop distinction, loop cost dynamics (Uber $1,500 cap), three hard stops (iterations/progress/budget), skills-over-loops thesis, verification as essential feedback
• "Loops: What Every AI Engineer Needs to Know in 2026" — Rahul (@sairahul1, Jun 2026) — open vs closed loop taxonomy, single-agent vs fleet loop scales, token cost as the key accessibility barrier to loop engineering
• "Loop Engineering" — Addy Osmani (tweet thread, Jun 2026) — five building blocks of agent loops (automations, worktrees, skills, plugins, sub-agents), memory as persistent spine, maker/checker split, tool convergence across Claude Code and Codex, loop risks (verification, comprehension debt, cognitive surrender)
• "The Art of Loop Engineering" — Sydney Runkle / LangChain (tweet thread, Jun 2026) (link) — four-level loop stack taxonomy (agent → verification → event-driven → hill climbing), grader-as-rubric verification pattern, hill-climbing loop that rewrites inner-loop config from traces, human oversight insertion points at each level
• "The Agent Loop Architecture" — Dan Farrelly / Inngest (tweet thread, Jun 2026) (link) — three-layer architecture (loop/skill/orchestrator), durable orchestration as infrastructure layer, step-level checkpointing for crash recovery and cost savings, orchestration-aware self-extension (agents authoring and deploying their own durable skills via sidecar), concurrency controls, observability as trust layer
• "Designing loops with Fable 5" — Lance Martin / Anthropic (tweet thread, Jun 2026) (link) — self-correction loops via /goal and Outcomes, verifier sub-agent > self-critique (independent context window), Parameter Golf benchmark (Fable 5 ~6× over Opus 4.7, structural vs scalar experimentation), cross-session memory as outer loop, five-stage memory progression (fail → investigate → verify → distill → consult), Continual Learning Bench 1.0 results across Fable/Opus/Sonnet
• "My Thoughts on Loop Engineering" — Samuel McDonnell (tweet, Jun 2026) — "generator wired to a verifier" framing, Reflexion as persistent-memory precursor, Bun-to-Rust port as verification-as-architecture case study (750K lines, 99.8% test pass, not yet production), inner/outer loop distinction, "design the verifier, not the prompt"
• "Revenue Engineering: How to turn AI loops into revenue" — Eric Siu (tweet thread, Jun 2026) (link) — five-part business loop anatomy (trigger/context/action/eval/stop), applying loop patterns to sales/content/recruiting/ops, broken loop audit framework
• "From Prompting Agents to Loop Engineering" — Elvis / DAIR.AI (tweet thread, Jun 2026) (link) — practitioner synthesis: /goal-as-contract framing (end state, evidence, constraints, budget), six-part loop anatomy (trigger, isolation, written-down context, tool reach, second-agent check, state on disk), crabfleet orchestration tool, PR babysitter as concrete loop shape
• "Loops explained: Claude, GPT, Mira and what actually works" — Anatoli Kopadze (tweet thread, Jun 2026) (link) — beginner-accessible loop explainer: four-box test for when loops are worth building, cost-per-accepted-change as key metric, prove-then-harden-then-automate build order
• "How to Create Loops with Claude" — MIKE (tweet, Jun 2026) — popularized loop-design guide synthesizing Cherny, Osmani, and Huntley; introduces four-level autonomy ladder (suggest → draft → apply-with-approval → fully automatic), silent-archiving heuristic for no-op runs
• "Loop Engineering Clearly Explained" — Akshay Pachaar (tweet thread, Jun 2026) (link) — beginner-accessible explainer: context rot and doom loop terminology, tool design principles for loops (idempotent writes, agent-readable errors, small non-overlapping toolsets), four-level progression (prompt → context → harness → loop), stopping conditions taxonomy, maker/checker split framing
• "Build Agents That Run for Hours" — Ash Prabaker & Andrew Wilson / Anthropic, AI Engineer Conference (video, Jun 2026) — Planner-generator-evaluator harness pattern (GAN-inspired adversarial roles), contract negotiation between generator and evaluator before building, evaluator must not see generator reasoning, design taste as weighted rubric (design/originality/craft/functionality), harness co-evolution with model generations (what changed Opus 4.5 → 4.6), trace reading as primary debugging loop, file-system-as-state over context windows, model willingness to discard under adversarial pressure
• ""Ralph Wiggum" AI Agent will 10x Claude Code/Amp" — Greg Isenberg ft. Ryan Carson (video, Jun 2026) — Ralph loop practitioner walkthrough: PRD-to-JSON pipeline, atomic user stories with acceptance criteria, dual memory (agents.md long-term + progress.txt short-term), fresh context per iteration, $3/iteration cost, 14-iteration feature build
• "Hey Siri, meet AI" — Ben Tossell / Ben's Bites (Jun 2026) (link) — practitioner framing of skills-composition pipelines as loop design pattern (planning → PRD → research → build → review → test)
• "Your first AI loop should be for yourself (template included)" — Cathryn (tweet thread, Jun 2026) (link) — personal session-mining loop pattern: inner loop (the work) + outer loop (reviewing sessions as ops data), seven improvement targets (content idea, context file, slash command, skill, hook, tool/CLI, config), controlled compounding over autonomy, open-source template (agent-improvement-loop)
• "Human in the /loop" — Eric Zakariasson (tweet thread, Jun 2026) (link) — practitioner loop setup: five verification-target categories by task type (score, QA pass, test suite, benchmark, count), notification channel as human-in-the-loop mechanism (Slack pings, reply-as-next-input), cloud execution for multi-hour loops, concurrent loop self-regulation heuristic (stop starting when three are waiting on review), explicitness gradient for prompt tuning
• "Loop engineering: the 14-step roadmap from prompter to loop designer" — Codez / Lev Deviatkin (tweet thread, Jun 2026) (link) — 14-step three-tier progression (why/test → building blocks → build it right), 30-second tactical loop check (hard stop + human gate criteria), good vs bad first-loop examples, economic accessibility framing (who benefits vs who should skip), security tax (unreviewed code, skill injection, credential leakage, permission scope creep)
• "Loop Engineering reference repo" — Cobus Greyling (GitHub, Jun 2026) (link) — six named production patterns with cadence and token cost (Daily Triage, PR Babysitter, CI Sweeper, Dependency Sweeper, Changelog Drafter, Post-Merge Cleanup), L1/L2/L3 phased rollout per pattern, loop-audit CLI (readiness scoring) and loop-init CLI (starter scaffolding), primitives matrix (Grok vs Claude Code vs Codex), failure modes catalog and anti-patterns guide, pattern picker decision framework
• "A Beginner's Guide to Loop Engineering" — AI Edge (tweet thread, Jul 2026) — beginner-accessible six-component anatomy (trigger, execution layer, verifier, stop rules, memory, skills/CLAUDE.md), loop-prompt-as-goal-condition framing (verifiable end state + scope constraint + stop rule), practical /loop template, pro tips (start with /goal, cap iterations, run /compact before long sessions)
• "Loop Engineering" — HuaShu (IEEE-formatted paper, Jun 2026) (link) — four-layer engineering stack (prompt → context → harness → loop), five moves of a single turn (discovery/handoff/verification/persistence/scheduling) mapped to six parts, five structural anti-patterns mapped one-to-one to skipped moves, generator/evaluator separation (GAN-inspired, independent context prevents self-persuasion), Stripe case study (1,300+ PRs/week, deterministic orchestrator, Goose fork, cattle-not-pets EC2), local vs. cloud scheduling axis, four hidden costs as reinforcing cycle (verification debt → comprehension rot → cognitive surrender → cost surprise), "faithful multiplier" thesis (same loop yields opposite outcomes by builder), three staying-in-control disciplines (sample regularly, cap budgets, keep human checkpoint permanent)
• "Loop Engineering: The Karpathy Method" — codila (tweet thread, Jul 2026) (link) — Karpathy AutoResearch three-file architecture (train.py mutable / prepare.py locked evaluator / program.md constraints), 700 experiments / 20 improvements in two days, Lutke overnight result (19% quality gain, half model size), Bilevel Autoresearch paper (5× improvement from meta-looping inner search process), four-box when-to-loop test, five building blocks, comprehension debt and cognitive surrender risks
• "Getting started with loops" — ClaudeDevs / Delba Oliveira (tweet thread, Jul 2026) (link) — official Claude Code team four-primitive taxonomy (turn-based, goal-based /goal, time-based /loop+/schedule, proactive), trigger/stop/primitive/use-case properties for each type, proactive loop composition pattern (schedule + goal + skills + dynamic workflows + auto mode), code quality maintenance (clean codebase, skills for verification, reachable docs, second-agent review), five token-management levers (right primitive, clear criteria, pilot first, scripts for deterministic work, match interval to change frequency)
• "Anthropic free 1-hour loop engineering course with Fable 5" — 0xMarioNawfal (tweet, Jul 2026) — pointer to Anthropic's free one-hour loop engineering course built around Fable 5
• "Build self-improving agent system with Fable 5 in 14 steps" — Codez (tweet thread, Jul 2026) (link) — four-layer compound stack (primitives → orchestration → memory → self-improvement), model routing pattern for cost (orchestrator Fable 5 / workers Sonnet / graders Haiku / fallback Opus), Routines trigger taxonomy (schedule/API/GitHub event mapped to self-improvement patterns), vision self-verification pattern (maker screenshot → verifier vision check), classifier-block failure mode in unattended loops, 5-stage memory progression applied to Fable 5
• "How to build a self-improving code review agent" — Zach Lloyd / Warp (tweet thread, Jul 2026) — cloud software factory series part 3: code review skill with structured review.json output, GitHub action trigger with read-only agent permissions, outer-loop improver agent that synthesizes human feedback into skill PRs, convention-learning-over-time design, prompt injection mitigation via programmatic comment posting
• "From Loops to Graphs" — Carlos E. Perez (tweet/essay, Jul 2026) — loops-to-graphs topology framework: four single-loop failure modes (Goodhart's law, blindness upward, conflict, measurement decay) mapped to four topological fixes (pairing, hierarchy, arbitration, audit loops), anchors concept (ground-truth measurements, frozen rules, external "what is better" judgment), grounded vs. ungrounded as the durable axis, circular-graph failure mode (internally consistent, externally detached)
• "Stop prompting, start looping: the Boris Cherny method" — @sunick (tweet thread, Jul 2026) (link) — Practitioner deep-dive on Cherny's full workflow: compound engineering via shared CLAUDE.md (corrections ship with fixes in same PR, ~2,500 tokens lean), encoding rule ("build the thing that will do it for you next time"), plan-then-auto-accept as bandwidth technique, specific tooling (/commit-push-pr with precomputed git state, Code Simplifier and Verify App sub-agents, PostToolUse format hook, /permissions over --dangerously-skip-permissions), tokenmaxxing philosophy (benchmark against engineer cost, not tool cost)
• "Loop Engineering: The AI skill every builder needs in 2026" — rari / @0xwhrrari (tweet thread, Jul 2026) (link) — beginner-accessible popularization: five-stage cycle, six building blocks, open vs closed loops, single-agent vs fleet, token cost barrier, prompt engineer vs loop engineer skill-gap framing; synthesizes Cherny and others with no novel concepts beyond existing page coverage
• "Loop Engineering: How to Build Agents That Improve Their Own Work" — elune / @elune0x (tweet thread, Jul 2026) (link) — beginner-accessible popularization: five-stage cycle (discover/plan/execute/verify/iterate), six building blocks, open vs closed loops, single-agent vs fleet, token cost barrier, prompt engineer vs loop engineer skill-gap framing, concrete loop examples (coding/research/content/sales); synthesizes Cherny and others with no novel concepts beyond existing page coverage