Four kinds of work sit behind any agent, and each has a name that sounds harder than the thing it describes: prompt, context, loop and harness engineering. This note is about loop engineering. The other three have notes of their own, and they can be read in any order.
Picture sending a friend to the shop for you. How you word the request is prompt engineering. What you send with them — the list, the money, a photo of the empty fridge — is context engineering. What they do when the shop has no milk is loop engineering. The bag, the bus fare and the rule about how much they may spend is harness engineering.
So: what happens when the first attempt does not work. Your friend gets to the shop and there is no milk. Nobody briefed them on this. They check the next aisle, work out whether oat milk counts, and call you if it does not. That small sequence — try, look, decide, go again — is so ordinary in a person that it is easy to forget it has to be built deliberately in software.
In short
- What
- The cycle of act, look at the result, judge it, adjust, repeat — plus the rules for when to stop, and who to ask.
- Why
- First attempts are often close and rarely right. Something that can check its own work gets most of the way there without you watching.
- When
- When the job has steps, when a result can be checked against something real, or when the next move depends on what just happened.
- How
- Decide what “done” means before the loop starts, give it a hard limit, and make stopping to ask an ordinary outcome rather than a failure.
What a loop is
Act, look at what came back, judge whether it is good enough, adjust, go again. Four steps, and the one people leave out is the third.
That matters more than it sounds. A system that repeats without judging is not looping, it is just doing the same thing more times. The judging step — the check — is what turns repetition into progress. Everything interesting about loop engineering is really about that check: what it measures, how cheap it is, and whether it can tell good from merely finished.
Learning to ride a bike is the honest version of this. Nobody rides in a straight line on the first go. The skill is not balance; it is the wobble, the correction, the next wobble being smaller.
Why the first attempt is rarely the last
Real jobs have steps, and most of them cannot be planned in full from the start, because some of what you need to know only appears once you have begun. You do not know the shop is out of milk until you are standing in the aisle.
A single answer has to commit to everything at once: the plan, the details, the judgement about whether it worked. A loop gets to be wrong cheaply and early, then fix it. That is a much better deal, and it is the difference between a system that needs you watching every step and one that comes back when it is genuinely stuck.
There is a quieter benefit too. A loop leaves a trail. When the answer is wrong you can see which attempt went astray and why, instead of staring at one final paragraph with no history behind it.
When you reach for it
When the job has more than one step. When the result can be checked against something real — does the code run, does the address exist, does the total add up, does the field match what the owner actually wrote. When the next move genuinely depends on what just happened rather than being known in advance.
And just as importantly, when not to. A single question with a single checkable answer does not need a loop; wrapping one around it adds time, cost and new ways to fail while the answer stays the same. A loop with no meaningful check is the worst of both — it burns attempts and calls the last one success.
If you cannot describe the check in a sentence, you probably do not have a loop yet. You have a repeat.
How to build one
Write down what “done” means before the first attempt, in terms someone else could verify. Everything after this is easier once that sentence exists.
Make the check cheap and specific. Running the code beats asking whether the code looks right. Comparing against the source beats asking whether the summary seems fair. The more the check leans on something outside the model’s own opinion, the more it is worth.
Give the loop a hard limit — a number of tries, a budget, a clock — and decide in advance what happens when the limit is reached. Not “keep going”, and not silence. Something definite.
Keep a record of what has already been tried and feed it back in, or the loop will cheerfully attempt the same failing thing five times. A note on what did not work, and why, is usually the most useful thing in the bag on the second pass.
Finally, make asking a person an ordinary outcome. A loop that stops and says “I cannot tell whether this deposit was mentioned, can you check” is working correctly. Treat that as a normal ending, not an error, and the whole system gets more honest.
The two ways it goes wrong
It gives up too early, returning a half-finished answer as though it were complete. Or it goes round and round with total confidence, making small changes to something that was never going to work, until the budget runs out.
Both look like model problems and are almost always loop problems: the first has too weak a definition of done, the second has no honest check and no exit.
Where it stops
A loop can only try things it is able to try. If an attempt needs a file it cannot open or a service it cannot call, no amount of looping helps — and if it can call something it should never have been allowed to touch, looping makes that worse rather than better.
That is harness engineering, the one everything else stands on.
