How do you stop an AI agent continuing after the useful work is finished?

The overrun failure is under-discussed relative to how expensive it is. An agent that has finished the job and keeps going does three costly things: it spends, it changes files or records outside the intent, and it produces a report in which the actual work is mixed with unrequested work, so the review takes longer than if nothing had been automated. The last is the one that quietly kills adoption, because the reviewer's experience is of more work rather than less.

The root cause is that continuing is always an available action and there is usually something plausible to do next. Something can always be tidied, generalised, documented, refactored or extended. Absent an instruction, the model of a diligent worker includes doing a bit more, and the system is quite good at imitating a diligent worker.

The first control is a stated exclusion, and it needs to be specific rather than general. Do not change anything outside these two files. Do not alter the formatting of records you were not asked to update. Do not add tests for existing behaviour. Do not rename anything. These are boring and they are the whole control, because a general instruction to stay in scope is interpreted against the agent's understanding of scope, which is the thing in dispute.

The second is a cap, expressed in whatever unit the system exposes: steps, tool calls, tokens, wall time. A cap is not a quality control and does not need to be tuned finely. Its job is to convert an unbounded failure into a bounded one, and any cap does that. Running without one is a decision to accept an open-ended cost on the run where something goes wrong, which is precisely the run where the cost will be highest.

The third is the least obvious and the most effective: make stopping short a reportable outcome rather than a failure. If the only acceptable report is a completed job, the system will find a way to produce one. A brief that says stopping with items unfinished is acceptable and must be reported item by item removes the pressure that drives both overrun and the sort of definitional cleverness that dresses up an unfinished job. The report format is doing real work here, not documentation.

There is a variant worth naming separately because it is common in code and in documents: the fix that expands. Asked to correct one thing, the agent notices adjacent things that are also wrong and corrects those too. This is genuinely helpful about a third of the time and is expensive the rest, because the change is now larger than the review budget allocated to it. The convention that works is to have adjacent findings reported and not acted on, which keeps the observation and removes the unreviewed change.