Google SRE Chapter 7 — The Evolution of Automation at Google

Chapter 5 told us to eliminate toil through automation. Chapter 7 takes that idea a step further: automation itself goes through an evolution, and not every stage of it is worth the same.

Automation Isn't Always Good

The chapter opens with an interesting point. A badly designed piece of automation can be more dangerous than a bad manual process, since it spreads a mistake much faster and at a much larger scale. There are examples from Google's own history here: some automation tools rolled out the wrong decision across thousands of machines at once, without ever noticing an anomaly a human operator would have caught immediately.

What Automation Gets Right, When Done Well

It brings consistency, taking human error like fatigue and inattention out of the loop. It brings speed, letting you respond far faster than any human reaction time would allow. It's reliably repeatable, doing the same thing the same way every time, and it frees up time, letting engineers focus on higher-value work, which ties directly back to Chapter 5's case for cutting toil.

The Five Stages of Automation's Evolution

This is the chapter's most original idea. Google sums up its own automation journey in a handful of stages.

At the first stage there's no automation at all, everything is done by hand. At the second stage you get external, documented, system-specific automation, scripts an engineer writes for one particular system. At the third stage those scripts become external but general-purpose, usable across multiple systems. At the fourth stage automation gets embedded into the system itself, no longer a separate tool but part of the system. And at the fifth, most advanced stage, the system is designed to not even need automation, it manages itself.

That last stage carries a critical message: the real goal isn't writing better automation scripts, it's designing systems that don't need automation at all. Automation isn't the destination, it's a temporary tool on the way to a better architecture.

The Risks That Come With It

The chapter keeps its balance here too. Automation is only as good as the depth of understanding of whoever wrote it; if the engineer never fully grasped the system, the automation won't be any more reliable than that. When a centralized automation system breaks, the blast radius can be far bigger. And maintaining automation, if managed poorly, can turn into a source of toil in its own right.

Closing Thoughts

Chapter 7 asks us to see automation not as a toolkit but as a maturity journey. The best automation, really, is automation you don't notice, once a system can manage itself without needing a separate layer for it, the actual goal has been reached.

Through a 2026 Lens: Where Do AI Agents Fit in This Model?

This five-stage model feels very familiar if you work daily with infrastructure automation, Terraform, and Crossplane. Crossplane's control-plane approach sits right between the fourth and fifth stages, automation is no longer a separate script but the system's own declarative definition. Seen this way, the entire IaC and GitOps movement looks like an industry-wide rediscovery of the path the book already mapped out a decade ago.

The genuinely interesting question is where agentic AI fits into this model. An AI agent can take a task given in plain language and go make an infrastructure change. At first glance that looks like a step toward the fifth stage, systems that manage themselves. But look closer and it might actually be a step back to the second stage, system-specific automation, just now written in natural language instead of code. The difference is that this "script" is no longer documented or deterministic, it can make a slightly different decision each time it runs. Which brings the book's biggest warning back into a new context. Automation is only as good as the understanding of whoever wrote it, or in this case, whoever's directing it. Give an AI agent an ambiguous task, and it can spread that ambiguity across thousands of machines at once, very fast, exactly like the badly designed automation the book warns about.

Which is why the book's advice on transparency and having a kill switch has never felt more relevant than it does in 2026. When you're handing AI agents authority over infrastructure, being able to see what they're doing and having a human able to step in at any moment seems like a rule that holds no matter which of the five stages you happen to be standing in.

Next time, I'll move on to Chapter 8: Release Engineering.

Thanks for reading.