Introduction to Loop Engineering: Designing AI Agent Loops (2026)

A team I know left a coding agent running on a Friday afternoon. The task was open-ended — “keep fixing failing tests until the suite is green” — and the…

A team I know left a coding agent running on a Friday afternoon. The task was open-ended — “keep fixing failing tests until the suite is green” — and the agent dutifully looped. It just never stopped. Over the weekend it retried the same broken approach against the same failing test hundreds of times, each attempt a fresh round of expensive model calls. Monday’s lesson wasn’t in the code the agent wrote. It was in the bill, and in the realization that nobody had designed the one thing that mattered: when the loop was allowed to quit.

That missing off-switch is the entire subject of a discipline that got its name in June 2026 and has been reorganizing how people talk about agents ever since: loop engineering. If you’re still pouring your effort into writing the perfect prompt, you’re optimizing a bottleneck that already moved. The prompt isn’t where agents break anymore. The loop is.

One turn of an agent loop — trigger, plan, act, verify, persist — and then a stop rule decides whether to go around again.

TL;DR

→ Loop engineering is the practice of designing the system that prompts an AI agent for you — its trigger, its steps, its verifier, and its stop rules — instead of prompting the agent by hand each time.
→ It’s the fourth layer in a stack: prompt engineering, then context engineering, then harness engineering, then loop engineering — each one wraps the layer inside it rather than replacing it.
→ An agent, stripped down, is “an LLM in a while loop with tools” — the loop, not the model, is what separates an agent from a chatbot.
→ The single most important design decision is the stop rule: a loop with no termination logic is a resource sink that burns money without converging.
→ Never let an agent grade its own work — models asked to evaluate their own output reliably inflate the grade, so generation and verification must be separate.
→ Because generation is now cheap and abundant, the scarce resource is judgment: the quality of your verifier sets the quality of the whole loop.
→ Agent loops make roughly 10x–100x more model calls than a single prompt, so cost control (model routing, prompt caching, iteration caps) is a first-class part of the design, not an afterthought.

What loop engineering actually is

The clearest definition comes from Addy Osmani, a director on Google’s Cloud AI team, who named the practice in an essay in June 2026: loop engineering is replacing yourself as the person who prompts the agent, and designing the system that does it instead. The idea was in the air already — Peter Steinberger’s one-line version (stop prompting your coding agents; design the loops that prompt them) crossed millions of views in a day, and Boris Cherny, who built Claude Code, described his own job the same way: writing the loops that drive the model. Osmani gave the scattered practice a name and a parts list.

Underneath the buzz, the mechanism is unglamorous. Simon Willison’s stripped-down definition is the one to hold onto: an agent is “an LLM in a while loop with tools.” It takes an input, reasons about what to do, calls a tool, looks at the result, and goes around again until it’s done or hits a limit. That cycle is the whole ballgame. A chatbot answers in one pass; an agent persists across many steps. If you’ve walked through my guide to building a Databricks AI agent that reasons, acts, observes, and repeats, you’ve already built the innermost loop — loop engineering is the discipline of everything wrapped around it.

It helps to see loop engineering as the top of a stack that grew one layer at a time. Prompt engineering is about the words you send. Context engineering is about all the information the model can see. Harness engineering is about the environment the agent runs in — its files, tools, and memory. Loop engineering is about the iterative cycle that drives the agent toward a goal. Each layer wraps the previous one; none of them replaces it. The model is the brain, the harness is the body, and the loop is the routine that gets the body out of bed every morning.

A single turn of the loop

Decompose one pass through a loop and you get roughly five moves: discovery (find the work to do), handoff (give it to the agent with the right context), verification (check the result against something external), persistence (write down what happened so the next run remembers), and scheduling (decide when to run again). The diagram above is that turn drawn out. Miss any one of them and the loop degrades in a predictable way — skip persistence and every run starts from amnesia; skip verification and errors compound silently.

Osmani’s parts list maps neatly onto this. A real loop needs automations (a schedule or event trigger — without one it’s just a chat session), isolated workspaces so parallel runs don’t collide, codified knowledge the agent can load on demand, connectors to real tools and systems, and independent verification from a second agent. There’s a sixth piece that ties them together: external state — a markdown file or a task board — so progress survives between runs.

Two of those pieces are familiar territory for data engineers. The trigger is just scheduling, the same instinct behind orchestrating pipelines with Snowflake Streams and Tasks on a cadence. And the connectors are how the agent reaches your data at all — increasingly through MCP servers wrapping governed assets, which slots right next to a native dbt integration or the everyday operations in the dbt commands reference. Loop engineering doesn’t throw out your orchestration and governance instincts — it reuses them.

The loops stack: loopcraft

The real leverage shows up when you stop thinking about a single loop and start stacking them. LangChain’s framing describes four loops nested inside one another, and value compounds as you climb:

1. The agent loop

The model calls tools until the task is done. This is the one everyone starts with, and the one most tutorials stop at.

2. The verification loop

Wrap the agent loop in a grader that checks each output against a rubric. Fail the check, feed the failure back, and try again. The grader can be deterministic (run the tests, confirm the links resolve) or another model acting as judge.

3. The application loop

A human approves outputs before they reach the end user. This is where “human in the loop” stops being a slogan and becomes an actual control point on sensitive workflows.

4. The hill-climbing loop

The outermost loop improves the harness itself — better prompts, better tools, better rubrics — with changes flowing through review before they deploy. This is where an agent stops being a fixed tool and starts getting better at your specific work over time.

Most teams live in loops 1 and 2. The compounding value is in 3 and 4, where the system embeds into your workflow and improves against your standards instead of a generic benchmark.

The verifier is the whole game

Here is the insight that separates people who ship reliable loops from people who ship expensive ones. When generation becomes cheap — and inside a loop, it does — the bottleneck moves entirely to verification. A loop only spins as fast as its ability to tell a good result from a bad one. Andrej Karpathy’s version of this is the generation-verification loop: generation got cheap, so the loop is rate-limited by its verification half, which makes review, taste, and knowing what “correct” looks like the most leveraged skills an engineer has. Your judgment, encoded into a verifier, is effectively the loop’s reward function.

Which leads to the rule you cannot skip: do not let the agent grade its own homework. Empirically, a model asked to evaluate its own output tends to praise it — it gives itself an A. Tuning a separate, skeptical evaluator is far more tractable than trying to make a generator honestly critical of its own work. Keep the generator and the evaluator apart. This is the same principle behind agreeing on shared, governed definitions before you trust automated output, which is exactly the problem the Open Semantic Interchange is trying to solve at the industry level: automation is only as trustworthy as the standard it’s checked against.

What does this look like as code? Every real loop has the same skeleton — generate, verify with something independent, stop on success or a hard cap:

def run_loop(goal, max_iterations=8):
    state = load_state(goal)          # persistence: remember prior runs
    for attempt in range(max_iterations):
        result = agent_generate(goal, state)   # the inner agent loop
        verdict = independent_verify(result)   # a SEPARATE evaluator
        save_state(goal, result, verdict)      # write progress down
        if verdict.passed:
            return result                       # stop rule: success
    raise StoppedIncomplete(goal, state)        # stop rule: hard cap

The interesting lines aren’t the generation — they’re the ones that decide when to quit and who does the judging.

The cost math nobody does upfront

A single prompt is one model call. A loop is not. Reported figures put agent loops at roughly 10x to 100x the number of model calls of a single-shot prompt, because every iteration — every plan, act, and verify — is its own round of inference. That multiplier is the whole cost story.

Work a rough example. Say one loop turn costs about 15,000 tokens once you count the plan, the tool calls, and the verification pass. A task that converges in 4 turns costs ~60,000 tokens — fine. But a goal-based loop with a weak verifier and a generous iteration cap that grinds for 40 turns costs ~600,000 tokens for a single task, and if it never hits a stop condition it just keeps going. Run that unattended across a fleet of tasks and the numbers stop being rounding errors. The fixes are concrete: route cheap sub-steps (classification, triage) to small models and reserve the frontier model for final review; cache the stable prefix of your prompts so repeated context isn’t re-billed every turn; and cap iterations hard. Teams applying model routing and caching report total loop costs dropping on the order of 60–80%. None of that helps if the loop can’t decide to stop — which is the real lesson of that Friday-to-Monday weekend.

The gotchas nobody warns you about

A loop with no stop rule is a resource sink, not an agent. Termination logic is not a finishing touch — it’s a first-class design requirement. Decide up front what “done” means, what the maximum iteration count is, and what happens when neither is reached. The default failure mode of an autonomous loop is not crashing; it’s running forever.

Retrying the same action after the same error is spinning, not iterating. A loop that hits an error and tries the identical approach again has learned nothing. Design it to distinguish recoverable errors (a syntax slip, a missing import) from hard blockers (missing credentials, undefined behavior) and to actually change its approach — or escalate — rather than repeat itself.

No memory between runs means every run starts over. Without external state — a file, a board, a database row — each run is a stranger to the last. Persistence is what turns a sequence of one-shot attempts into a system that makes progress.

The evaluator is where your effort should go, not the generator. It’s tempting to spend your time making the agent smarter. The higher-leverage work is making the verifier sharper, because the verifier is the ceiling on everything the loop can produce.

Most tasks don’t need a loop yet. This is the contrarian one. For a one-off job, an interactive session with a capable agent is usually faster than building and babysitting a loop. Loops earn their complexity on recurring, well-scoped, verifiable work — PR reviews, dependency updates, test triage — not on everything. Reaching for a loop by default is its own failure mode.

The one principle: automate the generating, own the judging

The agent runs the inner loop; you own the outer one. That’s the whole discipline in a sentence. Hand the model the repetitive generation — the drafting, the fixing, the trying-again — and keep for yourself the two things that actually determine whether the loop is worth running: what counts as done, and whether the work is any good. Loop engineering isn’t about making agents more autonomous for its own sake. It’s about moving your attention up a level, from writing the prompt to designing the system that decides when to stop and who gets to say the result is correct. Get the stop rule and the verifier right, and the rest of the loop mostly takes care of itself.