The incident bridge is full, the error budget is thinning and the service owner wants the quickest safe recovery. An operations agent has identified a familiar failure pattern. It can restart the unhealthy workers, revert the last configuration change and open the incident record in seconds. The SRE on call knows the same runbook would normally be used. The question is whether the organisation has authorised the agent to make that call while customers are waiting.
That is the production tension created by autonomous work. A sensible recovery action can still be the wrong business action if it occurs during a change freeze, affects a regulated workload, masks a wider fault or leaves no credible path back. Production authority is earned through operating discipline, not through an impressive demonstration.
This is the point at which an AI agent becomes part of the service-management system. It is no longer merely an AI product with a dashboard. It is another actor in the control plane: one that can create tickets, change configurations, invoke tools, trigger vendor workflows and alter the state customers experience. CIOs, platform leaders and SREs need to decide in advance what that actor may do, how it proves the case for action and who carries the consequence when it gets the call wrong.
Give autonomy an operating contract
A production agent needs an action envelope: a precise statement of systems it may inspect, actions it may take, facts that must be true, and actions that remain prohibited. “Help resolve incidents” is a product aspiration. “Restart one unhealthy stateless worker after three failed health checks, when no freeze is active, record the action and stop if recovery has not begun within five minutes” is an operating instruction.
The envelope should define four authority levels:
- Observe: gather telemetry, correlate events and prepare an evidence pack.
- Recommend: propose a runbook step or change plan for an operator to approve.
- Execute within policy: perform a pre-approved, bounded action when all stated checks pass.
- Escalate: stop, preserve the evidence and route the case to a named human when policy or context does not support execution.
Most teams should stay in observation and recommendation long enough to expose missing telemetry, ambiguous runbooks and undocumented human judgement. The aim is to gather evidence before narrowing authority.
NIST’s February 2026 AI Agent Standards Initiative is a useful indication of where the wider discipline is heading. NIST identified trusted adoption, security, identity and interoperability as central concerns for systems capable of autonomous action. In production, those ideas become plain operational questions: which agent acted, what was it entitled to do, what evidence allowed it to proceed, and can the organisation reconstruct the effect? NIST
That requires a dedicated non-human identity, least-privilege access and short-lived credentials. Read paths and write paths should be separate. An agent allowed to inspect a production database has no automatic claim on permission to alter it. An agent allowed to restart a service does not need cluster-administrator access. Broad operations credentials may simplify a prototype; in production they turn every tool call into a larger-than-necessary blast radius.
Turn each runbook into an action budget
The agent is not the unit of control. The production workflow is. Each permitted workflow needs an action budget that the model cannot negotiate once it is running.
Set limits on resources touched, tool calls, retries, concurrent actions, elapsed time and estimated cost. Define valid maintenance windows, corroborating health signals and stop conditions. Escalations must reach a rota with the telemetry, attempted action, policy result and change context needed to act.
This is familiar SRE practice applied to a new kind of actor. Error budgets, rate limits, feature flags, maintenance windows and change freezes should constrain agent authority. If availability is already deteriorating, the agent’s scope should contract. It may still collect evidence and propose a recovery, but a change with material risk deserves stronger corroboration or an explicit human decision.
Consider a bounded case: several stateless workers fail health checks, the restart has worked before, capacity remains healthy and no freeze applies. The agent can check the runbook, restart only those workers and verify recovery. It must not expand to cluster restarts, autoscaling changes or shared network policy. The budget holds the line between a local fix and a consequential global action.
Google Cloud’s guidance on deploying and operating generative AI applications calls for versioned chains, inputs, outputs and intermediate states, alongside monitoring for degradation and unexpected behaviour. For production agents, the chain also includes tool schemas, retrieval settings, policy rules, model routing and the side effects of every tool call. Treat them as production artefacts with owners and change records, rather than informal settings around an application. Google Cloud
Put approval where consequence changes
A blanket rule that every production action needs a human creates theatre under pressure. A rule that no production action does creates a different, more expensive theatre. Approval thresholds should follow consequence.
A thoroughly tested action on an isolated, low-criticality service may execute automatically inside a narrow budget. Customer-impacting changes, security-control modifications, data deletion, cross-region actions, actions with irreversible downstream effects, and work during an unfamiliar incident should require human authority. Familiarity matters because it determines whether the evidence has been tested against reality, not merely whether the action sounds routine.
AWS guidance on production feedback loops similarly distinguishes well-defined, low-risk autonomous actions from high-stakes or unfamiliar situations that call for human review. The management aim is not to force people to click through predictable work. It is to preserve judgement when the case exceeds the evidence, the policy or the known failure pattern. AWS
Review capacity is part of the design. Hundreds of approval requests during an incident are automated alert fatigue. Track approval volume, decision time, rejection rate and reasons for overrides to see whether the agent reduces work or moves it into another queue.
Decision rights need named owners. The service owner defines tolerable disruption; SRE defines technical preconditions and recovery evidence; security sets access boundaries; the AI owner maintains prompts, tools and evaluation; incident command can suspend autonomy. Blurred roles become operational ambiguity.
Recovery must include the business state
“Undo” is not a rollback plan. Production actions often leave effects outside the component being changed: a downstream workflow may have started, a ticket may have been rerouted, a vendor call may have been made, or a customer communication may have been sent.
For every permitted action, define the known-good state, technical reversal, data reconciliation required and business notification path. Restarting a worker may need no repair. Reverting a configuration may require a versioned restore and verification of dependent services. Rerouting a high-priority ticket may require an audit correction. A customer-facing action may need a follow-up and a service-recovery decision. The job ends only when both the technical and business state are understood.
Use progressive delivery for agent authority just as you would for an application release. Begin in observation mode. Allow recommendations next. Permit automatic execution for a small share of eligible, low-risk cases only after the evidence supports it. Compare results with the established runbook, then halt expansion when quality, recovery or incident indicators deteriorate.
Anthropic’s distinction between workflows and agents is helpful here. A workflow follows predefined code paths; an agent dynamically directs its process and tool use. Where a production action can be safely expressed as a deterministic workflow, make it one. Model-directed choice belongs where ambiguity genuinely requires it. That is a design decision that reduces operational variance, which is what production engineering is meant to do. Anthropic
Observe the decision path and the service
An agent that restores a service quickly can still be unsafe if it used a prohibited tool, exceeded its authority or succeeded by luck. Equally, a safe abstention can be the best result when context is incomplete. SRE observability for autonomous work therefore needs two joined views.
The first is conventional service health: availability, latency, saturation, error rates, change failure and customer impact. The second is agent behaviour: trigger, facts consulted, policy checks, tool calls, retries, proposed and executed actions, approvals, overrides and final state. The views must meet at the incident, change or ticket record. Otherwise teams can see that the service changed without knowing why the agent believed it was safe to change it.
Retain operational evidence rather than hidden reasoning: signals used, policy applied, authorised effect, tool responses and change identifiers. Protect it as sensitive operational data and make it retrievable for incident review and audit.
A useful agent dashboard includes action success, reversal and escalation rates; runs stopped by policy or budget; tool failures and retry patterns; approval latency and human override rate; time to detect and contain an unsafe action; and customer or service impact compared with equivalent human-run changes. These measures keep attention on reliability rather than on the number of autonomous actions completed.
Rehearse the agent incident
An agent incident has two tracks. The team must restore the service, and it must determine whether the agent’s authority, context or controls contributed to the problem. Those tracks belong in one incident process. Separating them into an SRE problem and an AI-team problem is how evidence disappears and accountability becomes a dispute.
The playbook should state who can pause the agent, revoke its tool access, disable its workflow, revert the last configuration version and communicate the operational state. It should preserve run evidence before logs rotate or context is overwritten. Its review questions should be equally direct: did the action budget work, did the approval threshold match the consequence, was rollback credible, and should this workflow return to recommendation mode?
Test this before a live failure. Feed the agent conflicting telemetry. Remove an expected dependency. Return a malformed or stale tool response. Simulate an approval-service outage. Ask it to act during a change freeze. A safe stop and escalation is a successful test result. Reliability is demonstrated by dependable behaviour under uncertainty, not by maximum action.
The leadership test is simple. During the next pressured incident, can the accountable executive answer four questions without opening a design document: what may this agent change, what evidence must it have, who can stop it, and how will we put customers and the business state right if it is wrong? If the answer is unclear, the organisation has a capable assistant, not a production-ready operator.
Sources
- National Institute of Standards and Technology, Announcing the AI Agent Standards Initiative for Interoperable and Secure Innovation, 17 February 2026.
- Google Cloud, Deploy and operate generative AI applications, last reviewed 19 November 2024.
- Anthropic, Building effective agents, 19 December 2024.
- Amazon Web Services, Architecting the production feedback loops, undated guidance accessed before the scheduled publication date.