Loop Engineering: What it is, How it Works

Why loops are possible now

The idea of an agent running on its own until a condition is met isn't new. What's new is that it works reliably enough to build products on. That reliability needed three things to come together at roughly the same time.

Models that can check their own work

A loop only works if the agent can honestly judge whether its output meets the standard you set. Earlier models would give wrong answers confidently, with no way to catch the mistake. Andrew Ng named this problem explicitly around 2024: GPT-3.5 was too unreliable to run unsupervised across multiple attempts. Errors built up instead of getting fixed. GPT-4 and Claude 2 crossed a line where self-evaluation became reliable enough to act on. Current models are meaningfully better still.

Tool use

Without tools, the only thing a model can check is its own text output. That's a weak signal. With tools, the check can be concrete: run the tests, did they pass? Read the error message. Check the file. Tools like Bash, pytest, the GitHub Actions runner, and file read/write give the loop a binary signal (pass/fail, exists/missing, 200/500) that a model can act on without guessing. Models started being able to use tools reliably through 2023 and 2024.

Long context windows

A loop needs to remember what happened across attempts: what it tried, what failed, what the error said. At 4k-8k tokens, that's impossible across more than a couple of cycles. At 100k-200k tokens, it's routine. Context length grew alongside the ability to reason reliably over long sessions.

Boris Cherny built Claude Code as a loop. The product exists because the model crossed the reliability line. Andrew Ambrosino's path from Copilot (autocomplete) to Codex (an agent that codes on its own) tells the same story from OpenAI's side. Andrew Ng framed it as a capability unlock: the bottleneck was never the idea of a loop. It was whether a model could be trusted to run one without a human stepping in every time.

All three came together around 2024 and 2025. The builders are naming this pattern now because it's only been reliable enough to ship on for about 12 to 18 months.

Start with what you already know

A prompt is a single instruction. You send it, the model responds, you review it and decide what to do next. Every attempt runs through you.

A workflow is a set sequence of steps across one or more agents. You decide who does what, in what order, and what gets passed between them. A research agent finds sources. A writer agent drafts. An editor agent revises. A publisher agent posts. The sequence is fixed. Each agent has a role. The handoffs happen in the order you designed.

A loop is different. The agent acts, checks its own output against a standard you set, and decides what to do next, without you in the middle. You don't know how many tries it'll take. The agent determines that at runtime, based on the check you gave it.

I run them constantly. Build the feature, update the docs, write the tests, push. The check is CI. The agent reads each failure and decides what to fix next.

A concrete example

Here's the same task expressed three ways.

How multi-agent workflows and loops relate

This is where people get tripped up, because the two ideas aren't opposites. They describe different things.

Multi-agent describes the actors: how many models are running, what roles they have, and how they work together.

Loop describes the control flow: whether the system runs once or repeats until a condition is met.

A multi-agent workflow can have loops inside it. Each agent in the workflow might loop on its own before handing off to the next. A loop can use multiple agents. A coordinator might spin up a sub-agent on each attempt, collect results, check them, and decide whether to loop again.

The real distinction isn't "loop vs. multi-agent." It's between a fixed sequence you designed upfront and a cycle the agent runs until a condition is met. In a workflow, you designed every handoff. Your design holds the intelligence. In a loop, the agent decides whether to keep going based on a check. The intelligence is in the standard you gave it and the agent's ability to apply that standard honestly.

Designing a loop: three things you must define

A loop without clear specs doesn't save you work. It multiplies vague work.

A vague outcome produces vague software, just faster. A missing check means the agent can't correct itself. A missing stopping condition means you'll find out the hard way why it matters.

The check is the hard part

Most people focus on writing the task. The check is where loops actually fail.

A weak check gets gamed. An agent told to make tests pass can delete the tests. An agent asked "does this look good?" will find a way to say yes. A vague check gives the agent an easy out on every attempt, and it will take it.

A strong check is specific, external where possible, and hard to pass without actually doing the work. A real test suite gives you a binary result. An API call either returns 200 or it doesn't. Asking a second model "does this read naturally?" is weaker unless you give it a rubric. Without one, it will find a way to say yes.

The quality of your loop is the quality of your check. If you spend 80% of your design time on the task and 20% on the check, you've got the ratio backwards.

When to use a loop

Loops are the right tool when the task has an outcome you can actually check, you don't know how many tries it'll take, and one attempt probably won't get you there.

• Code refactoring with a test suite. Refactor each file, run the tests, fix what fails, continue. The check is concrete and external. You won't know how many failures there are until the agent finds them.
• Security vulnerability scanning. Scan each file, verify each finding is real, loop until all files are covered. The verification step weeds out false alarms automatically.
• Data cleaning. Process records in batches, check each batch against a set of rules, retry the ones that don't pass. The loop handles messy data without you having to touch each record.
• API integration development. Write the integration, call the real API, read the actual error, fix it, try again. The API response is a perfect check: it either works or it doesn't.
• Documentation with a completeness check. Generate docs for each function, check that every parameter is described and every example compiles, loop on the ones that don't pass.

When not to use a loop

Loops add cost and time. They're overhead when one attempt is good enough.

• Simple, predictable tasks. "Translate this paragraph to French." There's no meaningful check to run and no reason to retry. A loop here just wastes money.
• Subjective tasks without a rubric. "Write me a tagline." There's no external signal that tells the agent whether it succeeded. The human review is the check, which means a human should be in the loop, not just the model.
• Tasks where the check costs more than a human review. If verifying the output takes more effort than just looking at it yourself, the loop isn't saving you anything.
• Time-sensitive tasks. If a user is waiting for a response, multiple attempts aren't an option. Design for one-shot quality instead.
• Tasks with no clear definition of done. If there's no finish line the agent can recognize on its own, it'll run until it hits the stopping condition, not until it succeeds. You get a result, but not necessarily a good one.

Cost is a stopping condition too

Every attempt costs tokens. A loop that runs 20 times costs roughly 20 times what a single prompt costs, plus the overhead of the check on each cycle.

That doesn't mean loops are expensive overall. For tasks that would require 10 rounds of human review anyway, a loop that runs 8 times on its own and delivers a working result is cheaper in the end. The math depends on what your time is worth.

But cost needs to be an explicit stopping condition in your design, not something you discover after the bill arrives. Set a maximum attempt count. Set a token limit if your framework supports it. Know what an unconstrained loop would cost if it never finished, and decide whether that's acceptable before you run it.

A loop that can run forever is a loop that was never fully designed.

Log everything

A loop running without you means you need logs. If you can't see what happened on each attempt, you can't debug it when something goes wrong, and something will go wrong.

At minimum, log the input and output of each attempt, the check result, and the reason the loop continued or stopped. That's enough to understand what happened and find where it broke.

Most people skip this until a loop runs 40 times and they can't figure out why. Don't skip it. Adding logs before the first run takes almost no time. Debugging a black-box loop after the fact takes a lot.

Logs are also how the loop gets better over time. If you can see which attempts fail and why, you can tighten the outcome definition, sharpen the check, and adjust the stopping condition. A loop with good logs improves. A loop without them keeps failing in the same ways.

How much human review do you need?

Loops aren't all-or-nothing. There's a spectrum.

Where you land depends on how much you trust the check, how costly a bad result is, and how much your time is worth. Most production loops sit somewhere between the third and fourth options: human review on the final output, full autonomy in between.

If few-shot prompting is better than zero-shot, why do loops work?

It looks like a contradiction. Few-shot examples make the first attempt better. A loop doesn't care about the first attempt. It cares whether the check passes.

They're not in conflict. Examples reduce ambiguity before the model starts, but they're written once and have to predict every way the output could go wrong. For complex tasks, that's impossible. The check fills the gap: it gives the model specific feedback after each attempt, on what it just produced. "Your output failed test 4 with this error message" is more useful than any example written in advance, because it's about the actual output, not a hypothetical one.

Use both. A few-shot prompt inside a loop gets to a passing result faster. Zero-shot still gets there, just with more cycles.

Why this shift matters

Think about what each pattern asks of you. With prompting, it's clear instructions. With workflows, it's good pipeline design. With loops, it's a good spec: tight outcomes, honest checks, sensible stopping conditions.

The model is a worker with a job spec now. You write the spec. It does the work and decides when it's done.

That's what the three builders are pointing at. Not a new tool. A new layer. And a new place where being vague costs you.