When an autonomous agent run should stop and ask

Knowing when an autonomous agent run should stop and ask is mostly a matter of listing the points where continuing would mean deciding something nobody authorized. There are six: a check failed or could not run, the next step needs an approval that was not given, a blocker is unresolved, a change has created an impact obligation on other work, the agent wrote outside its scope, or the state of a process is uncertain. In each case the agent, or the runner driving it, could carry on. It could retry, guess, widen its scope or assume the best. Every one of those choices substitutes a machine's guess for your decision, usually in exactly the situations where the guess is most likely to be wrong. A stop is not the run failing. It is the run doing its job: protecting the work it cannot judge. This page covers the six conditions and what a useful stop leaves behind.

A check failed, or could not run

The clearest stop condition is verification. If the checks for a task fail, the task is not complete, whatever the agent reports. If the checks could not run (a missing test file, a crashed test runner, an unsupported command), the task is not complete either. 'No result' must never be read as 'passed'.

One development workflow test refused a completion report that included a failed check with a plain message: 'Failed, missing or unsupported verification prevents completion.' That wording covers the three cases well. The same test showed the weakness of trusting reports: a later report that simply asserted a pass was accepted while the code still failed. So the stop should depend on checks the runner runs itself.

What the agent should not do on a failure is keep editing until the check goes green by any means. Weakening an assertion, skipping a test or changing the fixture is a known failure mode, covered in agents tampering with tests. One retry with the failure output is reasonable. After that, stop and show the output.

Approval missing or a blocker unresolved

Some steps need permission the run does not have. Typical examples: editing files outside the approved scope, running a destructive command, applying a database migration, pushing or publishing, or starting work on a task that is closed, on hold or waiting for a decision. An agent that meets one of these should stop and say exactly which permission it needs and why, not find a workaround such as copying the file somewhere it is allowed to edit.

Blockers are the other half. A task may depend on another task that is not done, or on a question only the owner can answer: which of two behaviors is correct, whether a breaking API change is acceptable, whether a failing legacy test matters. The agent can note its recommendation, but the decision is yours. Guessing produces work that has to be undone when the guess is wrong.

In both cases the right output is a question with context, attached to the task, so it is still there tomorrow. A question asked only in a chat window disappears when the session ends.

An impact obligation, an out-of-scope write or uncertain state

An impact obligation arises when a change touches something other completed work relies on. In a development regression test, a shared money helper changed from rounding to truncation. The checkout check passed; the CSV export check failed. Work already marked done now rested on changed code, and its evidence had gone stale. A run should not continue past that point as if the earlier tasks were still verified. See the blast radius of an AI change for how to find what depends on a change, and note that any such query only follows relationships someone recorded.

An out-of-scope write is a stop even if the change looks harmless. The point of scope is that you decided in advance what this task may touch. Report the path and let a person decide whether to revert it or open a separate task.

Uncertain process state is the last condition. If the runner cannot tell whether a previous agent process finished, crashed or is still running, it must not start another one on the same work. Hold the run until the state is reconciled, as described in recovering interrupted agent work.

What a good stop leaves behind

A stop is only useful if the person who reads it can act quickly. A good stop message names five things: the condition, the task, the evidence, the decision needed and what is safe to do next. For example: 'Stopped ENG-13: CSV export check failed after the cents() change (row(1.235) returned 123, expected 124). ENG-12 is complete and verified. Decision needed: should export keep nearest-cent rounding? Safe next step: nothing in progress; working tree committed at a1b2c3.'

Compare that with 'Error: task failed' and a 4,000-line log. The first takes two minutes to act on. The second takes twenty to reconstruct.

Stops cost something: an unattended run that stops at 11 pm does nothing until morning. That cost is visible and bounded. The cost of not stopping is neither: a night of work built on a failed check, an unapproved migration or a guess about behavior. If your runs stop too often, the fix is usually better-specified tasks and checks, not looser stop conditions. Sign-off at the end of a task is a separate decision, covered in human sign-off for AI tasks.

QUESTIONS

Should an AI agent retry when its tests fail?

Once, with the failure output in front of it, is reasonable. A second failure on the same task usually means the task, the test or the environment needs a person. Repeated retries tend to drift toward weakening the test rather than fixing the code. Stop, record the output and the attempts, and ask.

How do I make Claude Code or Codex ask before risky actions?

Use the tool's approval settings for commands and edits, keep unattended runs in modes that cannot edit when you only need analysis, and write stop conditions into the task: list the actions that require a question first, such as migrations, pushes and edits outside scope. Instructions alone are requests, so back them with approval prompts or guards where your tool supports them.

Is an agent stopping to ask a sign that the task was badly written?

Sometimes, and that is useful information. Frequent stops for missing context or unclear behavior point to tasks that need sharper acceptance criteria. Stops for failed checks, missing approvals or uncertain state are the system working as intended. Fix the first kind by improving tasks, not by removing the stop conditions.

RELATED GUIDES

• Cards vs scheduled tasks: what starts an agent?
• How to read BRAIN FLUID reports and provenance

RELATED HARNESS PAGES

• Deciding which AI agent tasks need human sign-off Deciding which AI agent tasks need human sign-off: a risk-based policy, who signs off what, and why DONE is not the same as released.
• When an AI agent edits the tests to make them pass When an AI agent edits the tests to make them pass: the signs, why it happens, and how to keep test files out of an implementation task's scope.
• The blast radius of AI code changes The blast radius of AI code changes: what one agent edit can break elsewhere, a worked rounding example, and how a reviewer finds affected features.
• Bounded autonomy: limits every unattended agent run needs Bounded autonomy: limits every unattended agent run needs, from an explicit task list to launch, retry, time, failure and spend limits.