Local AI Agents · Module 2 · Lesson 3 of 3

Stop rules

Deciding, before a task runs, exactly when an agent must halt and hand back — on budget, on condition, and on classification — and practicing the module's core skill of rewriting a vague task into a bounded one.

Lesson · 20–30 minutes · Text-first

By the end, you can

Define budget-based and condition-based stop rules for a bounded task, before it runs (LA-2).
Rewrite a vague task instruction into a bounded task with explicit inputs, outputs, constraints, acceptance criteria and a stop rule (LA-2).

Before you start

This is Module 2, Lesson 3 of the Local AI Agents course, and the last lesson before Module 3's work on safe local setup. It assumes Module 1's vocabulary, this module's input/output/constraint statement, and its acceptance criteria. This lesson adds the piece that makes a task brief actually bounded in time, not just in scope: a written rule for exactly when the agent must stop, before it runs.

Every bounded task needs a stop line

An input/output/constraint statement bounds what a task touches. Acceptance criteria bound what counts as a correct result. Neither one bounds how long, how far, or how many attempts an agent may take trying to get there — and without that third boundary, a task that is well specified in every other respect can still run far past the point where it stopped being useful, or safe, to continue unattended.

A stop rule answers one question in advance: under what conditions does this agent halt and hand back, regardless of whether it currently believes the task is done? "Regardless of whether it believes the task is done" matters — a stop rule is not a hint the agent can reason its way past when it feels confident. It is a line decided by the operator, before the run, that the agent's own confidence does not get to move.

Budget-based stop rules

A budget-based stop rule sets a measurable ceiling — on time, on tool calls, on cost, on retries — and requires the agent to halt when that ceiling is reached, whatever state the task is in.

Google's Site Reliability Engineering practice offers a useful model for this, even though it was built for a different problem. An error budget is "the difference between" a service's reliability target and its actual measured reliability — a quantified amount of acceptable failure. As long as the budget is not exhausted, work can continue as planned; once it is exhausted, the response is not a judgement call made in the moment — it is a predetermined action: releases pause, or effort redirects to fixing the underlying problem, because the threshold decided that in advance.

Applied to a bounded task, a budget-based stop rule works the same way:

The number is less important than the property Google's practice highlights: the ceiling is fixed before the run, and reaching it triggers a stop automatically — not a request for the agent to decide whether it still feels like continuing is a good idea.

Time budget — a maximum wall-clock duration for the run.
Attempt budget — a maximum number of retries for any single step that keeps failing.
Tool-call budget — a maximum number of calls to a given tool, especially one with a cost or a side effect attached.
Cost budget — a maximum spend, where the tools involved have a metered cost.

Condition-based stop rules

Not every stop condition is a number running out. Some are about what the agent has discovered partway through the task.

The second and third conditions matter more than they might look. A task that keeps going after discovering a broken assumption is not showing initiative; it is compounding a problem the operator has not yet seen. Anthropic's engineering guidance is direct about this cost: "the autonomous nature of agents means higher costs, and the potential for compounding errors," and it recommends sandboxed testing with guardrails rather than trusting a wide-open run. A stop rule is one of those guardrails — it is what keeps one wrong step from becoming several.

Acceptance met — the criteria from the previous lesson are satisfied; the agent stops because the task is actually, verifiably done.
Evidence contradicts an assumption — something the task brief assumed turns out to be false (a source is empty, a format has changed, a count does not reconcile), and continuing on the original plan is no longer safe.
A classified action is proposed — the agent's next step is approval-required or out-of-scope, using Module 1's classification. This is where a stop rule and an approval boundary meet: OpenAI's guidance on human review describes exactly this pause — the run stops "so a person or policy can approve or reject a sensitive action" — before that action takes effect, not after.

Escalation is a handback, not a failure report

Stopping is not the same as failing, and a stop-and-handback packet should not read like an apology. It should tell the next person exactly what they need to make a decision:

A later module in this course, Rollback and handoff, covers how to write that packet in full. For this lesson, the point is narrower: deciding in advance that a stop will produce a handback, not silence or an unreviewed retry, is itself part of the stop rule — not an afterthought once the agent has already halted.

What was completed, with evidence.
Exactly what triggered the stop — which budget or which condition.
What decision is needed now, and from whom.
What state everything is currently in, so nothing is left ambiguous while it waits.

A worked example: stop rules for the ticket-summary task

Building on the earlier lessons' bounded ticket-summary task:

Time budget: the run halts after 10 minutes of processing, whatever state it is in.
Tool-call budget: the export-reading tool may be called once per run; a second call signals something unexpected and triggers a stop.
Evidence condition: if the export contains zero rows for the target week, the agent stops rather than producing a summary of nothing and presenting it as complete.
Classification condition: nothing in this task's action set is approval-required or out-of-scope, so this trigger does not fire for the current design — but it stays written down, so it applies automatically the moment the task's scope changes.

Accessibility notes

This lesson is text-first, with no images, audio, video or downloadable artifacts. The practice exercise's model answer sits behind a native disclosure control that is reachable and operable by keyboard and correctly announced by screen readers. The knowledge check uses native radio-button inputs with a visible question and options, and posts its result to a live status region so assistive technology announces the outcome without a page reload.

Practice

Rewrite a vague task into a bounded task

A colleague asks: 'Can you get an agent to tidy up our shared project drive? It's a mess — old files everywhere, duplicate folders, stuff that should have been archived ages ago.' There is no further detail: no named folder, no definition of 'old,' no list of what counts as safe to move, and no mention of who checks the result.

Write the bounded input statement: source, scope, retention and sensitivity.
Write the bounded output statement: shape, destination and side effects — and be explicit about which actions (if any) the agent may take automatically versus only propose.
Write at least two checkable acceptance criteria for this task.
Write at least one budget-based and one condition-based stop rule for this task.

Compare with a bounded first version

Input: the agent reads file names, paths, sizes and last-modified dates from one named top-level folder only, not the whole drive; it does not open or read file contents, and retains nothing beyond the run. Output: a proposed reorganization plan (a list of suggested moves and archive candidates, with reasoning) written to a review document; the agent does not move, delete or archive anything itself — every file action is approval-required, not automatic, because moving or deleting someone else's files is exactly the kind of action Module 1 places outside the automatic set. Acceptance criteria: every file in the named folder appears in the plan exactly once, checked by comparing the plan's file list against a fresh directory listing; no file is proposed for archiving unless its last-modified date is older than a stated threshold (for example, eighteen months), checked against each file's actual metadata. Stop rules: a time budget of, for example, 15 minutes for the scan; and a condition-based stop if the folder contains files the agent cannot read metadata for, since guessing at an unreadable file's status is exactly the kind of assumption this lesson says should trigger a stop rather than a silent continue.

Knowledge check

Try the idea

Low-stakes practice only. This does not score, block progress or create a learner record.

Sources and limits

This lesson synthesises the sources below into a practical learning model. It is not a security standard, legal advice or a guarantee that any particular agent design is safe.

Site Reliability Engineering, Chapter 3: Embracing Risk — Google SRE Book. Defines an error budget as a measurable threshold of acceptable unreliability that triggers a stop-and-review response once it is exhausted.
Guardrails and human review — OpenAI API documentation. Human review pauses a run before a sensitive action so a person can approve, reject or redirect it — the mechanism a condition-based stop rule hands control to.
Building effective agents — Anthropic Engineering. Warns that agent autonomy raises cost and the risk of compounding errors, and recommends sandboxed testing with appropriate guardrails rather than open-ended runs.