Loops that know when to stop

Every agent is a version of four lines:

while not done:
    action = model(context)
    result = run(action)
    context = context + result

The interesting engineering is not in the loop body. It is in the word done.

The two ways done goes wrong

An agent stops too early or it never stops.

Stopping early looks like success. The agent announces it fixed the bug, and the bug is still there because nothing checked. The fix is a step the agent cannot skip: a test run, a build, a second pass that has to agree before the work counts as finished. In our review workflows a task is not done when the implementer says so; a separate reviewer has to sign off on the same diff.

Never stopping is quieter and more expensive. An agent that polls a background job every few seconds spends a turn on each check and learns nothing new. The better shape is to let the work announce its own completion and keep one long fallback check in case it hangs. Remember that a loop’s cost is counted in turns, not tokens: a cheap model that takes three times as many turns is not cheap.

Pacing is part of the design

When the agent is waiting on something outside itself, a CI run or a deploy, match the check interval to how fast that thing actually changes. An eight-minute CI run wants one look at eight minutes, not eighty looks at six seconds.

Any harness can run the loop. Getting done right is what lets you hand an agent a job and walk away, instead of sitting next to it watching every step.