An Introduction to Loop Engineering
Loop engineering is the practice of designing self-running cycles for AI agents, allowing them to operate autonomously without constant human intervention. The concept gained traction in June 2026, building on earlier research such as ReAct (2022) and Reflexion (2023), and represents the latest layer in the progression from prompt engineering to context engineering to harness engineering. This article explores the definition, origin, anatomy, and challenges of building reliable loops.
An Introduction to Loop Engineering - MachineLearningMastery.com
An Introduction to Loop Engineering - MachineLearningMastery.com
In this article, you will learn what loop engineering is, where it came from, and how to design autonomous AI agent cycles that run reliably without constant human supervision.
Topics we will cover include:
The origin and definition of loop engineering, and how it fits into the broader progression from prompt engineering to context engineering to harness engineering.
The anatomy of a reliable loop, including its essential components, common patterns, and the pseudocode skeleton that underlies nearly every production implementation today.
The three hardest problems in loop engineering — context management, termination, and verification — and the failure modes that result from getting any one of them wrong.
Introduction
A few months ago, a developer’s evening looked like this: open the coding agent, type an instruction, wait, read what came back, paste the error into the chat, wait again, nudge it in a slightly different direction, and repeat until the feature actually worked or until it was time to sleep. The agent was doing real work, but the human was still holding it the entire time, one turn after another, like driving a car that needs a hand on the wheel every three seconds.
That evening looks different now for a growing number of engineers. They write one instruction, close the laptop, and come back the next morning to a draft pull request, a triaged issue list, or a green CI build, along with a readable trail of what the agent tried and why. Nobody stood over it, typing the next prompt. What changed wasn’t the model. It was what got built around the model.
The name that stuck for that shift is loop engineering, and it went from a niche phrase to something people were debating on every timeline within about a week in June 2026. This article walks through where the term came from, the research it actually descends from, what a loop is made of, and how to build a small one of your own.
What Loop Engineering Actually Means
Loop engineering is the practice of designing the system that prompts, checks, remembers, and re-runs an AI agent, instead of a person doing all of that by hand, turn by turn. The unit of work stops being a single prompt or even a single conversation. It becomes a loop: a repeating cycle where the model takes an action, gets feedback from its environment, uses that feedback to decide what to do next, and keeps going until a real, checkable condition is met.
It helps to hold this next to the thing it’s replacing. A chain runs in a fixed order: step A leads to step B, which leads to step C, and that’s it. A loop is dynamic. The agent might go from A to B, discover B didn’t work, revise its approach, and only then move to C, or it might loop back to A entirely. MindStudio’s breakdown of the concept puts it plainly: a loop continues until a task is genuinely complete, a stopping condition triggers, or the agent determines it can’t go any further. That’s a fundamentally different shape of work than “ask once, get an answer, copy it out.”
The other framing worth sitting with is the “recursive goal” idea. Instead of typing each next step, you define a purpose — something like “make the test suite pass” or “triage every open issue and draft fixes for the straightforward ones” — and the agent iterates on its own toward that purpose: inspect the code, make a change, run a check, read the outcome, decide the next move. The skill shifts from writing one very good sentence to designing a cycle you trust enough to walk away from.
How This Became a Term Almost Overnight
It’s worth being specific about the timeline here, because the speed is part of the story.
On June 7, 2026, developer Peter Steinberger, known for the OpenClaw agent project, posted on X that the relevant skill had already changed: you shouldn’t be prompting coding agents anymore, you should be designing the loops that prompt them for you. That post reportedly crossed 6.5 million views within days and dominated agent-focused conversation for the following week.
The very next day, Google engineer and author Addy Osmani published an essay titled simply “Loop Engineering” that took Steinberger’s claim and gave it an actual anatomy: automations, worktrees, skills, connectors, and sub-agents, plus a sixth piece underneath all of it — external memory. That essay is what turned a viral take into a vocabulary that other people could build on and argue about.
It wasn’t only outsiders making this case. Boris Cherny, who leads Claude Code at Anthropic, is quoted by Osmani as saying, “I don’t prompt Claude anymore. I have loops running that prompt Claude, and figuring out what to do. My job is to write loops.” When the person building one of the most-used coding agents on the market says he’s stopped prompting it directly, the idea has clearly moved past a fringe opinion.
The timing makes sense once you look at what changed underneath it. By mid-2026, coding agents had gotten good enough to run unattended for genuinely long stretches, recovering from their own mistakes along the way, rather than needing correction every second or third step. Once a single agent run can last an hour and touch dozens of files, the bottleneck isn’t the sharpness of your prompt anymore. It’s whether you’ve built a cycle that keeps the agent productive, checked, and pointed at the right goal for the whole hour — including the part where nobody’s watching.
Where It Fits: Prompt, Context, Harness, Loop
Loop engineering didn’t appear out of nowhere, and it helps to see it as the newest layer in a steady progression outward, each one wrapping the previous layer rather than replacing it.
Prompt engineering came first, roughly 2022 through 2024. The skill was wording: giving the model a role, breaking a task into steps, providing examples, and asking it to reason step by step. It optimized expression, and its ceiling was real — even a perfectly worded prompt can’t hand the model facts it was never given.
Context engineering followed in 2025. The focus moved from the words themselves to everything the model actually sees at the moment it responds: conversation history, retrieved documents, tool output, and any other information assembled for that step. Shopify’s Tobi Lütke offered a definition that stuck in mid-2025, describing it as providing all the context needed for a task to be plausibly solvable by the model. Andrej Karpathy endorsed a similar framing around the same period, and by September 2025, Anthropic had formalized the idea as curating and maintaining the optimal set of tokens available during inference. Prompt engineering effectively became one ingredient within context engineering rather than a separate discipline.
Harness engineering arrived in early 2026 as agents started doing longer, more autonomous, multi-step work in real production settings. The harness is the full environment around an agent — the scaffolding, the tools it’s given, the constraints it operates under, and the feedback loops that catch its mistakes. It’s what makes an agent dependable instead of merely capable, and it nests both prior layers inside it: a harness contains context, and context contains prompts.
Loop engineering is the layer sitting on top of all three. Where harness engineering asks what environment an agent needs, loop engineering asks a narrower, more operational question: what cycle keeps the agent working toward the goal, and when exactly does that cycle stop? None of these layers replaced the one before it. You still write prompts, you still curate context, you still build a harness. Loop engineering is simply the part where all of that gets put into motion and given a rhythm.
Each layer of the engineering stack wraps and contains the ones before it.
The Research Behind the Buzzword
It’s tempting to treat loop engineering as something invented in a single week in June, but the mechanics behind it are closer to five years old, and knowing the lineage is what separates a real understanding of the idea from just repeating the trend piece.
The direct ancestor is the ReAct pattern, short for Reason plus Act, introduced by Yao and colleagues in 2022 out of research connected to Princeton and Google. The core idea was to interleave reasoning steps with action steps: the model thinks about what to do, takes an action, observes what actually happened, thinks again in light of that observation, and acts again. That interleaving — reason, act, observe, repeat — is the base loop that essentially every modern coding agent still runs today.
A year later, Reflexion, from Shinn and colleagues in 2023, added something ReAct didn’t have: memory and self-critique. A Reflexion-style agent runs three distinct roles instead of one: an Actor that does the work, an Evaluator that scores the result, and a Self-Reflection step that writes an actual verbal lesson — something like “the patch failed because the import path was wrong” — into an episodic memory the agent reads back on its next attempt. That’s the mechanism behind a loop that visibly improves within a single session, without anyone retraining the underlying model.
Anthropic’s own December 2024 guide, Building Effective Agents, named two more patterns worth knowing. The evaluator-optimizer pattern has one model generate a candidate solution while a second model checks it against explicit criteria and hands back feedback, cycling until the evaluation actually passes. The orchestrator-workers pattern has a central model that dynamically breaks a large task into smaller pieces, hands each piece to its own worker with a clean context window, and then combines the results. If Osmani’s “sub-agents” and “worktrees” sounded familiar, this is the formal version of the same idea.
The point of walking through all four of these isn’t trivia. It’s that “loop engineering” is a product name and a rallying phrase for a research direction that’s been quietly accumulating results since 2022. The June 2026 moment didn’t invent the loop. It gave regular developers — not just researchers — a reason and a vocabulary to start building one deliberately.
The Anatomy of a Loop
Strip away the branding and a loop that’s actually reliable — rather than one that spins its wheels or runs forever — tends to have the same handful of components, no matter which tool or team built it.
It needs a goal with a genuinely testable termination condition. “Make the app better” gives an agent nothing to check against, so it either runs forever or stops arbitrarily based on a guess. “Make every test in the auth module pass” is checkable in a literal, mechanical sense, and that difference is the whole ballgame.
It needs a tool set that actually touches the real environment: code execution so it can see whether something runs, file system access to read and write, a terminal for commands, a test runner and a linter to generate honest feedback. A loop’s feedback is only as trustworthy as the tools producing it. An agent that can reason brilliantly but can’t run its own code is just guessing with extra steps.
It needs context management. Every iteration of a loop adds more to the record — the code written, the errors hit, the decisions made along the way — and a context window is a fixed size. Left unmanaged, a long loop either overflows that window or, more insidiously, starts attending less carefully to what actually matters as the transcript grows, a problem people increasingly call context rot.
It needs explicit termination and escalation logic: a real success condition, a real failure condition (a maximum number of iterations, a token or time budget, repeated identical errors with no progress), and a defined pat
[truncated for AI cost control]