# Loop Engineering ## What it is Loop engineering is the discipline of designing the system that drives an autonomous agent, instead of prompting it step by step. [[Simon Willison]]'s definition of an LLM agent is sharp: "something that runs tools in a loop to achieve a goal." The art, he says, is carefully designing the tools and the loop. Loop engineering is where that art lives. The shift is about what you spend your time on. Prompt engineering asks: what do I say to the model right now? Loop engineering asks: what is the trigger, what are the tools, what counts as done, and what stops the agent if it isn't? You author the system once. The agent runs. This sits at the top of a layered stack. [[Prompt Engineering]] is inside [[Context Engineering]] is inside [[Harness Engineering]] is inside loop engineering. You still write prompts; you still curate context. Loop engineering is the layer that puts it all in motion. ## Why it matters now The bottleneck moved. For years, the constraint in AI-assisted work was the model itself: too short a context window, too many reasoning failures, too much recovery needed from the human. That changed around 2025-2026. METR measured it concretely: Claude Opus 4.6 now completes 50% of tasks that take roughly 12 hours, up from roughly 1 hour 40 minutes a year earlier. The model can run long. It can recover from its own mistakes. The question is no longer "can the model do this?" but "have I designed the loop well enough that it will?" The most provocative data point on this comes from Terminal-Bench 2.0. The same model swings 30-50 percentage points on benchmark performance depending on which harness is running it. Claude Code vs. OpenHands vs. a homegrown loop, same underlying model, radically different results. When someone tells you "model X is best for agents," the right question is: which harness? [[Boris Cherny]], who built Claude Code: "I don't prompt Claude anymore. My job is to create loops." [[Peter Steinberger]], who built OpenClaw, makes the same argument: stop prompting coding agents; design the loops that prompt them. [[Jensen Huang]] said something similar: "Nobody writes prompts anymore. The new job is to write and handle loops." It was Cherny's and Steinberger's posts going viral that pushed the phrase into the mainstream; by late June 2026 even [[Andrew Ng]] was writing about his own loops in The Batch. That is not hype. That is where the leverage is. ## How it works A well-designed loop has six parts: **Trigger** — what starts the loop. This can be a file change, a cron job, a human command, an API event, or the completion of another loop. The trigger determines scope and timing. **Tools** — what the agent can call. Shell commands, file operations, APIs, search, sub-agents. Tool design matters enormously. Willison's framing: it's not just about designing the loop, it's about carefully designing the tools the loop runs. Dangerous or overly broad tools in the loop are a safety problem, not just a design smell. **Goal** — a clear, verifiable target state. "Make the tests pass and the type-checker clean" is a goal. "Help me with the codebase" is not. The goal needs to be testable by something other than the agent's own judgment. **Verifier** — a deterministic check that runs when the agent reports completion. This is the most important part of the loop and the most skipped. The agent stops when it *feels* done. The verifier checks whether it actually is (see [[AI Verifiability]]; this is also why verifiable domains get the biggest agent gains). [[Claude Code Hooks]] give you exactly this: a hook that intercepts the agent's exit signal, runs real completion criteria (tests green, coverage threshold met, type-check clean), and reinjects the goal if the criteria are not met. Trust the verifier, never the agent's self-report. **Stopping condition** — separate from the verifier. This fires when the loop should stop regardless of completion: max iterations reached, cost ceiling hit, a specific error type detected, a human-review flag raised. Without an explicit stopping condition, a loop that hits a bad state can spiral expensively. **Memory** — the durable spine outside any conversation (see [[AI Agent Memory]]). Every run starts from scratch unless the loop records what happened: run history, lessons learned, current state. Without memory, the loop keeps paying tokens to rediscover the same problems. [[Addy Osmani]] said it best: "The agent forgets, the repo doesn't." A markdown file is enough. Anthropic's own guidance for long-running agents says the same: give the agent a place to write notes. The agent then runs: act, observe, decide, repeat. ReAct (Yao et al., 2022) formalized this structure. Reflexion (Shinn et al., 2023) added self-correction via verbal feedback. The lineage is well-established. A widely shared Google paper on loop engineering shows the cycle in its purest form, applied to compiler optimization: the LLM proposes a code transformation, the compiler runs it and reports back (valid? faster? by how much?), the model reads that feedback and adjusts its next move, and the cycle repeats until it stops finding improvements. The agent gets better purely from grounded feedback inside its own context window. No fine-tuning. Just a tight loop with a source of truth at the bottom. ### Loops nest [[Andrew Ng]] frames product building as three loops running at different speeds, each feeding the next: - **Agentic coding loop** (minutes): spec and evals in, working code out. The agent writes, tests its own work, and iterates until the code meets the spec. Ng built a typing app for his daughter this way; the agent worked for about an hour, checking its output in a web browser several times, without needing him once. - **Developer feedback loop** (tens of minutes to hours): the developer reviews the product and steers. A year ago developers were the QA function for their agents. Now that agents test their own code, the human role moved up to product decisions: which features, where the UI fails, what the spec should say. - **External feedback loop** (hours to weeks): friends, alpha testers, A/B tests. Slow, but this is what feeds the developer's vision, which drives the spec, which drives the coding agent. The inner loop is fast and cheap. The outer loops are slow and carry the judgment. Loop engineering is designing all three and knowing which one you're standing in. ### Three shapes of loop [[Matt Van Horn]]'s distinction, and the one almost everyone trips on. Three shapes, three different jobs: - **Goal**: run until a verifiable condition is true, then stop. "Fix it until the tests pass." A separate model checks completion after every turn. - **Interval loop**: repeat on a timer while you're present. "Every 5 minutes, check the deploy." - **Routine**: run on a schedule while you're gone. "Every night, review my open PRs." Getting the shape right matters because tooling maps to it directly ([[Claude Code]]: `/goal`, `/loop`, `/schedule`). Pick the wrong shape and the loop either never stops or never starts. ### Four loop types (the Claude Code team's version) Anthropic's own taxonomy, published July 6 2026, is the same distinction plus one level below it. Each type is classified by what triggers it, what stops it, and which primitive implements it. Read as a ladder: **each type hands off one more job than the last.** | Type | Triggered by | Stops when | Primitive | Best for | |---|---|---|---|---| | Turn-based | A user prompt | Claude judges it's done or needs context | The agentic loop itself + skills | Short, one-off tasks | | Goal-based | A manual prompt with success criteria | Goal met, or turn cap reached | `/goal` | Verifiable exit criteria | | Time-based | A clock interval | You cancel, or the work completes | `/loop` (local), `/schedule` (cloud) | Recurring work, watching external systems | | Proactive | An event or schedule, no human present | Each task exits on its goal; routine runs until turned off | All of the above + dynamic workflows | Standing responsibilities: triage, migrations, upgrades | Turn-based keeps both the trigger and the check with the human. Goal-based automates the checking. Time-based automates the trigger. Proactive automates both and decides the workflow shape at runtime. So the question is not which loop is most advanced; it's whether your task is **exploratory, measurable, recurring, or standing**. Encode your manual verification steps as a `SKILL.md` so the agent can check its own work end to end, and make those checks as quantitative as you can. A frontend verification skill that says "start the dev server, click the control, screenshot before and after, confirm zero new console errors, run a Core Web Vitals trace, and rerun from step 1 if any step fails" turns a subjective "looks done" into something the loop can actually test. See [[AI Agent Skills]]. ### Four altitudes of loop (the taxonomy that resolves the arguments) The Claude Code table classifies loops by *mechanism*. Laurie Voss's July 2026 map classifies them by *altitude*, and it is the better tool for arguing about the trend, because most disagreements about loop engineering are people standing at different altitudes using the same word. He counted four distinct architectures hiding behind it: 1. **Execution loop** — the agent's own act-observe cycle. Call a tool, read the result, decide, repeat. Iterates on *steps within one task*. Ends on environment feedback, or whenever the agent decides it's done, whether or not it is. This is the innermost loop you can actually engineer; the token loop below it is just the model. 2. **Task loop** — restart the agent against the same spec until the spec is satisfied. This is Geoffrey Huntley's [[Ralph Loop]]: a completely fresh context window every iteration, exactly one task per loop. The apparent waste is the point, because re-feeding the full spec each time prevents the [[AI Context Rot]] and compaction events that quietly degrade long sessions. Iterates on *a single artifact*. Ends on spec compliance and passing tests. 3. **Product loop** — the "software factory." The whole lifecycle: triage, specification, implementation, review, verification, shipping, monitoring. Iterates on *a codebase and its backlog*, continuously. Its closing signals come from outside the codebase entirely: new issues, production logs, user feedback. Warp put its own open-sourced repo under the control of its factory platform and describes the adoption path as ratcheting the automatic PR merge rate from 20% toward 60%. Anthropic reports 65% of its product team's code now created by its internal agent, used in a delegated mode: not "fix this bug" but *take responsibility for this part of the codebase*. 4. **System loop** — "autoresearch." The inner loop does the user-facing work; the outer loop studies and maintains the inner one, iterating on *prompts, harnesses, model choices, and the evals themselves*. Roland Gavrilescu's one-liner: the loop is the product. Existence proofs at both ends of the scale: Karpathy's ~630-line autoresearch ran 50 hypothesis-edit-evaluate experiments overnight on one GPU (March 2026), and Meta's Brain2Qwerty v2 had agents iteratively modify the codebase to invent better decoding architectures. Meta's caveat is the instructive part: final training configurations were still selected by hand. Above all four sits what Voss calls the **oversight loop**, the ring swyx's original Loopcraft diagram labeled "??? loop" with exit condition *none*. Its verbs are set goals, allocate, cull. Its exit condition is you. [[Addy Osmani]]'s line from the AI Engineer World's Fair stage is the compressed version: "That inner loop is capability. The outer loop is agency." Two consequences worth holding on to: - **Autonomy is a separate dial on every loop.** You can run a fully autonomous execution loop inside a heavily supervised product loop, or hand the system loop to agents while keeping goal-setting entirely human. "Which camp is right about autonomy" is the wrong question; "what information would I need to set each dial correctly" is the right one. - **Fan-out is not a loop.** Cognition's Devin Security Swarm pattern (parallel bounded agents across a repo, findings aggregated) gets called Agentic MapReduce and gets called a loop. Dispatch, gather, validate is a *pipeline*: nothing feeds back into a next cycle, and a loop without feedback is just a `for` statement. Fan-out is a topology you deploy inside any of the four loops. ### Where the disagreement actually is By the AI Engineer World's Fair (closing July 2 2026), the word dominated the main stage and the conference ended with an hour-long debate on whether the hype had outrun what works. Translated, every sharp disagreement was about **who runs the oversight loop**: - *Turn the dial up*: pick your checkpoints deliberately and ratchet autonomy as trust accumulates. Roland Gavrilescu's memorable version is to build **orchestras before factories**, where an orchestra keeps a human conductor. - *The dial has a stop*: Geoffrey Litt called factories "a depressing vision" and argued that those who delegate understanding get replaced by the agent (see [[Comprehension Debt]]). Paul Bakaus put it flatly: "There is no auto, and there will be no auto," and his argument is about ownership as much as quality. People want a role in what they create. - *Step down, not up*: Dex Horthy pointed out that Kubernetes is built on control loops, but **deterministic** ones, and his worry is that enthusiasm has run ahead of the engineering. And the most honest data point of the whole wave: even inside Anthropic, the team running its internal agent reports being bottlenecked on **reviews** and on the human ability to conceptualize what the system is doing. The checkpoint humans kept for themselves is now the constraint. That is the strongest argument for measuring where your bottleneck actually is before adding loops. ### The July 2026 turn: from loops to graphs Two weeks after the World's Fair, [[Peter Steinberger]] posted "Are we still talking loops or did we shift to graphs yet?" and the framing moved again. The substantive claim, developed by [[Carlos E. Perez]], is that a single loop fails in four structural ways (it games its own metric, it cannot question its own reference, it fights neighbouring loops, and its measurements silently decay) and the answers to all four are topological: pair every metric with a counter-metric, let a slower loop own the faster loop's target, arbitrate conflicts explicitly, and run independent audit loops. See [[Graph Engineering]]. What carries over: everything in this note about verifiers, stop conditions, budgets, and permissions. The graph framing adds a layer above it; it does not replace it. Read both notes together, because the graph has a failure mode of its own. A network where every loop watches another loop and none touches the ground is more sophisticated than the single loop it replaced, and no more grounded. ### The counter-argument: the harness is not enough The sharpest rebuttal to the whole wave arrived on 24 July 2026, from Dex Horthy of HumanLayer, expanding his AI Engineer World's Fair keynote. His claim is uncomfortable and, as far as I can tell, correct: **no amount of loop engineering, graph engineering, or harness work fixes what is fundamentally a model-training problem.** The argument runs like this. **Models cannot maintain codebase quality over time.** Not "write bad code once." The specific thing where it becomes hard to change one part without breaking another, what Fowler called shotgun surgery. Horthy went fully lights-off in July 2025, hit three failures gnarly enough that nobody could fix them without reading the code they had stopped reading, and by November concluded it was easier to rewrite from scratch. His cofounder spent two weeks replumbing the patterns by hand. **And the reason is in how coding models are scored.** Take SWE-bench Multilingual. The reward is one bit, from two checks: did you fix the thing (`FAIL_TO_PASS`), and did you avoid breaking anything else (`PASS_TO_PASS`). How the model got there does not matter. There is no penalty for eroding maintainability. That is how you get try/catch wrapped around everything. **The asymmetry is the whole problem.** Running tests gives a clean pass or fail in seconds, which is what lets RL run millions of loops. The cost of bad architecture is measured in weeks or months, showing up the first time somebody opens that file for a one-line change and discovers the edit has to happen in eleven places. RL needs a fast, reliable oracle. There is no fast oracle for maintainability, so it cannot be rewarded during training. His line for why "model as judge" does not rescue this deserves quoting: > If a model could reliably tell good code from bad, it might have written the good version to begin with. Which produces the conclusion that matters for anyone stacking review agents: **more reviewers raise the floor, they do not move the ceiling.** They catch the dumb stuff. The ceiling is whatever got taught in RL, and good design is the thing nobody knows how to teach yet. He is fair about the frontier trying: SWE-Marathon (Abundant AI) uses ~400-hour tasks with a compound reward instead of one bit, DeepSWE (Datacurve) builds tasks that cannot already be in the training set, and Frontier Code (Cognition) penalizes tests that do not fail against the pre-patch code, which is mutation testing smuggled into an eval. First evals that even try to score maintainability. He still would not bet a codebase on them. The corroborating data, which he flags as correlational rather than proof: Faros AI reported that since teams picked up AI coding tools in early 2026, pull-request review quality fell (more comments, longer comments, many PRs merged with no review at all) while incidents and bugs per developer rose. ### Turning the lights back on His answer is not to abandon agents. It is to put human judgment back at the points where it has leverage, which is *before* the code exists rather than after. Four phases: 1. **Product requirements.** What we are building and why, in the user's terms, plus what success looks like after shipping. He mocks the screens up in rough HTML rather than describing them, because a mockup settles an argument three paragraphs would prolong 2. **System architecture.** How services, endpoints, schemas, queues and stores talk to each other. Heavy on visualizations: sequence diagrams, contract shapes, data models 3. **Program design.** The phase he calls criminally underemphasized. Before anyone writes implementation, agree on the *shape of code*: types, method signatures, program layout, call stacks. Call-stack trees in pseudocode, file-tree diffs, signatures for the key new functions. Every one of these is a decision you would otherwise make implicitly during code review, at the most expensive possible moment to change your mind 4. **Vertical slices.** Models love horizontal plans (migrations, then services, then API, then frontend), which leaves nothing you can touch until the end. Slice vertically instead, the way most of us worked before agents: mock the API contract and hit it with curl, build the frontend against mock data, wire the services, then the database. Test at every step **Thirty minutes of planning saves hours of review.** He does not run all four phases on everything: roughly 40% of tasks get one-shot or one-shot with light feedback, medium work gets product and system design in one document, and only large work gets the full sequence. Two lines worth keeping: > You don't have too many PRs. You have too many bad PRs. A great PR is a joy to review. One needing 20% rework is a burden on everyone, and he puts AI one-shot PRs closer to 50%. > It is possible you are too busy trying to move 10-100x faster and trying to convince yourself code quality doesn't matter any more, when you could embrace the constraints and move 2-3x faster, safely. **How this sits against the graph framing.** [[Graph Engineering]] says: change the topology so loops watch each other. Horthy says: fine, but topology cannot supply what the model was never trained to have. Both conclusions point the same way, which is why I read them as complementary rather than opposed. The graph needs anchors that cannot argue back; Horthy's anchor is a human who read the code. And his 2026 verdict on the whole wave is the one line I would keep from the entire discourse: **the hype is outrunning the discipline.** ## Recommendations **Write the verifier before the loop.** If you cannot write a deterministic check for "done," your goal is not specific enough. Tighten the goal first. **Read about premature stopping before you ship anything.** This is the central failure mode: the agent halts when its subjective confidence is high, not when the task is actually finished. Every serious loop needs a verifier that can say no. **Build loops out of battle-tested skills.** Austin Marchese calls this skill-driven loop development, and it's the right order of operations: never wire a loop around instructions you haven't already run by hand and refined. [[AI Agent Skills]] are the natural building blocks here; a skill you've battle-tested knows how you want the task done. A loop built on top of it inherits that. A loop built on a vague prompt inherits the vagueness, then repeats it autonomously. **Roll out in phases: report, assist, then unattended.** Week one, the loop only reports what it would do. Then it proposes fixes you approve. Only after that does it run unattended. The cobusgreyling/loop-engineering repo bakes this L1 → L2 → L3 progression into every pattern it ships. Same idea at the micro level: keep the first runs of any new loop in training mode, pausing at each step for your approval, until you've seen it do what you actually meant. **Scale with subagents in isolated worktrees.** The main loop decomposes the task, spawns [[AI Subagents]] in isolated worktrees (each with its own context window, model tier, and permissions), collects results, and decides what to do next. This protects your main context window and lets you route cheap subtasks to cheaper models. **Scope permissions and sandbox before you run.** [[AI Agent Permissions]] are part of the loop design, not an afterthought. Willison's warning: "An AI agent is an LLM wrecking its environment in a loop." YOLO mode (auto-approve on all shell commands) is where real productivity is and also where the real danger is: bad shell commands, secret exfiltration, the machine used as a proxy for attacks. Define what the loop can touch before you start, not after something goes wrong. **Route models by subtask, not uniformly.** A frontier model for planning and reasoning; a cheaper, faster model for mechanical subtasks. The harness manages this. The goal is accuracy per dollar, not the best model everywhere. **Put a different model family in the checker seat.** An agent grading its own homework will delete the failing test and call it done ([[Goodhart's Law]] with a shell). A separate verifier model helps; a verifier from a *different* model family helps more, because it doesn't share the worker's blind spots. The Clodex pattern (Codex reviewing Claude's pull requests before merge, capped at 5 iterations) is the cleanest example: two model families have to agree before code lands. **Watch cost.** Errors compound in loops. A bad state in iteration 3 becomes a worse state in iteration 8 if the verifier doesn't catch it. And the bills are not theoretical: Uber capped its engineers at $1,500 per AI tool per month after burning through its annual AI budget in four months, and one Reddit user torched around $6,000 overnight with a single unbounded command. Every goal gets a budget; every loop gets a cap. Set the ceiling before you walk away, not after the invoice arrives. Log everything. ## Tips and tricks **Run the four-condition test before building any loop.** Does the task repeat? Is there a clear definition of done? Can you afford the tokens if it wanders? Does the loop have the tools to verify its own work? Four yeses make a loop candidate. Anything else stays a prompt. **Stop hooks are the most underused primitive.** [[Claude Code Hooks]] let you intercept exits deterministically. A stop hook that rejects agent self-reports and runs your own checks is not a nice-to-have; it's what makes the loop trustworthy. **The harness outweighs the model.** Terminal-Bench 2.0 showed 30-50 point swings. Design the harness first; choose the model second. **Loops only pay off with a strict validation gate.** Without one, you get an agent agreeing with itself on repeat. That is not autonomous work; that is expensive noise. Or, as one practitioner put it during the June 2026 wave: a loop that cannot tell good output from bad just automates being wrong, faster. **One green run is luck. A streak is reliability.** Don't stop at the first clean pass. The quality-streak pattern only declares victory after N consecutive clean runs, and any new failure resets the count. This respects how flaky "it works" really is. **Add anti-spin stops.** Most loops never ask whether they are actually making progress; they retry the same broken approach, or quietly edit the test until it passes. No-progress detection, retry caps, and flip-flop detection (the loop alternating between two approaches) are cheap to add and catch exactly this. **Spend your human time before the code, not after it.** The instinct under agent pressure is to review harder. The leverage is upstream: product requirements, architecture, program design, vertical slices. A decision made during program design costs minutes. The same decision made during code review costs a rewrite. **Benchmark gains are not maintainability gains.** When a model tops a coding benchmark, what improved is measured by "tests pass, nothing else broke." Nothing in that score says the codebase is still workable in six months. Treat the two as unrelated until somebody ships an eval that scores design. **If human review is your bottleneck, a loop just floods the queue.** Measure where the actual constraint is before adding automation. Loops move throughput; they do not improve quality gates. **Do not let permission creep happen.** Scope at design time. Once an agent has broad shell access, you are trusting every tool call it makes, forever. **Context discipline matters inside the loop.** Longer context windows per subagent are not free. [[Context Engineering]] (what you put in, what you leave out, what you refresh) is still a skill, just applied at the loop level instead of the prompt level. **"Taste" is a context advantage, not magic.** [[Andrew Ng]]'s reframing of why humans stay in the loop: for nearly every product, the human knows far more about the users and the operating context than the AI does. Human-in-the-loop is how that knowledge gets injected into the system. So long as you know something the agent doesn't, your review step isn't ceremony; it's the highest-bandwidth input the loop has. You move up a loop, not out of the loop. **A loop is not automatically a control system.** The sharpest pushback on the trend came from the control-theory crowd: if one stochastic component generates output and another stochastic component reviews it, you may just have a faster stochastic loop with better branding. Recursion with a dashboard. Deterministic anchors, measurable error signals, bounded failure modes, and an accountable human owner are what turn a loop into control. Vitalii Oborskyi's summary under Ng's post nails it: the industry is not short of loops; it is short of control. **The "Brute Squad" framing is useful.** Sourcegraph described agentic coding as brute-force autonomous agents. That is an honest description. Loops are not elegant; they are persistent. The value is iteration speed, not elegance. **plentysun's pattern (Claude Code features):** context discipline plus hooks that force steps. The hook is not optional scaffolding; it is the loop's backbone. **Ask the three questions kaize asks.** The real question was never "what do I type." It is: can the loop recover from a failed step, can it control spend, and does it know when to stop? His compressed cycle is Think → Act → Observe → **Verify → Evolve** → Repeat, and the last two verbs are what separate a loop from a retry. His framing of the whole stack is the cleanest one-liner available: *prompt decides how the agent starts, context decides what the agent sees, loop decides how far the agent gets.* **Use scripts for the deterministic parts.** Running a script is far cheaper than reasoning through the steps every iteration. If a skill needs a form filled or a file transformed the same way each time, ship the script inside the skill instead of re-deriving the code on every run. **Pilot before a large run.** Dynamic workflows can spawn hundreds of agents. Gauge usage on a small slice of the work first, and match the interval of any routine to how often the watched thing actually changes. **When one run fails your standard, fix the system, not the instance.** The reflex is to correct the individual output. The leverage is to encode the correction so every future iteration inherits it. This is what turns a loop into something that compounds. **Permission boundaries beat vigilance.** The sharpest comment on Osmani's one-month retrospective: what decides safety in a brownfield codebase is not whether the engineer stays alert, it's what the loop was *permitted* to touch, which changes it could commit, and what evidence got captured before merge. Design from the authority the loop holds during a run, not from the stop condition. Attention doesn't scale; enforced boundaries do. The counter-question is equally sharp and unresolved: accountability is a human thing, and you cannot fire a loop. **The skeptics' case, stated fairly.** The most common report from people who tried meta-loops and bounced: agents reward-hack, go depth-first into their own internal domain language, chase their own tails, and burn indefinitely until a human steps in, producing a high ratio of slop to useful code. Notably, the same skeptics carve out an exception for autoresearch (exhaustively exploring a space no human could cover by hand) and for Ralph-style task loops (making a cheaper model perform like a better one at 5x tokens and 1/10 the cost per token, so the math works). That carve-out is the tell: loops pay off where the search space is large and the verifier is real, and disappoint where neither is true. **A fourth loop the other taxonomies mostly skip.** [[Maryam Miradi]]'s version stacks four loops by scope, and the last one is the one that rarely gets built: 1. **Task execution** — goal and context in, plan, act, observe, repeat until done 2. **Verification** — output checked against tests, rules or evals rather than the agent's self-assessment; failure triggers retry 3. **Orchestration** — work triggered from outside (Slack, GitHub, email, queues, schedules), with execution and verification running automatically and results returned 4. **Continuous improvement** — analyse traces across *many* runs; find repeated tool errors, missing context, weak prompts, bad memory; then fix the prompts, tools, skills, evals or workflow Loops 1 to 3 are covered by every taxonomy on this page. Loop 4 is the one people describe and almost nobody runs, and it's the only one that operates on the population of runs rather than a single run. Its argument is sharp: without it, a repeated failure doesn't stay a small bug, it scales across thousands of executions. The verifier catches the individual failure; only trace analysis catches the *pattern* that keeps producing it. Human approval sits inside any of the four, not as a separate stage. That framing is better than treating oversight as a fifth loop, because it makes approval a property of a step rather than a phase you can skip. **A vendor datapoint on the other side.** Alibaba used the term *Loop Engineering* explicitly in the [[Qwen 3.8]] launch (2026-08-03) for the setup behind `oh-my-cli`: an issue state machine, dispatcher, monitor and watchdog wired into one execution loop, with requirements normalised into issues, claimed by agents through `ready → leased → act`, then driven through code, tests, previews and logs before merge. They report ~16 days of unattended operation producing 265 commits, 127 PRs and 151 issues, with the trace public. Treat the framing as marketing and the artifact as evidence: it is one of the few long-horizon loop runs anyone has published end to end. Note what carries the run, and it is exactly what this note argues for throughout: a real verifier (build, unit, E2E, lifecycle checks) and enforced state transitions, not a smarter model left alone. ## References ### Foundational - Simon Willison, "Designing agentic loops" (2025-09-30) — https://simonwillison.net/2025/Sep/30/designing-agentic-loops/ - Anthropic, "Building Effective Agents" (2024-12) — https://www.anthropic.com/news/building-effective-agents - Anthropic, "Effective harnesses for long-running agents" — https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents - Anthropic, "Effective context engineering for AI agents" (HN discussion) — https://news.ycombinator.com/item?id=45418251 - ReAct (Yao et al., 2022) — https://arxiv.org/abs/2210.03629 - Reflexion (Shinn et al., 2023) — https://arxiv.org/abs/2303.11366 ### Taxonomies (start here) - Anthropic / Claude Code team (Delba de Oliveira), "Getting started with loops" (2026-07-06) — https://x.com/ClaudeDevs/status/2074208949205881033 (the four primitives: turn-based, `/goal`, `/loop` + `/schedule`, proactive) - Laurie Voss, "What the hell is a loop, anyway?" (2026-07-03) — https://www.linkedin.com/pulse/what-hell-loop-anyway-laurie-voss-ldmdc (execution / task / product / system, plus the oversight loop) - Akshay Pachaar on X, "the four types of agent loops" (2026-07-13) — https://x.com/akshay_pachaar/status/2076748259377516782 · full write-up: "Loop Engineering Clearly Explained" (2026-06-22) - bobbytables.io, "The Agentic Loop: Three loops in a trench coat" — HN discussion (incl. the reward-hacking and slop critiques) — https://news.ycombinator.com/item?id=48907672 - swyx, "Loopcraft: The Art of Stacking Loops" (2026-06-12) — https://www.latent.space/p/loopcraft ### Published long-horizon runs - Qwen Team, "Qwen3.8-Max: A New Bar for Coding and Cowork" (2026-08-03) — https://qwen.ai/blog?id=qwen3.8 (the "Loop Engineering Setup" section: state machine, dispatcher, monitor, watchdog) - `oh-my-cli`, the full public trace of the ~16-day autonomous run — https://github.com/qwen-code-dev-bot/oh-my-cli ### 2026 commentary - Maryam Miradi, "The Art of Loop Engineering" (2026-07) — https://www.linkedin.com/posts/maryammiradi_the-art-of-loop-engineering-how-to-share-7487945874938077185-1gB_ (the four loops: task execution, verification, orchestration, continuous improvement) - Addy Osmani, "Loop Engineering, a month on" (2026-07) — https://www.linkedin.com/posts/addyosmani_loop-engineering-a-month-on-ugcPost-7483004445094506496-R62H - Addy Osmani, "Loop engineering" (2026-06-07) — https://addyosmani.com/blog/loop-engineering/ - kaize, "Loop engineering: the reading list" (2026-07-05) — https://x.com/0x_kaize/status/2073743517155774641 · article: "Loop Engineering: From Prompting to Looping" (2026-07-04) - OpenAI, "Harness engineering" — https://openai.com/index/harness-engineering/ - Martin Fowler, "Harness engineering for coding agent users" — https://martinfowler.com/articles/harness-engineering.html - Firecrawl, "Loop engineering" — https://firecrawl.dev/blog/loop-engineering - Mem0, "Loop engineering for AI agents: memory-first design" — https://mem0.ai/blog/loop-engineering-for-ai-agents-memory-first-design - Oracle, "What is the AI agent loop" — https://blogs.oracle.com/developers/what-is-the-ai-agent-loop-the-core-architecture-behind-autonomous-ai-systems - LangChain, "The Art of Loop Engineering" (2026-06-16) - Andrew Ng, "3 key loops for building 0-to-1 products", The Batch issue 359 (2026-06-26) — https://www.deeplearning.ai/the-batch/issue-359 (LinkedIn version: https://www.linkedin.com/posts/andrewyng_loop-engineering-is-a-hot-buzzphrase-after-share-7477753882505338880-dBJ-/) - Matt Van Horn, "WTF Is a Loop? Part 2: The 15 Loops People Are Actually Running" (2026-06-20) — https://www.linkedin.com/pulse/wtf-loop-part-2-15-loops-people-actually-running-steal-matt-van-horn-xgkkc/ - Austin Marchese, "Stop Prompting Claude. Start Loop Engineering." (YouTube, 2026-06-19) — https://www.youtube.com/watch?v=YAS4ojuhbW4 - Movez on X (summary of the Google 19-page loop engineering PDF: act → observe → learn → repeat) — https://x.com/0xMovez/status/2069500921382326531 - Kent C. Dodds on X ("I've been loop engineering for months", with video) — https://x.com/kentcdodds/status/2069510257525874923 - Data Science Dojo, "Agentic Loops: From ReAct to Loop Engineering (2026 Guide)" — https://datasciencedojo.com/blog/agentic-loops-explained-from-react-to-loop-engineering-2026-guide/ - bdtechtalks, "Demystifying loop engineering" (2026-06-22) — https://bdtechtalks.com/2026/06/22/ai-loop-engineering/ - Requesty, "Loop Engineering: How to Build AI Agent Loops That Run Themselves" — https://www.requesty.ai/blog/loop-engineering-how-to-build-ai-agent-loops-that-run-themselves - Augment Code, "Agentic Design Patterns (2026 Pattern Catalog)" — https://www.augmentcode.com/guides/agentic-design-patterns - Sourcegraph, "The Brute Squad" — https://sourcegraph.com (Readwise highlight) - Dex Horthy, "Why Software Factories Fail" part 1, "the harness is not enough" (2026-07-24) — https://x.com/dexhorthy/status/2080697380379427275 - Dex Horthy, "Why Software Factories Fail" part 2, "Turning the lights back on" (2026-07-25) — https://x.com/dexhorthy/status/2081058573556306030 - Dex Horthy, "Why Software Factories Fail" part 3 (2026-07-27) — https://x.com/dexhorthy/status/2081797628552270027 - Dex Horthy, keynote video version, AI Engineer World's Fair 2026 — https://www.youtube.com/watch?v=Ib5GBkD555M - Faros AI, the AI acceleration whiplash report (review quality down, incidents and bugs up) - SWE-Marathon (Abundant AI), DeepSWE (Datacurve), Frontier Code (Cognition) — the first evals attempting to score maintainability rather than pass/fail ### Curated lists - cobusgreyling/loop-engineering (7 production patterns, starters, and the loop-audit / loop-init / loop-cost / loop-sync / loop-context CLIs; five building blocks + memory) — https://github.com/cobusgreyling/loop-engineering - serenakeyitan/awesome-agent-loops — https://github.com/serenakeyitan/awesome-agent-loops - Picrew/awesome-agent-harness — https://github.com/Picrew/awesome-agent-harness - RyanAlberts/best-of-Agent-Harnesses — https://github.com/RyanAlberts/best-of-Agent-Harnesses - ai-boost/awesome-harness-engineering — https://github.com/ai-boost/awesome-harness-engineering ### Tools and repos - earendil-works/pi — https://github.com/earendil-works/pi - snarktank/ralph (the [[Ralph Loop]]) — https://github.com/snarktank/ralph - the-open-engine/zeroshot — https://github.com/the-open-engine/zeroshot ### Talks and threads - Louis Bouchard, "Loop Engineering Explained" (YouTube) — https://www.youtube.com/watch?v=NjXIIH9vcv0 - HN: "The unreasonable effectiveness of an LLM agent loop with tool use" — https://news.ycombinator.com/item?id=43998472 - HN: "Designing agentic loops" — https://news.ycombinator.com/item?id=45426680 - Paweł Huryn on X (Cherny / Huang quotes) — https://x.com/PawelHuryn/status/2069315068664197315 - Graham Neubig on X (his agent loop) — https://x.com/gneubig/status/2064011013637234728 ## Related [[Graph Engineering]] · [[Goodhart's Law]] · [[Harness Engineering]] · [[Agentic loops]] · [[How Coding Agents Work]] · [[AI Agent Harnesses (MoC)]] · [[Agentic Engineering]] · [[AI Guardrails]] · [[Claude Code]] · [[Feedback Loop]] · [[Levels of AI use]] · [[AI Agent Skills]] · [[AI Skill Best Practices]] · [[AI Verifiability as a Capability Ceiling]] · [[Ralph Loop]] · [[AI Agent Memory]] · [[AI Agent Orchestration]] · [[Claude Code Hooks]] · [[Goal Engineering]] · [[Comprehension Debt]] - [[Cursor Agent Swarms]] - [[DSLs Make LLM Output Reliable]] - [[Qwen 3.8]]