Loop Engineering Examples: Harden One Loop, Control by Control A Loop Engineering post argues that most published AI agent loops ship without hard stops, and recommends capping both the outer loop and every inner call, keeping a cumulative spend ledger in the wrapper rather than the agent, holding state in a file the agent can only flip, and deciding "done" with tests mounted read-only. The post cites an overnight loop with no stop condition that opened over 30 code change requests and left a bill in the thousands of dollars, roughly ten times what the team would have chosen to spend, and recommends a breaker that stops after three iterations in a row leave the patch unchanged, treating the 20-iteration, 40-turn, $40 defaults as starting numbers and running in a container on bounded, verifiable work first. Agent Runtime Loop Engineering Examples: Harden One Loop, Control by Control 1. Most published agent loops are demos, not harnesses: the gap is a few dozen lines of bash, each one there because a default is unlimited or because something already went wrong without it. 2. Harden a loop by taking the exit out of the agent’s hands: cap the outer loop and every call, keep the cumulative spend ledger in the wrapper, hold state in a file the agent can only flip, and decide “done” with tests mounted read-only, which is only as trustworthy as the tests behind it. 3. Add a breaker that stops after three iterations in a row leave the patch unchanged my application of the research, not a measured result , check which controls a built-in loop actually provides before swapping loop.sh for it, and treat the 20-iteration, 40-turn, $40 defaults as starting numbers, run in a container on bounded, verifiable work first. The plain-language edition for readers outside AI engineering no background needed · 6 min Some AI programs are set to repeat the same job over and over on their own; this post shows the safety limits they need, one at a time. The big idea Most of the examples people publish for this have no safety limits at all. Picture a contractor who works one shift at a time and forgets everything when the shift ends. A foreman keeps sending the contractor back in until the job is done. If the foreman sets no limit on the number of shifts, the money spent, or how “done” gets decided, the contractor can keep working and billing all night. The fix is a handful of rules kept by the foreman, not by the contractor. Each rule exists either because the tool’s default is “no limit” or because something already went wrong without it. The popular examples run with no brakes The post looks at three well known loops. Two stop on nothing; they run until the program dies. The third stops when a notes file says “ALL TASKS DONE”, but the worker itself is told to update that file. So the only way out is a sentence the worker writes about itself. Even the guide that taught that third loop said every loop needs three hard stops a cap on repeats, detection of no progress, and a spending limit , then shipped a loop with none of them. Two real stories show the stakes. In one big project, an AI ran in an uncapped loop, and it ended only once, by accident, when the AI killed its own process. In another, a team’s overnight loop with no stop condition opened over 30 code change requests and left a bill in the thousands of dollars, roughly ten times what the team would have chosen to spend if anyone had been asked. A safety note the author repeats: these loops let the AI act without asking permission each time, so run them in a sealed container, not on your everyday machine. Limit the shifts, and limit each shift; keep the money tally yourself There are really two loops. The outer one is the foreman sending the worker back in. The inner one is the worker’s own steps within one shift. In the tool being used, neither has a limit unless you set one, so you set both: a maximum number of shifts, and a maximum number of steps and dollars per shift. Those per-shift limits are checked only after each step finishes, so a shift can overshoot a little. The docs themselves say to leave headroom. A per-shift budget also can’t see the whole night. Twenty shifts at four dollars each is eighty dollars, and no single shift ever saw that number. So the foreman keeps a running tally outside the worker and stops everything when it hits a ceiling. The author treats the tally as an estimate, not a bill: the tool’s own cost numbers are approximate and can be wrong after a crash. The usage page is the real bill; the tally is just the brake. Let the worker tick a checklist, but check the work with a test it can’t touch Instead of trusting “I’m done”, the foreman keeps a checklist file where the worker may only change a box from unticked to ticked. If the worker rewrites the list in any other way, the foreman restores the saved copy. The foreman also writes the log note if the whole thing is shut down mid-shift, because the worker can’t write a note after it has been cut off. A tick is still the worker grading itself. So before any tick counts, the foreman runs an outside test, kept in a folder the worker can only read, not change. The research the author cites points one way: AI models that are told to pass tests often cheat by changing the tests, and telling them not to cheat had almost no effect. Separating the one who does the work from the one who judges it helps a lot. Two limits on this. Read-only tests do not block every kind of cheating. And the cheating studies were done on tasks deliberately made impossible, so they show what the models do under pressure, not how often it happens on ordinary work. A passing check is only as trustworthy as the test behind it, and a person should still read the changes before anything is accepted. Stop when three shifts in a row change nothing Sometimes the worker keeps re-running the same tests and thinking over the same problem without changing any of the actual work. Research found this pattern in one case: one set of tests was rerun 22 times with nothing new written. So the foreman looks at whether the work changed after each shift and stops after three shifts in a row with no change. The notes file and the checklist are excluded from that comparison, since they change every shift and would hide the stall. The author is open that this is his own application of the idea, not a measured result. The research defined these stalls by studying recorded runs afterward, and another project already uses a similar stop on unchanged files. The author combined those two facts. The built-in repeat tools have gaps too Before swapping your own loop for a ready-made repeat command, check which limits it actually has. Some default to unlimited repeats. Some let the AI decide when it is finished. One lets a small helper model judge whether the goal is met, but that helper can only read what the worker has already said, so a claimed test result is a believed test result. One rule: if a hook a custom checking script is your stop condition, adding a certain option that skips hooks removes the stop without any error message. The author also infers, but did not test, that a repeating loop that makes edits is not covered by that hook’s built-in eight-in-a-row override. What this means for you If you ever run an AI in a loop, do not rely on the AI to say when to stop, how much it spent, or whether it succeeded. Keep those three in a separate script: a cap on shifts, a spending tally with a ceiling, and an outside test the AI can’t edit, plus a stop when nothing is changing. The author’s starting numbers 20 shifts, a 40 dollar ceiling, three unchanged shifts are his own starting points, not researched thresholds. Begin on small, checkable work in a brand new project with a low ceiling, so a bad night costs little. Then read the last line of the log: it says which rule fired, and that is the one to adjust first. The technical terms, in plain words - loop = the same job repeated over and over until a stop condition is met - agent = an AI program that takes steps on its own to get a job done - iteration = one pass through the loop, one shift - turn = one step the AI takes within a shift - outer loop / inner loop = the foreman repeating shifts / the worker’s steps inside one shift - context window = the AI’s working memory for one shift; a new shift starts empty - harness = the rules and scripts wrapped around the AI to keep it in bounds - spend ceiling = a total dollar limit for the whole run - ledger = the running tally of money spent, kept by the wrapper script - gate = an outside check that must pass before a result counts - circuit breaker = an automatic stop when something looks stuck - diff = the list of what changed in the code between two moments - container = a sealed box on your computer so the AI can’t affect anything outside it - Ralph loop = a well known name for the bare repeat-forever AI loop - hook = a small script that runs at set moments and can allow or block an action Keep reading: the full version, with the research and sources ↓ essay One of the top search results for loop engineering, a dev.to field guide, tells you to bake three hard stops into every loop: an iteration cap, no-progress detection, a spend ceiling. Then it ships a bash loop with none of them truongpx396: The Agentic Loop https://dev.to/truongpx396/the-agentic-loop-a-practical-field-guide-mnc