Key takeaways
- A remediation agent should stop when the incident context changes enough that the original approval no longer covers the proposed action.
- A useful handoff names the proposed operation, completed actions, and the specific reason for the pause, not just a status code.
- Rollback is a separate operation with its own prerequisites, so stopping new work does not automatically cancel work already in progress.
- If no authorized reviewer responds within the timeout window, the workflow needs an explicit fallback.
- Repeated failed service checks are not a recovery plan. Further attempts need to follow a defined policy.
During an incident, you want automation to take work off your team’s hands. A pause is helpful when it prevents an unsuitable change and gives you enough context to decide what happens next. A vague “agent stopped” notification just adds another thing to investigate.
The difference comes down to what your remediation workflow knows about the action, the service, and the conditions under which it may proceed. An operation can be approved and still become inappropriate as an incident develops.
Imagine an agent is preparing a configuration restore when a separate deployment begins on the same service. Before either operation proceeds further, you need to understand how they interact. The original approval doesn’t answer that new question.
The seven conditions below are a starting checklist for production-service remediation. Your service owner supplies the specific thresholds and escalation rules. These conditions are evaluated deterministically in the execution path at the point each action is attempted, not by the agent deciding whether to respect its own boundaries.
1. The severity now requires a different decision owner
If an incident moves into a severity category that requires incident-command approval under your process, an earlier permission may no longer be sufficient. The automation needs to recognize that change before taking another consequential action.
At that point, a useful handoff identifies the proposed operation, any actions already completed, and the reason the new severity requires review. You can then decide whether the same recovery plan still fits the incident. Naming a specific decision owner for each severity tier before an incident occurs is what makes that handoff land with the right person.
2. The affected scope has grown
A proposed change to one resource can become a very different operation if the agent expands its target to several resources or discovers shared dependencies.
This is the blast-radius question: what could the action affect? If the affected scope exceeds the grant your service owner approved, the operation should return for review. Your team needs the revised target and dependency information, rather than an approval request that still describes the smaller change.
3. The diagnosis lacks the evidence your runbook requires
Confidence needs an operational meaning. If the diagnosis depends on a current configuration snapshot and that snapshot is unavailable, a confident explanation from the model doesn’t replace the missing check.
Conflicting evidence creates a similar problem. A newer record may undermine the assumption behind the proposed fix. A useful pause gives you the specific discrepancy and the evidence needed to resolve it.
Your criteria can include an evaluated confidence measure, but its threshold needs validation for the task. There is no universal score that makes a production action safe.
4. The approval no longer matches the operation
An expired approval, changed parameters, or a different target can leave the agent proposing work that your reviewer hasn’t authorized.
In these cases, the revised operation needs a new decision. If no authorized reviewer responds, the workflow needs an explicit fallback. The AWS Well-Architected Agentic AI Lens describes timeout policies that hold an operation or route it to an escalation path rather than treating an unanswered request as permission - and notes that wildcard trust grants that approve all future operations of a given type effectively remove human oversight from an entire class of actions. For a broader look at what governance needs to be in place before ops agents act on production, see who governs the ops agents now acting on their own.
5. Recovery is unavailable or another change is in progress
Before a consequential change, you need to understand the recovery options if it fails. If the planned recovery procedure is unavailable, the assumptions behind proceeding have changed.
Concurrent work deserves the same attention. In the configuration example, the deployment owner may already be changing the state the agent plans to restore. A pause allows your team to coordinate those actions.
Rollback is a separate operation with its own prerequisites. Stopping new actions doesn’t necessarily cancel one already in progress, and automatically restoring an earlier state may be unsuitable after other changes.
6. The attempted fix fails its service checks
A command can complete while the service remains unhealthy. Your workflow needs to examine the intended service outcome before deciding whether to continue. This is one reason moring’s remediation agent verifies the expected state after every action before deciding whether to proceed.
The principle is familiar from canary deployments, where observed behavior at a subset of traffic determines whether a rollout proceeds - the SRE Workbook describes pausing or rolling back when the canary error rate diverges from the control. Remediation may use different checks, but it still needs evidence of the action’s effect. The Workbook warns that metric intervals must be the same as or shorter than the evaluation window. An agent that checks an hourly-aggregated error rate two minutes after a remediation is reading a meaningless signal.
If the agreed checks fail or service health worsens, further attempts need to follow your defined recovery policy. Repeating a permitted command is not, by itself, a recovery plan.
7. A required control cannot be verified
Some actions depend on a permission check, a required record, or a containment mechanism being available. If the workflow cannot establish that a required control is functioning, it needs to pause the actions that depend on it.
The AWS Well-Architected Agentic AI Lens describes credential revocation and circuit-breaker activation as containment mechanisms, with forensic state captured before isolation. Your runbook needs to explain when those controls are used and what they mean for work already underway.
What you need when the agent hands over
A useful handoff lets you pick up the incident from a known state. It shows which actions ran, which remain unattempted, and which observation caused the pause. It also identifies the current owner and the condition that needs to change before work can resume.
Once that condition is resolved, your team can reassess the proposed action against the service as it is now. The original fix may still be appropriate, or another intervention may have made it unnecessary. The workflow should leave you with the evidence to make that decision without first reconstructing what the automation did.
Frequently asked questions
When should a remediation agent stop and hand back to a human?
When the incident context changes enough that the original approval no longer covers the proposed action: severity escalation, expanded scope, unavailable evidence, expired or mismatched approval, unavailable recovery, failed service checks, or a required control that cannot be verified.
What belongs in a handoff from agent to human?
The proposed operation, completed actions, the specific reason for the pause, the current owner, and the condition that needs to change before work can resume.
Does pausing new work cancel work already in progress?
No. Rollback is a separate operation with its own prerequisites. Stopping new actions does not automatically cancel one already underway.
What happens when no authorized reviewer responds to an approval request?
The workflow needs an explicit fallback: hold the operation or route it to an escalation path. An unanswered request is not permission.
Sources
Warner, N., and Davidovič, V. (2018). The Site Reliability Workbook: Practical Ways to Implement SRE. O’Reilly Media. Chapter 16, Canarying Releases: describes pausing or rolling back when canary error rate diverges from control; notes that metric intervals must be the same as or shorter than the evaluation window.
AWS Well-Architected Framework, Agentic AI Lens. AGENTSEC 4: How do you manage agent actions? Best Practice 02: describes timeout policies that hold an operation or route it to an escalation path; notes that wildcard trust grants effectively remove human oversight from an entire class of actions.
AWS Well-Architected Framework, Agentic AI Lens. AGENTSEC 7: How do you contain agent actions? Best Practice 04: describes credential revocation and circuit-breaker activation as containment mechanisms, with forensic state captured before isolation.
Author: moring editorial team Last updated: October 2, 2026
This article reflects current practices in production operations governance. Requirements and tooling continue to develop as agentic systems mature.
