The Real Work of Loop Engineering Is the Stop

Loop engineering, agent loops, and the quiet discipline of designing exits.

Every loop you build will eventually try to run forever.

The agent reads its goal, calls a tool, and the tool breaks in a way nobody planned for. It tries again. In one Oracle writeup, an agent with no hard stop called a broken scraper four hundred times in five minutes before a platform rate limit ended the spree. A maximum of three iterations would have killed it on contact.

Loop engineering is sold as the craft of making agents run. The part that pays rent is the part that makes them stop.

The story being sold

The field arrived with a clean slogan, and the slogan points one direction. Addy Osmani frames loop engineering as replacing yourself as the person who prompts the agent, then designing the system that does the prompting for you. Boris Cherny at Anthropic says it from the inside, that he no longer types at Claude turn by turn and instead writes loops that decide what to do next. Peter Steinberger puts the same thought in the imperative, that you should be designing the loops that prompt your agents rather than prompting them by hand.

Every version of the pitch faces outward. More autonomy. More sub-agents. More work discovered, assigned, and shipped while you sleep.

Read those lines again and notice the buried assumption. The interesting engineering lives in the going.

It does not.

Motion is not progress

A loop has two failure modes, and the conference talks only cover one.

The first is the loop that quits too early, before the work is finished. Everyone builds for this one. They add retries, fallbacks, and fatter budgets so the agent muscles through the next obstacle.

The second is the loop that will not quit at all. This is the costly one. A flaky tool returns a timeout, the agent reads the timeout as "try harder," and now you own a slot machine wearing a trench coat of JSON. As one engineer put it after watching a runaway cycle, the agent is not broken. It is obeying.

Here is the arithmetic nobody wants on the slide. Agents already burn close to four times the tokens of a plain chat exchange, and multi-agent systems push that toward fifteen times, per Oracle's measurements across the teams it works with. A loop with no brake does not waste a little money. It compounds.

The bill for a missing stop comes due in four currencies:

• Token spend that grows with every confused turn, because the transcript of the confusion becomes the prompt for the next one.
• Comprehension debt, the widening gap between what the loop shipped and what any human on the team has read.
• Silent wrong answers, where the agent declares victory on a goal it never met and logs a cheerful success.
• Trust erosion, because a single runaway run teaches a whole team to hover over every future one.

The artifact you under-build

Ask an engineer to show you their loop and they show you the orchestration. The dispatcher. The sub-agent fan-out. The retry policy. Everything that moves.

Ask to see the termination logic and you get a shrug, or a lone max-iteration cap bolted on after the demo worked.

That cap is not a strategy. It is a smoke detector. Good loop design treats stopping conditions as first-class requirements rather than afterthoughts, which means the exit is not the thing you sprinkle on at the end. The exit is the design.

The people who build agent runtimes already know this. Every run of the Claude Code SDK ends with a result object carrying a stop_reason, an explicit record of why the model stopped, whether it ended its turn cleanly, hit a token ceiling, or refused. The runtime treats the reason for stopping as a primary output, not a footnote. Your loop deserves the same respect for its own ending.

Three stops, not one

Most builders model a single exit, the one labeled "task complete." A serious loop models three, and they are not interchangeable:

• Done. The goal carries a testable definition of success, and the loop can prove it cleared that bar. No test, no done. A loop that cannot check its own work will always think it is winning.
• Stuck. The loop notices it is repeating itself, calling the same tool with the same arguments and harvesting the same failure, and it refuses to keep paying for an identical mistake.
• Boundary. The loop reaches the edge of its authority. It pauses, not because the work is finished, but because the next decision belongs to a person.

That third stop is the one teams skip and the one that earns the most. Oracle's engineers describe human-in-the-loop not as a net for when the agent fails but as a deliberate choice about where human judgment buys the most leverage in a system. A loop that hands off well is not a weaker loop. It is a designed one.

And the handoff carries a quality bar. A vague "I need help" wastes the whole interruption. The agent has to name the exact decision or fact that blocks it, so the human spends ten seconds rejoining context rather than ten minutes reconstructing what went wrong.

How to engineer the brake

Start from the skeleton, not the prose. A loop built to stop on purpose has these bones:

• Write the success test before the first prompt. If you cannot phrase "done" as something a script can check, you have given the loop a direction and called it a target.
• Cap the cheap way and the smart way. Keep a hard iteration ceiling as a fuse, then add cycle detection so the loop catches itself spinning long before the fuse blows.
• Separate recoverable from terminal. A missing import earns a retry. A missing credential does not. Sort them, or the loop treats every wall as a door it has not pushed hard enough.
• Budget in dollars, not just turns. One auditable research loop injected a single plain sentence into each session, telling the agent it had a fixed budget of experiments and to stop after that, then enforced the count from an outer script. The budget was a sentence and a guardrail.
• Make the stop legible. Log why the loop ended, every time, the way a runtime records a stop reason. A loop that cannot tell you why it quit cannot be trusted when it does.

None of this is glamorous. All of it is the job.

Stay the engineer

The flattering read of loop engineering is that it deletes you from the picture. Build the system, press go, walk away, collect the output.

The honest read runs the other way. The community reference that catalogs these patterns warns that unattended loops make unattended mistakes, that verification still belongs to you, and that two people running the identical loop can land on opposite results because the loop has no idea which one is right. You do.

The research lands in the same spot. A recent roadmap for agentic software engineering on arXiv puts checkpoints for human review at the center of loop design, not out at the margin where convenience tends to file them.

So build the loop. Give it real tools, real sub-agents, and a real budget to do work that matters. Then pour most of your effort into the unglamorous wiring that decides when it is finished, when it is lost, and when the call is yours. The agent worth trusting is not the one that never quits.

It is the one that knows when to stop.