Loop engineering

What is loop engineering?

Loop engineering is designing the loop around an agent instead of the prompt inside it: what makes the agent run again, what it sees when it does, what it may spend, and what evidence has to exist before the run counts as finished.

The distinction that gives the term its meaning is between two loops. The inner loop is the model calling a tool, reading the result and choosing the next step. That is the agent loop, and it mostly works: the SDKs handle it for you. The outer loop sits one level above and decides whether the inner loop runs again, with what context, under what budget, and when it stops for good.

Addy Osmani put it in one line in June 2026: loop engineering is replacing yourself as the person who prompts the agent, and designing the system that does it instead. If you sit there reading output and typing "no, try that again", you are the outer loop. Loop engineering is writing down what you would have said.

The parts you design

The stop condition. The hardest part and the one most often skipped. A run has to end on something, and the default is the model producing a turn with no tool call in it, which is its own opinion that it is done. Write the stop condition before the prompt: what has to be true for this run to be over? If you cannot answer without using the word "good", you do not have one yet.

The check that tests it. The stop condition is the statement, the check is the code that evaluates it, and what matters is where the check lives. An instruction telling the agent to verify its own work is a suggestion. A script your harness runs after the agent stops, whose exit code decides whether the agent gets called again, is a stop condition.

What carries over between iterations. The naive outer loop appends everything, so by the fourth pass the model is mostly rereading its own dead ends. Anthropic's September 2025 write-up on context engineering names three ways out: compaction, which summarises the run and restarts from the summary; note-taking to a file outside the context window; and sub-agents, which get a clean window and hand back a short summary. Their reason is context rot, the drop in a model's recall as the window fills. What the next pass needs is the goal, the current version of the work and the failures, not the transcript.

A budget in steps, tokens or money. The agent loop entry covers the caps the SDKs put on a single run. The outer loop needs its own on top, because it can start the inner loop many times over. Three to five outer passes before a person looks at it is a sane default. A loop still failing after five attempts is circling rather than converging, and the sixth costs the same as the first.

An escape hatch to a person. Microsoft's Agent Framework treats stopping as its own layer, with middleware that ends a run before the model is called or after it has answered. Their documentation carries a warning worth copying: terminate in the middle of a tool call and the history can end up holding a call with no result, which breaks the next run that reads it. Decide what the agent leaves behind when it gives up, a file of failing rows or a ticket with the last error and its input. "It stopped" is not a handover.

A cleaning loop with a real stop condition

A wholesaler gets a price file from its largest supplier every morning: 4,200 article lines plus a summary line with the supplier's own total. Four rules have to hold before it goes into the ERP. Every article code exists in the internal code list, every price parses as a number in euro, no code appears twice, and the file total reconciles to the cent with the supplier's. Those four rules are a validation script, and the script is the stop condition: zero rejected lines and a reconciled total.

The loop is short. Run the script. If it passes, load the file. If it fails, hand the agent the rejected lines with their error text, let it correct them, run the script again. After five passes, or if two passes produce the same failures, write what is left to a file and mail the purchasing clerk.

A normal morning takes three passes: 180 rejected lines to start, mostly comma decimals and two codes the supplier renamed, then 25 left, then the last three and the total reconciles. Each pass sends the standing instructions, about 2,000 tokens, plus the rejected lines and their errors at roughly 40 tokens a line, so the three together come to some 14,000 input and 4,000 output tokens. At the going rate for a mid-range model, around two dollars per million tokens in and ten per million out, one morning costs under ten cent and a year of them stays under twenty euro. The clerk used to spend twenty minutes a morning on that file.

Now the version where nothing gets thrown away. Send the whole file back on every pass and each one carries about 170,000 input tokens instead of 9,000, so three passes is half a million tokens and a euro a day before you count output. Same result, fifteen times the bill, and a model reading 4,200 lines to fix three of them.

A mechanical stop condition versus the model's own verdict

Both loops end. The dimension that separates them is what evidence ends the run.

A mechanical stop condition ends the run on something outside the model: the tests pass, the file validates, the row count matches the source, the invoice balances. The evidence is an exit code or a number, it comes out the same every time, and it holds up in front of an auditor. Its limit is that somebody had to write the rule, so it only covers what the rule covers. A file can validate perfectly and still hold last week's prices.

The model deciding it is finished ends the run on a judgement it makes about its own work, and the evidence is a sentence saying so. It stretches to anything, which is the appeal, and it is the same instrument grading itself, which is the problem. Osmani's phrasing is hard to improve on: the model that wrote the code is far too nice grading its own homework.

So use a mechanical condition wherever one can be written, and where you fall back on a model's judgement, hand it to a second agent with different instructions and a fresh context.

What to watch out for when you build a loop

The loop declares victory. The run ends on a confident summary of what was accomplished and nothing compared that summary to the result. This one costs the most, because it looks exactly like success and surfaces weeks later in a report that does not add up.

The loop never stops. When the stop condition is a judgement the model makes about itself, it tends to be either always true or never true. Either the first attempt passes and the loop was decoration, or nothing satisfies it and the run goes to the cap. Same design error, opposite symptoms.

The loop repeats the same failing action. Inside one run this is about tool error messages, which the agent loop entry covers. Across passes the outer loop has to notice it: compare this pass's failures with the last, and if they are identical, do not send the same context back. Change the approach or escalate. Nothing new going in means nothing new coming out.

What a loop cannot fix

Loop engineering does not make a model capable of something it cannot do. It converts a capability that works sometimes into one that works reliably enough to leave running.

The research is blunter than the marketing. Researchers at Google DeepMind and the University of Illinois gave their 2024 paper the flat title "Large Language Models Cannot Self-Correct Reasoning Yet". They tested the version everybody assumes works: let the model review and revise its own answer with nothing else to go on. Performance did not improve, and often got worse. Among the answers the model changed, it was more likely to turn a right one into a wrong one than the other way round. Correction with feedback from outside the model did work. That result is the argument for building the outer loop out of checks rather than out of instructions to reflect.

Which gives the counter-example. Loop the rewrite of a supplier reminder mail: the agent drafts, grades its own draft, revises, five times over. What comes back is longer, more hedged and further from what you meant, and you have paid for five drafts where one would have done. There was no score, so the loop had nothing to climb towards.

Two questions decide whether a loop is worth engineering. Can a machine tell you the answer is right? And does the job run often enough to pay back the day you spend building it? A daily price file with a control total says yes twice. A yearly filing that one person checks in ten minutes says no to the second, whatever the check looks like.