The guarded loop and its guards: Stopping safely

The guarded loop

One loop, with the stop checks in one place

Put every stop condition in one place in the loop, so none can be forgotten and every exit goes through the same ending:

Before each step: has the user cancelled? Is there time left? Steps left? Words (tokens) left?
The model decides the next call, or says it is ready to answer.
Run the tool with a deadline.
After the step: did the same call just give the same result again? Has nothing new been found for several steps?

A run that is ready to answer is always allowed to answer, even at the limit (otherwise a limit of 9 would fail a task that needs exactly 9 steps and one more call to write the answer).

The five guards

Guard	What it measures	Catches	Misses
Step limit	tool steps taken	everything, eventually	nothing, but late; and a limit too low kills good runs
Word (token) budget	text sent and received so far	huge observations, long loops	slow stuck runs with short text
Time limit	wall-clock time for the whole run	slow tools, long loops	fast loops (they take many steps in little time)
Repeat detector	the same call and same result repeating (A A A, or A B A B A B)	loops, thrash, retry storms	wandering, and retries with changing arguments
No-progress detector	steps in a row that add no new information	wandering, jittered retries, all of the above	nothing; but must tolerate healthy waits
Cancellation	a flag set by the user or a supervisor	whatever the user wants stopped	only as fast as it is checked (section 5)

Which guard stops which of nine runs, with only that guard switched on (the number is steps taken when it stopped; "never" means only the test's own emergency stop at 200 steps ended it):

Which guard stops which failure

Run	What it does
normal	needs 6 steps and finishes
poll	after its facts, checks a job status 4 times (the progress text changes each time) and finishes
loop	repeats the same lookup
thrash	alternates between two lookups
wander	keeps trying new ids that find nothing
storm	retries a failing tool, same arguments
jitter	retries a failing tool, a counter added each time
bloat	each result is 1,500 words
slow	one tool call takes 120 seconds

Reading it:

No single guard is enough. The repeat detector never stops wander or jitter (the arguments change); the time limit stops loops only after 20 steps; the word budget is the only one that stops bloat early.
The no-progress detector stops every stuck run in 7 steps, because "nothing new in 5 steps" is the real meaning of stuck.
A step limit is the backstop, not the detector. It always works and it is always late.
The combined default (15 steps, 4,000 words, 90 seconds, repeat of 3, no progress for 5 steps) stops every stuck run within 8 steps and leaves the normal and polling runs alone.

Choosing the limits

A step limit that is too low kills good runs; too high wastes steps on stuck ones. Normal tasks here need 2 to 9 steps; stuck runs make 3 steps of progress and then go wrong:

Step limit	Normal tasks that finish	Steps a stuck run burns	Same, with repeat and no-progress guards
4	38%	4.0	4.0
6	62%	6.0	6.0
8	88%	8.0	7.2
9	100%	9.0	7.2
12	100%	12.0	7.2
25	100%	25.0	7.2
50	100%	50.0	7.2

Raising the step limit

With the step limit alone, every added step of headroom is paid by every stuck run. With the other guards on, the limit can be generous (it only has to be a backstop) because the detectors end stuck runs early.

How to set the numbers:

Measure how many steps, words and seconds your successful runs use (module 7's traces). Take the 95th or 99th percentile.
Set the limit at 1.5 to 2 times that, so normal variation survives and a stuck run does not run forever.
Set limits per task type if the types differ a lot; a coding task and a lookup do not need the same.
Re-measure when the model, the tools or the prompt change.

Tip: budget money as well

Words or tokens are a stand-in for money. A real budget has a cost cap per run and per user per day, and a cap on parallel sub-agents, because a runaway that fans out multiplies spend. Pass a budget down to sub-agents so a parent's limit is shared, not multiplied.