Autonomous loops without burning budget, and the failures that cost real money

An agent that runs on a schedule or loops until a task is done is genuinely useful: monitoring a build, working through a queue, checking for a state change. The work happens without you.

It is also the setup where mistakes are least visible and most expensive. A loop with no stop condition runs until something else stops it. A loop that polls too frequently costs money for nothing. A loop that fails silently produces nothing while appearing to work.

None of these are exotic. All three are the default outcome of setting one up without designing for them.

Define what finished means, in checkable terms, before running anything. 'Until the tests pass' is a condition. 'Until it is done' is not.

Then add a second, unconditional limit — a maximum number of iterations or a wall-clock deadline — that stops the loop regardless. The first condition handles the expected case; the second handles the case where the first can never be satisfied because something upstream broke.

A loop with only the first condition is a loop that runs forever when the world stops cooperating, and that is precisely when nobody is watching.

An eight-minute build checked every thirty seconds is sixteen checks to learn something one check would have told you. The cost is multiplied by every iteration and it buys nothing.

Set the interval from how fast the thing you are watching actually moves. A deploy that takes ten minutes gets one check at nine. A queue that fills hourly gets checked hourly.

Where the harness notifies you when background work completes, do not poll at all — use the notification and keep any scheduled check as a long-interval fallback in case the notification never arrives.

Decide in advance which actions are permitted without a human. A reasonable default: read anything, write within the project, and nothing that leaves the machine.

Publishing, deploying, sending, deleting and anything with an external side effect should require a person — or at minimum should be queued for approval rather than executed.

This is not about capability. It is that an unattended loop repeats its mistakes, and a mistake with an external side effect repeated forty times overnight is a different kind of problem from the same mistake made once.

A loop that only reports when something changes is indistinguishable from a loop that has stopped. By the time you notice, it may have been dead for days.

Have each iteration record that it ran and what it found, even when the answer is nothing. Keep the quiet reports terse so they do not become noise, but make sure they exist.

Then the check is simple and reliable: if there is no report, something is wrong. That single property is what makes an unattended process trustworthy.

1. What stops it? Both the success condition and the hard limit.
2. What does it cost per iteration, and how many are possible? Multiply them. That is the worst case and you should be comfortable with it.
3. What happens if the thing it depends on is broken? It should stop and say so, not retry indefinitely.
4. What is the worst action it can take? If the answer is anything irreversible, restrict it further.

Answering these takes five minutes and is the difference between automation that helps and automation that produces a surprise.