The 4-body problem of SRE: Why autonomous operations depend on context

What a room full of senior SREs confirmed about the trust gap, and where the actual work begins I spent a day last week at an event in Bengaluru asking a room full of senior SREs,... What a room full of senior SREs confirmed about the trust gap, and where the actual work begins I spent a day last week at an event in Bengaluru asking a room full of senior SREs, platform engineers, and engineering leaders a single unglamorous question: where does AI SRE actually stand right now? When you put that to people who run real systems (not analysts, not vendors doing demos) you don’t get a tidy story about recovery times dropping. You get agent failure horror stories. You get a hard look at stale runbooks and institutional memory that lives in three engineers’ heads. And you get teams who are all somewhere on a ladder from “AI assists me” to “AI acts on its own,” none of them entirely sure what it takes to climb. Across the discussions, panels, and hallway conversations, the same theme kept resurfacing: AI’s biggest challenge in operations isn’t model capability. It’s context. The framework I kept returning to throughout the day is something I’ve started calling SRE’s 4-Body Problem . Here’s what it is, and why I think it explains both the promise and the limits of autonomous operations today. Why operations is a four-variable problem A few years ago, I sat on an incident bridge at two in the morning with eight vendors on the line, a 200-row RACI spreadsheet, and every party showing green dashboards for their own slice of the world.  Two cloud vendors blamed each other. One orchestration vendor dropped off the call the moment it heard a competitor’s cloud was in scope. The actual root cause was hiding in a subcontracted network telemetry stream that nobody had integrated into anyone’s observability. That night taught me two things: no single party has the whole picture, and no human (howe

What a room full of senior SREs confirmed about the trust gap, and where the actual work begins I spent a day last week at an event in Bengaluru asking a room full of senior SREs,... What a room full of senior SREs confirmed about the trust gap, and where the actual work begins I spent a day last week at an event in Bengaluru asking a room full of senior SREs, platform engineers, and engineering leaders a single unglamorous question: where does AI SRE actually stand right now? When you put that to people who run real systems (not analysts, not vendors doing demos) you don’t get a tidy story about recovery times dropping. You get agent failure horror stories. You get a hard look at stale runbooks and institutional memory that lives in three engineers’ heads. And you get teams who are all somewhere on a ladder from “AI assists me” to “AI acts on its own,” none of them entirely sure what it takes to climb. Across the discussions, panels, and hallway conversations, the same theme kept resurfacing: AI’s biggest challenge in operations isn’t model capability. It’s context. The framework I kept returning to throughout the day is something I’ve started calling SRE’s 4-Body Problem . Here’s what it is, and why I think it explains both the promise and the limits of autonomous operations today. Why operations is a four-variable problem A few years ago, I sat on an incident bridge at two in the morning with eight vendors on the line, a 200-row RACI spreadsheet, and every party showing green dashboards for their own slice of the world.  Two cloud vendors blamed each other. One orchestration vendor dropped off the call the moment it heard a competitor’s cloud was in scope. The actual root cause was hiding in a subcontracted network telemetry stream that nobody had integrated into anyone’s observability. That night taught me two things: no single party has the whole picture, and no human (however senior) can hold the whole picture at 2:07 a.m. Every meaningful decision in operations requires reasoning across four tightly coupled bodies of truth at once: Code: Every commit, PR, branch, build artifact, version, and configuration change. What was deployed, when, and what was different from yesterday? Infrastructure state: The actual, current shape of cloud accounts, networks, Kubernetes clusters, queues, databases, and IAM policies. What does Terraform say should be there, and what is actually there, right now? Runtime signals: Metrics, logs, traces, events, error budgets, SLOs, and customer-impacting alerts. What is the system doing right this second, and when did it start behaving differently? Operational knowledge: The tribal wisdom, post-mortems, architectural decision records, on-call playbooks, the “we tried that in 2022 and took out the region,” the runbooks, the Slack threads that explained why a thing is the way it is. Each body, in isolation, is mostly solved (Git, Terraform, your observability stack, Confluence). The problem is that every real decision sits at the intersection of all four, and the intersection is where we have historically had no system at all. Like the three-body problem in physics, adding the fourth mass doesn’t make it incrementally harder; it makes the dynamics qualitatively different. The only thing that has ever navigated it reliably is a handful of senior engineers whose brains track all four bodies simultaneously: expensive, scarce, and gone every two years. We hold the gap together with what I’ve started calling “people putty”: tribal knowledge in a few heads, and runbooks that drift stale the moment the next infra change lands. Almost every session that day was, underneath, a story about people putty failing under load. What the day confirmed The conversations throughout the day became a tour of the four bodies and the trust gap between them. Discussions kept returning to the root-cause problem that sits at the heart of autonomous operations.   The questions they worked were the ones that decide whether any of this is real in production: How far can you actually trust an agent to run an automated RCA? How completely does that trust depend on the quality of the data the agent reasons over? The recurring shape of the war room is the bridge call I described: the answer is rarely in the body you’re staring at. Faster RCA isn’t a smarter-dashboard problem. It’s a cross-body correlation problem. Agents should erase the war room not by paging faster, but by having SLO-anchored RCA hypotheses ready before the first human even joins the bridge. The conversation around agent failure stories surfaced what no product deck includes: Agents that confidently fix the wrong thing. Agents that demo beautifully and fall apart against a real, messy incident. Agents whose reasoning you can’t reconstruct afterward. When the context an agent reasons over is fragmented, it doesn’t just fail. It plausibly fails, which is the kind of error that survives review. The discussions about operational knowledge and trust repeatedly pointed in the same direction. Stale runbooks are arguably worse than none, because they invite confident, wrong action. And the broader trajectory was equally clear: most organizations are somewhere between copilots and autopilots. Almost everyone is mid-climb. The question is what earns you the next rung. The substrate comes before the agents Here’s the conclusion I keep arriving at, and the room largely shared it: the bottleneck isn’t model quality. You can’t put an agent on top of four siloed, mutually-suspicious systems and expect reliability. An agent is only as good as the context it can reason over. Fragmented context produces hallucination, often the plausible kind. So the foundational work isn’t buying agents. It’s building the substrate they read and write against: a unified,

What a room full of senior SREs confirmed about the trust gap, and where the actual work begins I spent a day last week at an event in Bengaluru asking a room full of senior SREs,... What a room full of senior SREs confirmed about the trust gap, and where the actual work begins I spent a day last week at an event in Bengaluru asking a room full of senior SREs, platform engineers, and engineering leaders a single unglamorous question: where does AI SRE actually stand right now? When you put that to people who run real systems (not analysts, not vendors doing demos) you don’t get a tidy story about recovery times dropping. You get agent failure horror stories. You get a hard look at stale runbooks and institutional memory that lives in three engineers’ heads. And you get teams who are all somewhere on a ladder from “AI assists me” to “AI acts on its own,” none of them entirely sure what it takes to climb. Across the discussions, panels, and hallway conversations, the same theme kept resurfacing: AI’s biggest challenge in operations isn’t model capability. It’s context. The framework I kept returning to throughout the day is something I’ve started calling SRE’s 4-Body Problem . Here’s what it is, and why I think it explains both the promise and the limits of autonomous operations today. Why operations is a four-variable problem A few years ago, I sat on an incident bridge at two in the morning with eight vendors on the line, a 200-row RACI spreadsheet, and every party showing green dashboards for their own slice of the world.  Two cloud vendors blamed each other. One orchestration vendor dropped off the call the moment it heard a competitor’s cloud was in scope. The actual root cause was hiding in a subcontracted network telemetry stream that nobody had integrated into anyone’s observability. That night taught me two things: no single party has the whole picture, and no human (however senior) can hold the whole picture at 2:07 a.m. Every meaningful decision in operations requires reasoning across four tightly coupled bodies of truth at once: Code: Every commit, PR, branch, build artifact, version, and configuration change. What was deployed, when, and what was different from yesterday? Infrastructure state: The actual, current shape of cloud accounts, networks, Kubernetes clusters, queues, databases, and IAM policies. What does Terraform say should be there, and what is actually there, right now? Runtime signals: Metrics, logs, traces, events, error budgets, SLOs, and customer-impacting alerts. What is the system doing right this second, and when did it start behaving differently? Operational knowledge: The tribal wisdom, post-mortems, architectural decision records, on-call playbooks, the “we tried that in 2022 and took out the region,” the runbooks, the Slack threads that explained why a thing is the way it is. Each body, in isolation, is mostly solved (Git, Terraform, your observability stack, Confluence). The problem is that every real decision sits at the intersection of all four, and the intersection is where we have historically had no system at all. Like the three-body problem in physics, adding the fourth mass doesn’t make it incrementally harder; it makes the dynamics qualitatively different. The only thing that has ever navigated it reliably is a handful of senior engineers whose brains track all four bodies simultaneously: expensive, scarce, and gone every two years. We hold the gap together with what I’ve started calling “people putty”: tribal knowledge in a few heads, and runbooks that drift stale the moment the next infra change lands. Almost every session that day was, underneath, a story about people putty failing under load. What the day confirmed The conversations throughout the day became a tour of the four bodies and the trust gap between them. Discussions kept returning to the root-cause problem that sits at the heart of autonomous operations.   The questions they worked were the ones that decide whether any of this is real in production: How far can you actually trust an agent to run an automated RCA? How completely does that trust depend on the quality of the data the agent reasons over? The recurring shape of the war room is the bridge call I described: the answer is rarely in the body you’re staring at. Faster RCA isn’t a smarter-dashboard problem. It’s a cross-body correlation problem. Agents should erase the war room not by paging faster, but by having SLO-anchored RCA hypotheses ready before the first human even joins the bridge. The conversation around agent failure stories surfaced what no product deck includes: Agents that confidently fix the wrong thing. Agents that demo beautifully and fall apart against a real, messy incident. Agents whose reasoning you can’t reconstruct afterward. When the context an agent reasons over is fragmented, it doesn’t just fail. It plausibly fails, which is the kind of error that survives review. The discussions about operational knowledge and trust repeatedly pointed in the same direction. Stale runbooks are arguably worse than none, because they invite confident, wrong action. And the broader trajectory was equally clear: most organizations are somewhere between copilots and autopilots. Almost everyone is mid-climb. The question is what earns you the next rung. The substrate comes before the agents Here’s the conclusion I keep arriving at, and the room largely shared it: the bottleneck isn’t model quality. You can’t put an agent on top of four siloed, mutually-suspicious systems and expect reliability. An agent is only as good as the context it can reason over. Fragmented context produces hallucination, often the plausible kind. So the foundational work isn’t buying agents. It’s building the substrate they read and write against: a unified,