Designing agent loops that don't spiral out of control

The first version of any agent loop looks great in a demo. Give it a goal, a handful of tools, and a while loop, and it'll happily chain together plans that look almost thoughtful. Then you point it at a real task with real edge cases, and it starts calling the same tool ten times in a row, or burns through a week's API budget in an afternoon chasing a goal that was never quite well-specified.

The fix isn't a smarter model — it's guardrails you'd never think to add until something has already gone wrong once. A hard cap on steps. A hard cap on tool calls, per tool and in aggregate. A wall-clock timeout that kills the loop regardless of how close it thinks it is to done. These aren't nice-to-haves you bolt on later; they're the difference between an agent that fails loudly and cheaply, and one that fails expensively and quietly.

Stop conditions deserve just as much care as the guardrails. "Keep going until the goal is met" is not a stop condition, it's a wish. I check explicit, checkable success criteria after every step, and I treat "I'm not confident this is done" as a legitimate, first-class outcome — not a failure to be retried into oblivion.

None of this matters if you can't see what the agent actually did. Every step, every tool call, every decision gets logged in a form a human can skim in under a minute. When something goes wrong — and it will — the transcript is the only thing that turns "the agent did something weird" into an actual root cause.

It's not glamorous work, and none of it shows up in a demo video. But it's the difference between an agent loop you can hand real responsibility to, and one that stays an impressive toy forever.