Google's Gemini SRE Playbook: A Reference Architecture for AI in Incident Response

Two Google SREs, Riccardo Carlesso and Ramon Medrano Llamas, have published a detailed account of Gemini 3 operating inside an incident response workflow, driven through Gemini CLI and an internal agent framework called ProdAgent. The Google walkthrough traces one incident through its full lifecycle, from the initial page to the exported postmortem, and the accompanying research abstract states that the incident is simulated. The document is therefore a design specification: the operating model Google intends for AI in outage response, demonstrated in a controlled scenario, published by the team that owns the workflow.

The workflow, stage by stage

The published lifecycle runs through five stages:

• Paging and investigation. Gemini retrieves the incident details, analyzes causal relationships and time-series correlations, and examines logs.
• Mitigation. The agent selects a predefined mitigation, in the example a task restart analogous to restarting a Kubernetes pod, and proposes the action.
• Approval and execution. Every production mutation runs behind risk metadata, policy checks, reversibility rules, and an explicit human confirmation.
• Root cause analysis and repair. Gemini correlates recent changes with production evidence, identifies a configuration-related logic error, generates a code change, and stages it for human review.
• Postmortem. The agent assembles conversation history, metrics, and logs into a timeline, proposes action items, files bugs, assigns owners, and exports the document.

At every stage that touches production, the human verifies and approves the proposed action. The agent investigates, proposes, and documents; the operator executes.

The read path is wide, the write path is narrow

Two structural decisions define the design. The agent's read access is broad: incident records, telemetry, logs, playbooks, change history, and issue tracking. Its write access is tightly bounded: predefined mitigations only, each wrapped in risk metadata and reversibility rules, each gated on a human.

The broad read path produces the speed. Connected to that operational context, the agent compresses the interval between an alert, a usable picture of the incident, and a safe first action. That interval is where Mean Time to Mitigation lives, and where customer-facing minutes accumulate while an engineer assembles the same picture by hand across dashboards.

The narrow write path produces the trust. Because every action is proposed, policy-checked, and approved, the workflow generates a complete record of what the agent recommended and what the operator accepted. That record makes the agent's judgment measurable over time, which is the mechanism that lets a team expand the agent's autonomy on evidence instead of on faith.

The architecture also encodes a clean division of labor. Correlating deployments, tickets, telemetry, and timelines is assembly work, and the agent handles all of it. Deciding whether to roll back, patch, or wait requires context the telemetry does not carry: customer impact, risk tolerance, what else is in flight. Those decisions stay with the engineer at every stage of Google's design.

Context quality decides whether any of this is safe

The workflow's safety rests on assumptions stated nowhere in its stage list: the agent can see an accurate dependency map, current runbooks, a complete change history, and enforceable policy. An agent proposing production mutations on top of stale topology produces wrong answers at high speed, formatted with the confidence of right ones.

That constraint orders the work for any team adopting the pattern. Building and maintaining the context layer, then wiring policy checks and reversibility into the execution path, is the bulk of the engineering. Mapping one organization's systems into the agent's context and encoding its governance rules stays with each team, and it has to be done before the approval gate means anything.

What the playbook establishes

Google originated SRE as a discipline, so a first-party account of its own SREs putting an agent inside the incident loop functions as a reference architecture for the industry. The architecture it commits to is propose-and-approve: wide operational context, a bounded and reversible action set, a human on the gate, and an audit trail underneath. For teams evaluating AI in incident response, the five stages double as a requirements checklist: read access to incident state, telemetry, and change history; a constrained action set with defined rollback; explicit approval on every production mutation; and postmortems that feed action items back into the tracker.

NeuBird AI's Production Ops Agent is built on the same operating model: reason over the live environment, surface the causal chain, and keep a human on the approval. Teams running on Google Cloud can see how the pattern applies in a GCP environment, and a self-service AI SRE trial on AWS walks through the same propose-and-approve loop end to end.

Sources: Google - How Google Sres Use Gemini Cli To Solve Real World Outages · Research - How Google Sres Use Gemini Cli To Solve Real World Outages