When the system must stop

The Meal Companion enters iteration five. Each pass tweaks Thursday's meal marginally. Token cost accumulates. The household still waits. Nothing in the architecture declares stop. The model's vague sense that another pass might help keeps the loop alive. Missing stop design, not diligence, explains the wait. Agent loops without stop conditions train false completion and hidden cost, and users experience unbounded helpfulness as reliability until the system spins, burns budget, or silently abandons work.

Helpful context: Minimum sufficient loop defines the success stop. The agent loop describes iteration structure. Refuse and defer covers conduct language for unsuccessful exit.

Why infinite helpfulness is a bug

Products often treat stopping as failure. Metrics reward completion. Demos reward another clever pass. Engineers leave loop termination implicit because the model "usually knows when to stop." Usually is not a contract. Infinite helpfulness produces predictable harms: cost spirals on low-value iterations, latency that erodes trust even when output eventually arrives, silent abandonment when budget exhausts without user-visible partial state, false completion when the loop stops on token limit mid-plan, and training users that corrections require full regeneration. Stop conditions convert loop behaviour into testable policy. Success includes stop, and evaluation scores stop class alongside final artifact quality.

The agent stops when the work meets the minimum sufficient loop.

Introduction to Thoughtware Ch. 20

The stop taxonomy

The success stop comes from the minimum sufficient loop. Stop successfully when the outcome is useful (accepted provisional plan), exact checks pass (allergies, portions, spinach deadline), material assumptions are visible, authority is respected, and further iteration has low expected value. "Model ran out of tokens" and "iteration count equals three because we guessed" are accidents, not stops. Expected value of another pass is explicit in design: if critique finds no material weakness and checks pass, the loop stops and presents.

Stop type	Trigger	User-visible result
Success	Minimum sufficient loop met	Accepted plan with visible assumptions
Budget	Loop or cost limit reached	Partial plan plus what remains unresolved
Escalate	Frontier terrain, missing authority	Handoff with evidence packet
Ask	One material gap	Targeted question from AskTargetedQuestion
Unsuccessful exit	Constraints impossible	Named conflict, no false completion
Abstain	Insufficient evidence	Structured refusal per abstention as a result

The review decisions from the grounding reference include accept, patch, fetch, bridge, replan, ask, escalate, and stop unsuccessfully. Each is a stop class with logging obligations. Agent loop specs list stop classes explicitly the way API specs list error codes, because engineers implementing loops do not invent stop behaviour at integration time. Product, evaluation, and orchestration share one stop taxonomy referenced in regression suites.

Consider the practical arcs. In a success arc, iteration one composes, iteration two critique finds Thursday weakness, iteration three patches locally via RecommendMealSubstitution, checks pass, expected value of iteration four is low, and the loop stops successfully with plan version 1.2 and a visible diff. In an escalate arc, medical frontier detected at iteration one triggers immediate deferral, and budget is not consumed on futile replans. In an ask arc, leftover acceptability is unknown, so the loop fires one targeted question before composition. In an unsuccessful arc, the system names the constraint conflict and offers challenge options rather than producing five replans that never resolve fresh-greens versus spinach-by-Tuesday. In a budget arc, the loop limit reaches mid-critique, and the system presents partial plan with flagged unresolved Thursday weakness rather than silently truncating.

Wiring stops to conduct

Stop conditions connect directly to trust conduct. Ask stop wires to targeted questions materiality rules. Escalate stop wires to authority is granted. Unsuccessful exit wires to challenge as conduct when constraints conflict. Abstain stop wires to evaluation-backed gates in when the system should refuse. Mixing stop classes without naming them confuses users. "I couldn't help" is not a stop class. "Fresh-only greens and spinach-by-Tuesday cannot both hold. Choose tradeoff or stop" is.

Stop conditions are also cost governance. Unbounded loops burn token budgets and user patience. Architectures expose partial value when budget exhausts, because a plan with flagged gaps beats silence and a named conflict beats a hallucinated completion. Paying for reliability connects economic stops to trust stops. Teams that separate finance metrics from conduct metrics often discover loops that are too expensive to run in production and too unbounded to evaluate offline. Log stop class in telemetry. Dashboard stop rate alongside accept rate. Penalizing stops in product analytics trains confidence theatre.

Under load, systems pressure loops to skip stops and return something fast. Rate limits and circuit breakers are transport stops, and conduct stops still apply: partial plan with flagged gaps beats silent truncation. Transport retry does not override abstention or unsuccessful exit classes. Free tiers may use tighter loop budgets than paid tiers, but budget stops still return partial value and visible unresolved items. Tighter budgets are not excuses for silent failure or theatre completion to hide stop rate.

Partial value and recovery

Every stop except silent failure returns partial value where possible. Ask stop returns what is already known plus the question. Budget stop returns best plan so far plus flagged gaps. Escalate stop returns evidence packet plus safe partial scope. Unsuccessful stop returns named conflict plus tradeoff options. Users learn that stops are informative, not abandonment.

When stop follows partial progress, persistence before regeneration preserves accepted work. Budget stop with Monday through Wednesday accepted returns those days in visible state, not blank slate. Escalate stops package contestable state for humans: assumptions, checks passed, checks failed, user selections already made. Handoff without state forces humans to re-interview users, and that breaks recovery is part of trust at the organizational boundary.

Human approval steps are themselves stops. They carry the same visibility as automated stops: what the human sees, what they can edit, what happens on timeout. Human stops that silently default to approve are failed stop design. If every marketing surface shows only happy completion, users interpret stops as bugs. In-product copy normalizes ask, escalate, and unsuccessful exit the way good APIs document error codes as expected branches. Surveys after unsuccessful stops versus false completions often reveal that users prefer honest conflict to wrong plans, and that evidence justifies stop design politically against completion-only metrics.

Stop conditions in evaluation

Evaluation suites often golden-path only. Stop cases are essential: expect ask when gap present, expect escalate on medical frontier, expect unsuccessful exit on impossible constraints, expect success stop when checks pass and expected value is low, expect partial state on budget exhaust. Regression on stop class prevents drift toward infinite helpfulness after a demo sprint.

Product review reads stop class histograms alongside completion rate. A rising ask-stop rate may mean materiality rules improved. A rising budget-stop rate may mean critique loops are too greedy. A rising unsuccessful-stop rate may mean users send impossible constraint combinations. Each pattern suggests different design work. Alert when budget-stop rate spikes week over week, because spikes often precede user churn more reliably than latency alerts alone.

Each stop class maps to a runbook entry: what state is returned, who is notified, what eval case covers it. On-call does not guess whether budget stop is bug or design. Stop class alerts correlate with user satisfaction data to validate that honest stops outperform false completions in retention.

What to do next

Stop conditions transform loop behaviour from runtime accident into architectural commitment. The taxonomy of success, budget, ask, escalate, unsuccessful exit, and abstain covers the paths an agent loop can take, and each path leaves visible, contestable state. The same taxonomy applies to household planners, invoice intake, and any domain where iteration can spin without bounds.

Read the agent loop, minimum sufficient loop, and contestability.

Read next: Contestability explains how stops leave state users can inspect and correct.