AI-augmented operations: where an SRE agent earns trust
An agent that can read your telemetry, runbooks, and pull requests can cut time-to-detect and take toil off the on-call rota. The line between helpful and dangerous is the line between proposing and executing, and it has to be drawn in policy, not in prompts.
Platform teams are being sold autonomous operations. What we have seen work in regulated estates is narrower and more useful: an agent that triages incidents, proposes runbook actions, and reviews pull requests, with a strict and auditable boundary around what it may execute on its own. This is a note on where that boundary sits and how it moves over time.
Start with triage, not remediation
The first job is reading. When an alert fires, the agent gathers the context an engineer would gather: recent deployments, related alerts, the relevant runbook, similar past incidents, and the current state of the affected services. It posts a summary and a proposed next step in the incident channel.
That alone changes mean time to detect, because it converts alert noise into a ranked, contextualised list. It executes nothing, so the trust cost is close to zero.
Runbooks as executable knowledge
Runbooks that live in wikis are not consulted under pressure. Runbooks encoded as structured, versioned procedures can be retrieved by the agent, matched to the incident, and presented as concrete commands with the expected outcome of each.
The agent's proposals are only as good as the runbooks. Most engagements begin with a runbook clean-up, and that work pays back even if the agent is never switched on.
The execution boundary
Which actions the agent may take without a human is defined in policy-as-code: action type, scope, blast radius, and time window. Restarting a single pod in a non-production namespace is inside the boundary on day one. Scaling a production database is outside it for a long time, possibly forever.
Every execution is logged with the trigger, the context the agent saw, the policy that permitted it, and the outcome. The boundary widens only on evidence: a category of action earns automation when the agent's proposals for it have been accepted by humans consistently over a defined period.
Pull-request review as a quality gate
The same agent, given the codebase and the platform's conventions, reviews infrastructure and application changes for the things humans miss under load: missing alerts, absent rollback paths, changes to security groups, cost implications. It comments; it does not approve.
Teams report the review is most valuable on the boring changes that would otherwise get a cursory look. The high-drama changes already get attention.
Measuring trust
Track proposals accepted, proposals rejected with reasons, actions executed, and actions rolled back. Publish the numbers to the team. The agent that earns its widening boundary in public is the one the on-call engineers actually use.
What we tell clients: if the vendor pitch starts with autonomous remediation, ask to see the audit log design first.
Where we apply this in practice
Working on this in your own organisation?
If any of this maps to a programme you are running, we would be glad to compare notes.