The rule sounds simple: an SRE spends less than half their time on toil, the rest on engineering work. The same chapter holds a second number that rarely gets quoted. Quarterly surveys inside Google put average toil at roughly 33% — the organisation lives well below its own limit. The 50% there is not a budget to spend but a line past which people start asking what broke.
Then there is a third number, the awkward one.
The ceiling has a floor
On-call produces toil that cannot be automated away, because it consists of being available. The book does the arithmetic outright: in a six-person rotation each engineer takes two weeks out of six — primary and secondary — so the lower bound on toil lands at 2/6, about 33%. With eight people it is 2/8, 25%.
The same formula yields something the book does not spell out. Four people on call under the same shift structure gives 2/4, exactly 50%. The team sits at the ceiling before anyone opens the ticket queue. Three people gives 67%, and that is no longer an automation problem.
The caveat matters: the arithmetic counts primary plus secondary. Where no second line exists and one person carries the shift, the bound is half that — 1/N. Even so, 25% with four people means half the permitted budget is consumed by the schedule alone.
For a small platform team the conclusion is unpleasant: "we have too much routine work" often describes the size of the rotation rather than the quality of the tooling. No agent changes 2/4.
What an AI agent actually removes
The same text ranks the sources of toil. Top of the list is not incidents but interrupts: non-urgent service questions, mail and messages. On-call response comes next, and only then releases and pushes.
First place is precisely the work that ends with an investigation and no change. "Did this version reach production?", "why is the pod restarting", "what changed in the last hour", "is the drift on this cluster still there". The answer already exists in the cluster, the metrics and the deployment history; a human spends minutes plus a context switch on it, and the system is left in the same state afterwards — the definition of toil is satisfied in full.
A read-only agent fits here: it answers without changing anything, and the decision stays with a person. The mechanics of that access are a separate conversation; what matters here is the accounting.
The trap: "this one needs judgement"
The standard way to move work out of the toil budget is to say it requires human judgement. The book closes that loophole in a footnote: the thing to check is whether judgement is intrinsic to the task, or required because the system was designed badly. A service that calls out an on-caller several times a day for a complex response is described there as poorly designed, and the response itself stays toil until the redesign ships.
Hence a risk worth weighing before adoption rather than after. An agent that performs that analysis daily in place of a human makes a badly designed system comfortable. Toil measured in human-minutes drops. The cause that produced it stays where it was, and the pressure to redesign leaves along with the pain.
The practical consequence is in what you count. Minutes will show an improvement, because minutes are exactly what the agent took. Count the number of investigations: how many times a week someone — a human or an agent — had to work out why the system is in this state. That figure does not move when an agent is installed; it moves when the cause is fixed. How a metric turns into a target and stops working, I covered separately.
Read-only is not a synonym for safe
One detail breaks hand-rolled roles. The built-in Kubernetes ClusterRole view deliberately withholds Secrets: reading a secret's contents hands over ServiceAccount credentials and the ability to call the API under that identity. The documentation files this under privilege escalation, not under reading.
A role assembled by hand as "get, list, watch on everything" includes secrets. It is read-only on paper while handing the agent material for acting as somebody else. Everything read also lands in the model's context — logs, environment variables, configs — which is why noisy alerts are worth fixing before an agent is connected rather than after (on firing modes).
What to do with this
Work out your own floor: rotation size, whether a secondary exists. If it sits near 50%, the conversation about agents is premature — the roster comes first. If there is headroom, hand the agent your interrupts: the largest single source of toil, and the only one where reading solves the task outright. And keep a separate count of investigations, so a fixed cause can be told apart from a neatly hidden one.