Google SRE has started describing, in public, how it runs agentic AI against production — not as a demo, but as an architecture with names and seams: an autonomous control plane built from a reasoning engine (AI Operator), an actuation guardrail (Actus), and a continuous evaluation pipeline grounded in human operational memory (IRM Analyzer). There’s a longer companion write-up on sre.google.
Most of us will never operate at Google’s scale, and copying Google’s tooling wholesale has burned more platform teams than it has helped. But this one is worth studying closely — not for the components, for the cuts. Where Google chose to draw the boundaries is a free lesson from the team with the largest corpus of production incidents on earth, and the boundaries land almost exactly where I’ve been arguing they should for a year.
The architecture in one pass
Three components, three jobs, deliberately not merged:
AI Operator is the reasoning engine. It consumes incident signals and produces mitigation intent — what it thinks should happen. It does not touch production.
Actus is the actuation layer, and it’s where the interesting engineering lives. It holds a curated, dynamically filtered registry of mitigation tools — the agent doesn’t get “the API,” it gets a vetted menu that changes with context. It translates the model’s intent into a concrete, verifiable execution plan. And it enforces what Google calls a Progressive Authorization framework with pre-flight safety validations: mandatory dry-runs, justification verification, and concurrent-action checks before any plan executes.
IRM Analyzer closes the loop. It captures incident timelines and the trajectories of human responders — what people actually did, in what order, with what result — and uses stratified sampling to keep surfacing incidents for manual review. That produces gold-standard evaluation data, and the evaluation results feed back into how much authority the agents are granted.
Reasoning proposes. Actuation validates and executes. Evaluation decides how much rope the whole system gets. As The Next Platform’s coverage put it, the stance toward agents is essentially prove yourself before you touch production.
The cut that matters: reasoning never holds the keys
The single most important decision in this architecture is that the component that thinks and the component that acts are different components with different trust models.
The reasoning engine is probabilistic. It will be wrong sometimes — that’s not a bug to fix, it’s a property to design around. It can be fed poisoned context, it can hallucinate a tool that doesn’t exist, it can be prompt-injected into wanting something destructive. If that component holds production credentials, every one of those failure modes is a production incident.
Actus is deterministic. A fixed registry, a plan format that can be statically checked, a dry-run that must pass, an authorization level that must cover the action. It cannot be talked out of its rules, because there’s no model in the enforcement path to talk to. This is the same conclusion the bounded autonomy argument reaches from first principles: guardrails that live in a system prompt are suggestions; guardrails that live in a separate enforcement layer are architecture.
If you’ve built or read about the MCP gateway pattern, Actus should look familiar — it’s a gateway with opinions: tool curation, policy enforcement, and plan verification between the agent and everything the agent can break. The validation is that Google independently converged on the same shape for the highest-stakes environment there is.
The part almost everyone skips: evaluation as the autonomy throttle
Most teams bolt evaluation on after deployment, if at all. Google made it a load-bearing component: IRM Analyzer’s judgment of agent performance determines the authorization level Actus enforces. Autonomy is not a config flag someone sets in a moment of optimism — it’s an output of measurement.
Two details are worth stealing even if you steal nothing else:
Human trajectories as ground truth. The evaluation corpus isn’t synthetic benchmarks — it’s what experienced responders actually did during real incidents. Benchmarks like ITBench are useful for comparing agents in the lab, but the distribution that matters is your incidents, and the expert baseline that matters is your on-call. Your postmortem process is already capturing half of this; it’s just not structured for evaluation. That’s fixable with process, not research.
Stratified sampling instead of vibes. Continuously pulling a representative sample of incidents for manual review means the gold data doesn’t drift toward easy cases or recent memory. It’s the same discipline we apply to SLO measurement, applied to agent judgment.
This is the mechanism that makes error budgets for autonomy enforceable rather than aspirational: a measured performance signal, a threshold, and an actuation layer that actually narrows the agent’s permissions when the signal degrades.
What to copy at normal scale
You don’t need Google’s investment to get the shape right. The mapping for a normal platform team:
- Actus → an MCP gateway with policy. One choke point between agents and tools, a curated registry per agent role, plan-level validation for anything mutating. Dry-run support already exists in most of your tooling —
terraform plan,kubectl --dry-run=server, feature-flag previews. Wire them in as mandatory, not optional. - Progressive authorization → an autonomy ladder with promotion criteria. Read-only → propose-with-approval → auto-execute-low-blast-radius → broader autonomy. Write down what evidence promotes an agent a rung, and what demotes it. Tie each rung to a real identity with scoped credentials, not a shared key that makes every rung the top rung.
- IRM Analyzer → structured incident capture. Extend your postmortem template to record the responder’s action sequence, not just root cause and follow-ups. Sample closed incidents monthly and score any agent involvement against what the humans did. That’s your gold set, and it compounds.
- Justification verification → require the agent to show its work. Every proposed action carries a machine-checkable justification linking evidence to intent. You want this in your traces anyway; making it a gate costs little once it’s captured.
Honest caveats
Google’s write-ups are describing a direction as much as a shipped steady-state, and public architecture posts always compress the failure-and-iteration mess into a clean diagram — assume the real thing is messier. The evaluation loop presumes an incident volume most organizations don’t have; with a few dozen incidents a year, your gold set grows slowly, and you should lean harder on staged environments and fault injection to generate evidence. And none of this removes the judgment call about where autonomy is worth it at all — there are still places I wouldn’t put an agent regardless of how good the guardrails are.
But the direction of the cut is the takeaway, and it generalizes: let the model reason, never let the model actuate, and let measured performance — not enthusiasm — decide how much autonomy the system earns. When the org with the most to lose from getting this wrong publishes that as its architecture, that’s the closest thing to a reference design our field has gotten yet.
Sources: Google Cloud Blog — How Google SRE is using agentic AI, sre.google — AI engineering for reliable operations, The Next Platform — SREs to AI agents: prove yourself
Comments