Unattended agents need permission to stop. Without it, a failed run can turn into a loop of retries, unrelated fixes, broader diffs, and increasingly vague status reports. A circuit breaker is a simple rule that converts risky momentum into a safe blocker.

The goal is not to make automation timid. The goal is to decide, before the run starts, which signals mean “continue” and which signals mean “stop before making the situation worse.”

Put stop rules next to success rules

Many runbooks describe the happy path in detail but leave failure behavior implicit. That is where agents improvise. If the build fails, they may patch dependencies. If a deploy probe fails, they may rebuild. If a verification URL returns the wrong result, they may keep changing nearby files without proving the cause.

Circuit breakers make failure handling explicit. Useful breakers include:

  • Retry limits: stop after a small number of failed attempts at the same step.
  • Diff limits: stop if the change set grows beyond the intended files or scope.
  • Evidence limits: stop if the agent cannot produce a concrete observation for the next action.
  • Safety limits: stop immediately if secret-shaped content, private data, or destructive commands appear.
  • Time limits: stop when the investigation exceeds the runbook's budget without narrowing the cause.

Each breaker should name the action that follows. Usually that action is not “try harder.” It is “report a blocker with the evidence collected so far.”

Make the breaker observable

A circuit breaker works best when it can be checked mechanically. “Do not go too far” is vague. “If more than three files outside the expected content folder changed, stop and report the unexpected paths” is actionable.

A runbook can use language like this:

Before making a second repair attempt, inspect the current diff and the last verification output. Stop and report a blocker if the diff includes files outside the declared scope, if the same command failed twice with no new evidence, or if the next action would require guessing about credentials, private infrastructure, or destructive cleanup.

That instruction gives the agent a safe default when context is missing. It also gives reviewers a clear reason why the run stopped.

Prefer small blockers over large recoveries

Stopping early can feel inefficient, especially when the next guess might work. But unattended automation is judged by total risk, not by how confidently it continues. A concise blocker with evidence is cheaper than a large recovery from an agent that kept editing after its assumptions failed.

Circuit breakers are especially useful for scheduled publishing, deployment, data cleanup, and maintenance jobs. They keep the system's failure mode legible: either the task completed with receipts, or it stopped at a named boundary.

Rule of thumb: if an agent is allowed to retry, it also needs a rule for when retrying must end.