Stopping Conditions: How AI Loops Know When to Quit (and What Happens When They Don't)

Written By Alpa Parmar

A loop without stopping conditions is a tap left running. The complete guide to done-checks, budgets, circuit breakers and escalation triggers: the unglamorous engineering that makes autonomous AI affordable and safe.

Every powerful machine in history shipped with a way to stop it, and the ways multiplied as the machines got more autonomous. The kettle got a whistle, then a thermostat. The car got brakes, then a rev limiter, then a fuel cutoff. The lesson took a few burnt kitchens per invention, and it is always the same lesson: the more a machine runs without you, the more engineering belongs in how it stops.

AI loops are the newest powerful machine that runs without you, and their stopping problem is the least glamorous, most consequential topic in the whole loop engineering discipline. A loop that does not know when it is done will keep going: politely, plausibly, at machine speed, spending real money and taking real actions while everyone sleeps. The practitioner community learned this fast; even the term's coiner flags token costs in his second sentence, and "you absolutely have to be careful" is not a phrase engineers use decoratively.

This article is the complete guide to making loops stop well: the four kinds of stopping condition, why "the AI says it's finished" is the one answer that never suffices, the runaway patterns and their circuit breakers, and the one-page stop-sheet every business loop should carry.

What Is a Stopping Condition?

A stopping condition is a rule, checkable from outside the AI's own opinion, that ends a loop's run: the goal is verifiably met, a budget is exhausted, a boundary is crossed, or a failure pattern is detected. Loops need them at both levels of the [nesting]: the inner task loop ("stop working on this invoice when...") and the outer scheduled loop ("stop this morning's whole run when...").

The analogy that carries the article: the thermostat versus the hopeful cook. A pot watched by someone who "feels like it's probably done" boils over the moment attention lapses. A thermostat does not hope: it measures a condition (temperature reached) and acts (heat off), every time, unattended. Stopping conditions are thermostats for loops: externally checkable states, not internal impressions. The whole discipline in one sentence: never let the pot decide it is done by vibes, least of all a pot that talks.

The Four Kinds of Stop

1. The done-check: the goal is verifiably met. The good stop, and the one requiring the most design honesty. "Done" must be a checkable condition, not the model's self-assessment: the payment recovered or the case escalated, the queue empty, every item's state written. The gold standard, borrowed from the coding world's /goal primitives: the check is performed by something other than the worker: a separate checker model, a mechanical test, or both. (Claude Code and Codex both implement exactly this: a fresh model judges whether the stop condition holds, the [maker-checker split] applied to "finished" itself.) If your loop's done-condition cannot be written as a checkable sentence, the loop is not ready; that sentence IS the specification.

2. Budgets: the resources are spent. Hard ceilings per task and per run: cycles ("no task exceeds 25 iterations"), tokens ("no run exceeds $X of model usage"), time ("the morning run ends by 8:30 whatever remains"), and actions ("never more than 40 emails per run"). Budgets are the stop that protects you from the failure you did not foresee, which is precisely why they cannot be optional: they are the only stop that works when everything else has gone strange. The [pillar's] tap-left-running warning is answered here, in four numbers on a page.

3. Boundaries: a line was reached. The [governance] stops: an action exceeded a threshold (money, reach, sensitivity), a case matched an escalation trigger, a tool returned something outside expected shape. These do not end the loop so much as route around it: the item leaves the loop for a [human approval queue], with context attached, and the loop continues on the rest. Boundary stops are where loop engineering and your existing [gate map] become one document.

4. Circuit breakers: something is wrong with the loop itself. The failure-pattern stops: the same item failing its check twice ("two strikes, human queue"), the same tool erroring repeatedly ("three failures, pause the run and alert"), output quality collapsing (checker rejection rate spikes), or cost velocity going abnormal ("spend rate doubled versus baseline, halt"). Circuit breakers exist because loops fail in patterns, not single events, and a pattern detected at cycle five costs pennies while the same pattern discovered on the monthly invoice costs a story you will tell at conferences.

The One Answer That Never Suffices

Worth its own section, because it is the most common gap in real deployments: "the AI says it's finished" is not a stopping condition.

The [LLM guide] explains why from the machinery: the model is an improviser whose confidence is identical when right and wrong. A worker-model's "done" is a claim shaped like all its other fluent claims. The coding-agent world learned this early and built the answer into its tools: the stop condition is judged by a separate model or a mechanical test, never by the one that did the work. Osmani's phrasing: even with the split, "done is a claim and not a proof," which is why sampled human review ([the improvement loop]) never fully retires.

The business translation is a hierarchy of trustworthiness for done-checks, best first: mechanical verification (the payment exists, the record updated, the file parses), independent checker model against explicit criteria ([the reflection checklist]), worker self-report. Use the highest rung available per condition, and treat any loop whose only stop is rung three as unfinished engineering.

The Runaway Patterns: A Field Guide

Four ways loops fail to stop, each with its breaker.

The circler. The inner loop retries variations of the same failing approach: cycle 12 looks like cycle 4 with different adjectives. Breaker: cycle budgets plus loop detection (repeated tool calls with similar arguments trip a halt), plus the [planning disciplines] that give tasks a route in the first place.

The perfectionist. Maker and checker ping-pong forever: draft, reject, redraft, reject. Breaker: revision caps ("two redrafts, then human queue"), which also generates the most useful escalations in the system: work the loop cannot satisfy itself about is exactly what a person should see.

The glutton. Context assembled carelessly grows every cycle (full history re-sent, documents re-attached), so each cycle costs more than the last, invisibly. Breaker: cost-per-cycle monitoring with velocity alerts, and the [context-engineering] fixes (summaries, retrieval on demand) that treat the cause.

The sorcerer's apprentice. The outer loop's discovery step over-matches ("find invoices needing chasing" matches half the ledger after a data hiccup) and the loop diligently processes an ocean. Breaker: sanity bounds on discovery ("if today's queue exceeds 3x the trailing average, halt and alert before processing"), the single cheapest catastrophic-failure prevention in the discipline. Named for the fairy tale because it is precisely the broom fetching water: perfect obedience, absent judgment, no one watching the bucket count.

A Real-World Shape: The Stop-Sheet in Action

A distributor's document-intake loop ([the operations playbook], on a heartbeat): supplier documents in, extracted, validated, posted to systems, exceptions queued. Its stop-sheet, one page on the wall and in the config:

Done per item: extraction validated mechanically (totals match, fields parse) AND checker passes format rules AND state written. Done per run: intake queue empty or 8:30am, whichever first. Budgets: 20 cycles per document, $6 model spend per run, 200 documents per run. Boundaries: any document over $10,000 queues for approval regardless of validation; unknown supplier formats queue always. Breakers: same document failing twice → exception queue; extraction tool erroring 3 times → run pauses, ops lead alerted; daily queue exceeding 3x trailing average → halt before processing (the apprentice-breaker).

In eight months the breakers have fired four times: twice for a supplier's format change (caught in minutes), once for an API outage (loop paused gracefully instead of hammering), and once, memorably, when a mis-configured export flooded the queue with 1,900 duplicates: the 3x sanity bound halted the run at 7:02am, one alert, zero pounds of nonsense processed. That morning paid for the whole stop-sheet's design time roughly fortyfold, and nobody in the business has since asked whether stopping conditions are over-engineering.

Setting the Numbers: From Baseline to Budget in Three Steps

The stop-sheet template is easy; the numbers on it are where teams stall. Here is the method that replaces guesswork.

Get you FREE Stop-Sheet Template here

Step 1: Run caged and measure (weeks one and two). During the [shadow period] every loop should have anyway, record the natural statistics: cycles per item (median and 95th percentile), tokens per run, items per day, checker rejection rate. These are your baselines, and they are facts, not opinions, which is what makes everything after defensible.

Step 2: Set budgets at generous multiples, not tight fits. Budgets exist to catch the abnormal, not to trim the normal: a cycle budget at roughly twice the observed 95th percentile, run spend at 1.5 to 2x the observed peak, discovery bounds at 3x trailing average. Tight budgets fire on healthy variation and teach everyone to ignore alarms; generous ones fire only when something is genuinely strange, which is the entire point of an alarm.

Step 3: Tune quarterly, from the log, in one direction at a time. Budgets that have never fired in a quarter can tighten modestly; budgets that fired on healthy runs loosen; and every real catch (the format change, the flood, the outage) gets a one-line post-mortem: did the right stop fire, fast enough, to the right person? The stop-sheet is a living document with the same review rhythm as every [governance boundary], and its revision history quietly becomes the loop's safety biography.

One number deserves special mention because everyone asks: what should the model-spend budget be? The unhelpfully honest answer is "roughly double what two clean weeks cost," because the right figure is a property of your loop's observed metabolism, not of any industry table. The method IS the number.

What Are the Limitations?

Stops cannot supply judgment. A perfectly bounded loop still does the wrong work if the goal was mis-specified; budgets contain the blast radius of confusion, they do not cure it. Goal design remains upstream (Recursive Goals, this cluster's next article).

Over-tight stops create their own failure. Budgets set from anxiety rather than data halt healthy runs, flood the exception queue, and teach operators to bypass alarms, the [rubber-stamping] dynamic in a new costume. Set from a fortnight of observed baselines, then tune quarterly from the logs.

Breakers need testing, like fire drills. A circuit breaker that has never fired is a hypothesis. Seed the occasional failure (a malformed test document, a dummy over-threshold item) and confirm the stop actually stops; the [seeded-test habit] transfers directly.

Someone owns the halt. Every stop that pauses a run routes to a person: named, deputised, and equipped with a runbook line ("if the intake loop halts, check X, restart with Y"). An unowned halt is downtime; an owned one is the system working.

Frequently Asked Questions

What is a stopping condition in an AI loop? An externally checkable rule that ends or pauses a loop: the goal verifiably met (done-check), resources spent (budgets), a threshold crossed (boundaries routing to humans), or a failure pattern detected (circuit breakers). The defining property: checkable outside the AI's own opinion of itself.

Why can't the AI just decide when it's finished? Because a model's "done" is a fluent claim, produced by the same mechanism as its correct and incorrect answers alike. Trustworthy done-checks use mechanical verification or a separate checker model, the maker-checker split applied to completion itself, which is exactly how the leading coding-agent tools implement their run-until-done features.

How do I prevent runaway AI costs in loops? Four layers: hard budgets per task and per run (cycles, tokens, actions, time), cost-velocity alerts (spend rate versus baseline), context discipline so cycles do not bloat, and discovery sanity bounds so a data hiccup cannot feed the loop an ocean. Budgets are the layer that works when everything else surprises you.

What is a circuit breaker in AI automation? A stop triggered by failure patterns rather than single events: repeated check failures, recurring tool errors, quality collapse or abnormal spend velocity, pausing the loop and alerting a named owner. Borrowed from electrical engineering for the same reason: patterns of fault deserve automatic disconnection.

What should be in a loop's stop-sheet? One page: the verifiable done-condition per item and per run, the four budgets (cycles, tokens, actions, time), the boundary thresholds routing items to human approval, the circuit-breaker rules, and the named owner of halts with a one-line runbook. If it does not fit a page, the loop's scope is probably too broad.

How do stopping conditions relate to human approval gates? Gates are one of the four stop types (boundaries): conditions that route an item to a person rather than ending the run. The [gate-map design] from our human-approval guide slots directly into the stop-sheet; loops simply give the gates a schedule and make their absence more expensive.

The Takeaway

Autonomy is a stopping problem wearing a productivity costume. The loop that runs without you is only an asset because of the thermostats around it: a done-condition something other than the worker can check, budgets for the unforeseen, boundaries that summon humans, and breakers that smell patterns.

Write the stop-sheet before the loop runs, set the numbers from observed baselines, drill the breakers, and name the owner of the halt. It is the least exciting page in your whole automation programme, and, as one flooded intake queue at 7:02 on a Tuesday morning quietly proved, the most profitable.

Bots and Brand Works writes the stop-sheet before writing the loop, every time: done-checks above self-report, budgets from baselines, breakers drilled. Running a loop without one? Send us its goal and we will draft the stop-sheet, free, before the tap teaches you the lesson instead.

Need Help Implementing AI?

Read our FAQ section to learn more.

Resources and Further Reading

The stop-sheet template is easy; the numbers on it are where teams stall. Here is the method that replaces guesswork.

Step 1: Run caged and measure (weeks one and two). During the [shadow period] every loop should have anyway, record the natural statistics: cycles per item (median and 95th percentile), tokens per run, items per day, checker rejection rate. These are your baselines, and they are facts, not opinions, which is what makes everything after defensible.

Step 2: Set budgets at generous multiples, not tight fits. Budgets exist to catch the abnormal, not to trim the normal: a cycle budget at roughly twice the observed 95th percentile, run spend at 1.5 to 2x the observed peak, discovery bounds at 3x trailing average. Tight budgets fire on healthy variation and teach everyone to ignore alarms; generous ones fire only when something is genuinely strange, which is the entire point of an alarm.

Step 3: Tune quarterly, from the log, in one direction at a time. Budgets that have never fired in a quarter can tighten modestly; budgets that fired on healthy runs loosen; and every real catch (the format change, the flood, the outage) gets a one-line post-mortem: did the right stop fire, fast enough, to the right person? The stop-sheet is a living document with the same review rhythm as every [governance boundary], and its revision history quietly becomes the loop's safety biography.

One number deserves special mention because everyone asks: what should the model-spend budget be? The unhelpfully honest answer is "roughly double what two clean weeks cost," because the right figure is a property of your loop's observed metabolism, not of any industry table. The method IS the number.

What Are the Limitations?

Stops cannot supply judgment. A perfectly bounded loop still does the wrong work if the goal was mis-specified; budgets contain the blast radius of confusion, they do not cure it. Goal design remains upstream (Recursive Goals, this cluster's next article).

Over-tight stops create their own failure. Budgets set from anxiety rather than data halt healthy runs, flood the exception queue, and teach operators to bypass alarms, the [rubber-stamping] dynamic in a new costume. Set from a fortnight of observed baselines, then tune quarterly from the logs.

Breakers need testing, like fire drills. A circuit breaker that has never fired is a hypothesis. Seed the occasional failure (a malformed test document, a dummy over-threshold item) and confirm the stop actually stops; the [seeded-test habit] transfers directly.

Someone owns the halt. Every stop that pauses a run routes to a person: named, deputised, and equipped with a runbook line ("if the intake loop halts, check X, restart with Y"). An unowned halt is downtime; an owned one is the system working.

Frequently Asked Questions

What is a stopping condition in an AI loop? An externally checkable rule that ends or pauses a loop: the goal verifiably met (done-check), resources spent (budgets), a threshold crossed (boundaries routing to humans), or a failure pattern detected (circuit breakers). The defining property: checkable outside the AI's own opinion of itself.

Why can't the AI just decide when it's finished? Because a model's "done" is a fluent claim, produced by the same mechanism as its correct and incorrect answers alike. Trustworthy done-checks use mechanical verification or a separate checker model, the maker-checker split applied to completion itself, which is exactly how the leading coding-agent tools implement their run-until-done features.

How do I prevent runaway AI costs in loops? Four layers: hard budgets per task and per run (cycles, tokens, actions, time), cost-velocity alerts (spend rate versus baseline), context discipline so cycles do not bloat, and discovery sanity bounds so a data hiccup cannot feed the loop an ocean. Budgets are the layer that works when everything else surprises you.

What is a circuit breaker in AI automation? A stop triggered by failure patterns rather than single events: repeated check failures, recurring tool errors, quality collapse or abnormal spend velocity, pausing the loop and alerting a named owner. Borrowed from electrical engineering for the same reason: patterns of fault deserve automatic disconnection.

What should be in a loop's stop-sheet? One page: the verifiable done-condition per item and per run, the four budgets (cycles, tokens, actions, time), the boundary thresholds routing items to human approval, the circuit-breaker rules, and the named owner of halts with a one-line runbook. If it does not fit a page, the loop's scope is probably too broad.

How do stopping conditions relate to human approval gates? Gates are one of the four stop types (boundaries): conditions that route an item to a person rather than ending the run. The [gate-map design] from our human-approval guide slots directly into the stop-sheet; loops simply give the gates a schedule and make their absence more expensive.

The Takeaway

Autonomy is a stopping problem wearing a productivity costume. The loop that runs without you is only an asset because of the thermostats around it: a done-condition something other than the worker can check, budgets for the unforeseen, boundaries that summon humans, and breakers that smell patterns.

Write the stop-sheet before the loop runs, set the numbers from observed baselines, drill the breakers, and name the owner of the halt. It is the least exciting page in your whole automation programme, and, as one flooded intake queue at 7:02 on a Tuesday morning quietly proved, the most profitable.

Bots and Brand Works writes the stop-sheet before writing the loop, every time: done-checks above self-report, budgets from baselines, breakers drilled. Running a loop without one? Send us its goal and we will draft the stop-sheet, free, before the tap teaches you the lesson instead.

Need Help Implementing AI?

Read our FAQ section to learn more.

Resources and Further Reading

Alpa Parmar

AI Marketing Automation

https://www.botsandbrandworks.com
Next

What Is an Agent Loop? The Cycle That Makes AI Autonomous