Give Your Agent a Brake: Stop Conditions, Report Formats, and a Four-Level Escalation Path

The core claim: what you give an agent is not permission to retry forever, but a brake that must engage on time

When people assign a task to an AI agent, they usually write only "fix this problem" and never write "what to do if it cannot be fixed". The result is an agent quietly working on one problem for three hours: twenty files changed, a hundred test runs, two places it should never have touched quietly worked around, and a final diff that even it cannot explain. Asked why it took so long, it can only say "I kept trying". The problem is not lack of effort. It is that nobody ever told it when effort turns into waste, and when it must stop and ask a human.

A stop condition is that brake line. It is not distrust of the agent; it is a definition of how the collaboration works: which signals mean "the value of continuing has dropped below the cost of asking", so that the agent stops, reports, and waits for direction as soon as it sees a signal, instead of gambling another round on instinct. This guide gives you six trigger categories, a copy-ready threshold template for each, a one-sentence report format, a four-level escalation path, and the three places in a task sheet where stop conditions belong.

Boundary: what this guide is not

The boundary is stated first to avoid confusion with neighbouring guides on this site. This guide covers "circuit-breaking and escalation while the work is running" — during execution, in which situations the agent must stop and ask a human. The permission-contract guide covers the "up-front authorization scope": what the agent is allowed to touch and not touch before work starts — that is a pre-work authorization list. This guide covers what happens after work has started, while it is in progress, when signals require a熔断 even if the operations themselves fall inside the authorized scope. The task-acceptance-checklist guide covers "after-the-fact judgment of whether the task is done": ticking items when the task ends. This guide covers the middle of the task, when to stop before it ends — one is post-hoc, one is mid-flight. The bug-report guide covers "how to write a single bug clearly": reproduction steps, expected versus actual behaviour, environment information — that is how to write one document. This guide covers when the agent's bug-fixing behaviour itself should stop, not a report format. The pre-merge code-review guide covers "reviewing code": how to review code after it is written and before it merges. This guide covers the brake that should trigger while the code is still being written and the agent is still fixing. Each neighbour owns one segment; this guide owns only the in-flight segment.

1. Why "keep fixing" costs more than "cannot fix": three kinds of cost

The first cost is repair loops. The agent fixes A and introduces B, fixes B and introduces C, fixes C and brings A back. Without a global anchor in memory, each round only sees the latest failure, so it can spin in the same loop for many rounds. What you see on the surface is "it keeps working"; actual progress is zero. Worse, every loop leaves code changes behind: the longer the loop spins, the larger the diff, until even rolling back to before the loop started becomes difficult. A task that cannot be fixed wastes at most one task's worth of time; a repair loop wastes that time plus the time to clean up the diff.

The second cost is scope creep. Without stop conditions, an agent trying to turn tests green will unconsciously widen its changes: first business code, then test expectations, then configuration files, finally a shared module it should never have touched. Each step looks, to the agent, like something it "had to do to fix the problem", but together they amount to an unapproved refactoring. When you review, half the diff is the bug fix and half is incidental refactoring, and you can no longer tell which changes were necessary and which were improvised to pass tests. The most expensive part of scope creep is not the volume of code; it is that it quietly changes your understanding of the task: you thought one bug was fixed, but in fact the conventions of three modules were altered.

The third cost is silent requirement changes. When an agent gets stuck, it does not say "I don't know what this requirement means" the way a person would; it picks an interpretation itself and builds to it. When two readings are both reasonable but mutually exclusive, it chooses one without telling you. When a requirement is itself ambiguous, it fills in the ambiguity from its own understanding, again without telling you. By acceptance time you discover the feature runs, but it is not the feature you wanted. Rework at that point costs far more than the five minutes it would have taken to settle the requirement up front. Silent requirement changes are expensive because they push the cost of a decision to the most expensive moment — after the work is done.

All three costs share one trait: they happen while nobody is watching. The function of a stop condition is to shorten the unwatched stretches: the moment a signal appears, the agent must bring a human back, so the cost is seen while it is still small rather than discovered after it has spread.

2. Six trigger categories: threshold templates and one-sentence reports

Each category below gives three things: the trigger signal, a threshold template you can copy directly, and a one-sentence stop report format. The report format is fixed to four elements: what was done, where it is stuck, what was tried, and what decision is needed from you. Vague phrases such as "still trying" or "working on it" are not allowed; the report must state concrete facts.

Trigger one: the same problem fails N times. The signal is the same test, the same error, or the same symptom recurring while the agent tries different fixes without progress. Threshold template: the same failure symptom appears 3 times in a row, or 5 times cumulatively within one task — stop immediately. "Same failure symptom" is counted by error message and failing test case, not by how many lines the agent changed: three code changes that produce the identical error count as 3, not 1. Report format: "Made 3 attempts at fixing lost login state; stuck on the same case 'session invalid after refresh'; tried changing cookie expiry, refresh logic, and storage key names, none passed; decision needed: is this session expiry expected behaviour, or does the login flow itself need changing?"

Trigger two: change size exceeds a threshold. The signal is a growing diff — more files, more lines — so the task is no longer "fix one point" but "touch a whole area". Threshold template: more than 5 files changed, or more than 300 lines added plus deleted, or changes reaching 2 or more modules not listed in the task sheet — stop immediately. Line thresholds should be adjusted by task type: pure copy tasks can be looser, refactoring tasks need their own numbers, but the defaults above are the starting point. Report format: "Fixed the login module; stuck because changes have spread to 6 files and 420 lines; tried restricting changes to the login module but tests still fail; decision needed: may the scope expand to the session-storage module, or should the task be narrowed first?"

Trigger three: touching paid, permission, or deletion operations. The signal is that the next step involves spending money, changing permissions, deleting data, or calling an external production service. Threshold template: zero tolerance — whenever the next step is such an operation, stop and ask first, no matter how many failures came before, and never act first and report later. There is no "small amounts don't need approval" exception: the danger of a small charge is not the amount, but that it opens the door to moving real money without approval. Report format: "Fixed the order-export feature; stuck because the next step needs a real payment call to verify a refund; tried the sandbox but it cannot reproduce this case; decision needed: may a small real order be used for verification, or should another verification method be used?"