Local AI Agents: Advanced · Module 1 · Lesson 3 of 3

Stop rules and the structured handoff artifact

Turning a bounded loop's exits into stop rules that do two jobs — log a structured failure reason a person can triage, and emit a handoff artifact the next owner can act on — so that every way the loop ends, success or abort, produces evidence instead of silence.

Lesson · 20–30 minutes · Text-first

By the end, you can

Write stop rules for an agent loop that log a structured failure reason and emit a handoff artifact on every terminal path (LA-11 O4).
Given an aborted run, assemble the complete handoff artifact a named next owner needs to act (LA-11 O4).

Before you start

This is the last lesson of the module, and it closes the loop the first two lessons opened. Lesson 1 built the plan-act-observe-reflect cycle; Lesson 2 put step, token and wall-clock budgets around it and established that aborting safely means returning a structured result rather than crashing. This lesson is about making that return *good*: a stop rule that not only halts the loop but records why, in a form a person can triage, and hands off enough state that the next owner can act without re-running anything. It extends LH-01's stop-rules and run-report lessons — the difference here is that the artifact is emitted by the loop itself, programmatically, on every terminal path, not written up by a human afterwards. This lesson does not run a model. Its exercise is the module's final-assessment contribution.

Every terminal path must produce a reason

A bounded loop has more than one way to end: the task completed, a budget was exhausted, an observation contradicted an assumption, a classified action needs approval. A stop rule's first job is to ensure that every one of those exits — not just the failures — records *which* exit it was, in a structured field, before the loop returns.

The reflect step is where this classification happens. In ReAct's terms, reasoning traces let the model "induce, track, and update action plans as well as handle exceptions" — and a stop is the handling of an exception the plan cannot continue past. But the reason must not stay as free-text reasoning inside the transcript; it has to be lifted into a structured value the caller can branch on and a person can filter. "The loop stopped" is not triageable. stop_cause: token_budget and stop_cause: contradicted_assumption are — one is a tuning problem, the other is a data problem, and only a structured reason lets whoever reads a hundred overnight runs tell them apart at a glance.

What goes in the handoff artifact

The handoff artifact is the single object the loop emits when it stops. It answers, without the reader needing to re-run anything, four questions: what happened, why it stopped, where things stand, and who does what next.

The completion path produces the same shape, minus the failure framing: what was done, that it completed, the final result, and — for a consequential task — who confirms it. Using one artifact shape for both success and abort is deliberate: it means the caller has exactly one kind of thing to read, and a monitoring layer can treat every run's end uniformly.

What was done, with evidence. The completed steps and their observations — the transcript from Lesson 2's loop — so the reader can see the actual work, not a claim about it.
Why it stopped. The structured stop_cause, plus the budget figures (steps and tokens used against their ceilings) or the specific condition that triggered the stop.
Current state. What is finished, what is partial, and what has not been touched — explicitly, so nothing is left ambiguous while the run waits.
What is needed next, and from whom. The decision the next step requires and the named owner who makes it. A handoff with no named next owner is not a handoff; it is a run that quietly stopped and hopes someone notices.

A stop rule is a guardrail, so it hands back rather than retries

The tempting failure is for the loop to treat a stop as something to reason its way out of — to retry the failed step, or to continue on a broken assumption because it is confident. That is precisely the behaviour Anthropic's guidance warns against: "the autonomous nature of agents means higher costs, and the potential for compounding errors," which is why it recommends running agents "in sandboxed environments, along with the appropriate guardrails." A stop rule is one of those guardrails. Its correct response to a real stop condition is to halt and hand back, not to spend another budget cycle papering over the problem — because a loop that continues past a broken assumption is the compounding-error case, turning one wrong step into a run's worth of them.

This is also why the handoff must be emitted *before* any further action, on the same principle as Lesson 1's human gates: the point of stopping is that the risky or wasteful continuation has not happened yet. A stop rule that logs its reason only after trying one more time has already given up the thing that made stopping worthwhile.

A worked example: the handoff for an aborted run

Take Lesson 2's overnight job-triage loop, aborting on its step budget with a likely-but-unconfirmed cause.

That artifact lets the engineer act in a minute without re-running the loop, and it is honest about the boundary between what was established and what was assumed — the graceful-degradation discipline from Lesson 2, now written into the handoff.

stop_cause: step_budget — 8 of 8 steps used, 5,900 of 8,000 tokens.
What was done: read the failed job's log (found a database timeout at 02:14), read the database container's log (found it restarted at 02:13), began checking whether the restart was scheduled — the step budget hit before that check returned.
Current state: likely cause identified — the job failed because the database was mid-restart — but *unconfirmed*: whether the restart was scheduled maintenance or a crash is not yet established.
Needed next, from whom: the on-call engineer confirms whether the 02:13 restart was scheduled; if scheduled, the job simply needs a later start time; if a crash, it is a separate incident. The loop does not guess between these.

Accessibility notes

This lesson is text-first, with no images, audio, video or downloadable artifacts; the handoff artifact is described as labelled prose fields rather than a rendered form or diagram, so nothing depends on seeing an image. The practice exercise's model answer sits behind a native, keyboard-operable disclosure control announced by screen readers, and the knowledge check uses native radio-button inputs with a visible question and options, posting its result to a live status region so the outcome is announced without a page reload.

Practice

Write the handoff for an aborted run

An agent loop was asked to reconcile a vendor invoice against purchase orders from a local records export, running on your own machine. It aborted mid-task. From the run you know: it read the invoice (total 4,820, twelve line items); it read the purchase-order export and matched eleven of the twelve line items to POs; on the twelfth it found the invoiced item but at a different unit price than any PO, and its next planned action was to adjust a PO record to match — an action classified as approval-required. The loop had used 6 of 10 steps and 3,100 of 6,000 tokens when it stopped. This exercise is the module's final-assessment contribution: build the complete handoff artifact.

State the structured stop_cause for this run and justify why it is that cause and not a budget cause.
Write the 'what was done, with evidence' section — the concrete work and observations, not a summary claim.
Write the 'current state' section, making explicit what is finished, what is partial, and what is unresolved.
Write the 'needed next, and from whom' section, naming the decision and a specific owner — and state why the loop must hand back here rather than proceed.

Compare with a bounded first version

The stop_cause is a classified-action stop (for example classified_action: approval_required), not a budget cause: the loop stopped with 6 of 10 steps and 3,100 of 6,000 tokens used, so no budget was exhausted; it stopped because its next planned action — adjusting a purchase-order record to match the invoice price — is approval-required, and the stop rule fired before that action, at plan time. What was done, with evidence: read the vendor invoice (total 4,820, twelve line items); read the local purchase-order export and matched eleven of the twelve line items to their POs by item; on the twelfth line item found a match on the item but a unit price that differs from every PO for it, so the twelfth line could not be reconciled without changing a record. Current state: eleven of twelve line items are reconciled and finished; the twelfth is partial — the discrepancy is identified (invoiced unit price does not match any PO) but not resolved; nothing has been written or changed, because the only path to resolution was an approval-required record change that the loop did not take. Needed next, and from whom: a person with authority over purchase-order records — for example the accounts-payable owner — decides whether the invoice price is correct (and a PO should be updated), whether the invoice is wrong (and should be queried with the vendor), or whether it is an approved variation; the loop must hand back rather than proceed because adjusting a financial record is approval-required and irreversible in effect, exactly the kind of action a stop rule exists to gate, and continuing would be the compounding-error case of acting on an unconfirmed price difference.

Knowledge check

Try the idea

Low-stakes practice only. A correct response marks this lesson complete; it does not affect your final assessment score.

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.

Building effective agents — Anthropic Engineering. Warns that the autonomous nature of agents means higher costs and the potential for compounding errors, and recommends testing in sandboxed environments with appropriate guardrails — the class a stop rule and its handoff belong to.
ReAct: Synergizing Reasoning and Acting in Language Models — Shunyu Yao and colleagues. Reasoning traces let the model induce, track and update action plans as well as handle exceptions, which is the reflect step's job when it classifies why a run must stop.