Loop Engineering

Loop engineering is the discipline of designing the repeated structure itself when AI performs the same process more than once — how much a single iteration should accomplish, when to stop, what carries over to the next iteration, and how much time to leave between iterations.

Why Loop Engineering Is Needed

Harness engineering sets up the tools, permissions, verification, and logging available to AI within one execution. But most real work does not finish in one execution. Fixing code until tests pass, addressing review comments until none remain, waiting and retrying until a condition holds — this “repeat until done” class of work needs a design decision that harness engineering does not cover.

graph LR
    Prompt["Prompt Engineering\nWrite clear instructions"]
    Context["Context Engineering\nSupply needed information"]
    Harness["Harness Engineering\nDesign execution, verification, and recovery"]
    Loop["Loop Engineering\nDesign the repeat structure"]

    Prompt --> Context --> Harness --> Loop

Where a harness decides what is available within one execution, a loop decides how many times, and how, that execution repeats. Running a loop without a harness means unverified results pile up on every pass. Setting up a harness without loop design means work that does not finish in one pass has to be re-invoked by hand every time. Both together are what let work spanning multiple iterations be automated safely.

Anthropic lists workflow patterns such as the “evaluator-optimizer” — generating and evaluating output repeatedly to refine it — among the basic building blocks of agent design.[1] The ReAct loop that AI agents use, which repeats reasoning, acting, and observing, is likewise a form of the repeat structure that loop engineering addresses.[2]

Four Decisions Loop Design Makes

Scroll horizontally→

Decision	Question
Granularity	How much should a single iteration accomplish
Exit condition	When to stop (done, ceiling, no progress)
Carried-over state	What passes to the next iteration, and what gets dropped
Pacing	How much time to leave before the next iteration

This table scrolls horizontally. Keyboard users can focus the table and use the left and right arrow keys.

1. Set the Granularity

An iteration that is too large makes it hard to see where a failure happened. One that is too small piles up round-trip cost on every pass. Scope each iteration to a single checkable unit — “fix one failing test,” “resolve one review comment” — rather than an open-ended chunk of work.

2. Set the Exit Condition

Combine at least two kinds of exit condition.

• Completion condition — a criterion for judging the goal achieved (all tests pass, zero comments remain)
• Ceiling — a criterion for stopping even without completion (iteration count, elapsed time, cost)

A completion condition alone never stops iteration toward a goal that cannot be reached. A ceiling alone can cut work short even when it is actually done. Combine both, and once the ceiling is hit, stop automatically and hand off to a human rather than continuing.

3. Decide What State Carries Over

Carrying everything forward on every iteration reproduces the same problem covered in Why Quality Degrades in Long Conversations. What should carry over is the essential point — what was tried last time and what happened — not the full history of trial and error.

Example handoff into iteration 2:
Previous change: set config.json's timeout value to 30
Result: tests A and B now pass; test C still fails (error: connection refused)
Next to try: check the connection settings that test C references

4. Set the Pacing

The interval between iterations should match how fast whatever it is waiting on actually changes. Watching for a file change can use a short interval; waiting for an external service to finish deploying calls for an interval matched to how long that process typically takes. Always using the shortest interval means repeatedly checking something that has not changed.

When Iteration Does Not Converge

The most dangerous state in a loop is iterating without any detectable progress. Repeating the same error, or oscillating between fixing one thing and breaking another, will consume time and cost until the ceiling is hit if left unchecked.

The countermeasure is comparing each iteration’s result against the previous one to judge whether progress occurred.

• Is the same verification failure showing up again
• Did something that was fixed break again
• Is the gap actually shrinking across iterations

Once a run of iterations shows no detectable progress, switch away from repeating the same approach — toward the “change what you’re targeting” judgment covered in Self-Correction and Reflection — or stop iterating and hand the decision to a human.

Summary

• Loop engineering designs the repeat structure itself when AI performs the same process more than once
• A harness sets up one execution’s environment; a loop decides how many times, and how, that execution repeats
• It sets four things: granularity, exit condition, carried-over state, and pacing
• Always combine a completion condition with a ceiling, and stop for human judgment once progress stalls

Frequently Asked Questions

Q: Is loop engineering the same thing as self-correction (reflection)?

A: No. Self-correction covers what happens inside one iteration — what evidence verifies the result, and how the approach gets adjusted. Loop engineering covers the structure outside that iteration — how many times it repeats, how far, and at what pace.

Q: What should the iteration ceiling be set to?

A: There’s no fixed answer. Set it based on the task’s complexity and the cost of a single iteration, starting with a smaller ceiling and adjusting it as you observe real results.

References

1. Anthropic, Building Effective Agents
2. Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models