What should an AI circuit breaker do when it trips?

An operations desk at night lit by calm blue screens

When an ai circuit breaker trips, it should limit further action through graduated steps: throttle, pause, or stop. The right response depends on the action class and its learned baseline, and your review should establish what happened before work resumes.

What does an AI circuit breaker watch?

A breaker needs to watch activity by action class, not treat every action as one undifferentiated stream. Its baseline gives it a reference for judging whether a change is unusual for that class. Circuit breakers watch each action class against learned baselines and can halt activity in graduated steps.

That distinction matters because a change in one kind of action does not, by itself, show that every workflow is unsafe. A rise in one class may call for a limit there while other work continues. The response should match the signal and the possible effect of more activity in that class.

Before work runs, decide what change should trigger a response. Describe the signal in terms an operator can recognize, and decide which responses are permitted. If the signal is unclear, the team may disagree about whether a trip was warranted or what to do next.

The autonomy page and guide to project abort conditions provide related context. The useful setup question is not only what the breaker measures. It is what you want it to do when the measurement changes.

What should throttle, pause, and full stop mean?

Throttle, pause, and full stop are different limits on further action. They are not a required sequence. Choose the response that fits the action class, the size of the change, and the cost of continuing while someone checks what happened.

Throttle reduces activity while the team checks whether the signal is real and whether the work remains within bounds. Pause holds the action while someone reviews the evidence or makes a decision. Full stop means the action should not continue under the current conditions. Use it when limiting activity is not enough to contain the risk.

The missions page is a place to read about how work is organized. The operating rule should be clear before a trip: who can choose a response, what each response permits, and what must be reviewed before activity resumes.

When should the breaker stop rather than throttle?

Throttle fits a contained deviation when activity can be limited while the team checks the signal. A stop is needed when continuing under the current conditions would cross a limit the company has already set.

Missions carry pre-declared go-around gates for burn, quality, drift, and deadline. When a gate trips, the mission aborts itself blamelessly. The purpose of setting the gate in advance is to make the limit clear before the team is under pressure to explain a bad result or keep work moving.

Stopping and investigating are separate decisions. The breaker responds to the condition it was given. After the halt, the review can ask whether the signal was accurate, whether the gate was set well, and what should change. Do not make continued work the default while those questions are open.

Consequential actions are governed by an auditable authority contract. That contract should make clear who can set limits, who can approve a return to work, and what record supports that choice. See the missions page and the guide to autonomy as a contract.

An engineer watching several screens of soft moving light in a dark room

What should you review after a trip?

Start with the state at the moment of the halt. A sealed, hash-chained capsule snapshots context, prompt, and state. That preserved record gives the investigation something to examine besides a person's memory of a fast-moving event.

Review what action was underway, what signal crossed the trigger, which response followed, and what evidence was available at the time. Separate what the record shows from what the team infers. If the trigger was wrong, identify the evidence that supports changing it. If the trigger was right, identify what allowed the condition to arise.

An investigation can be run as a mission. Confirmed causes are swept through play and prompt registries, with directives tracked to closure. That makes follow-up work visible: a finding should lead to a named change and a way to check that the change was completed.

Pre-decided incident responses give the team a basis for handling incidents. The published incident classes and responses include automatic refunds for incident-class credits. For the review, keep the operational question separate from any credit handling: what happened, what action is safe now, and what needs to change?

The memory page and the report on verifying rejections are related reading. The record should let someone who was not present follow the reasoning.

How do you prepare the response before the next trip?

Write the response plan before the breaker fires. Start with the action classes it watches and the baseline used for each. Then define the trigger and the permitted response for each class. A rule that says only “halt if unusual” leaves too much room for dispute when work is already underway.

Set who reviews a pause or full stop under the authority contract. Name what evidence that person needs, who can authorize resumption, and which conditions require a new decision rather than a quick restart. The rule should limit action without making responsibility unclear.

Also write down how the team will investigate a trip and track confirmed causes through to closure. Keep the trigger, response, review, and follow-up in one record that people can find later. The autonomy page and guide to mission blocker responses offer related context.

A useful test is whether someone on call can tell what to do without inventing a policy in the moment. If they cannot, make the authority and response rules clearer before the next run.