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, 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, real-time knowledge graph of all four bodies and the edges between them. The value is in the edges: A commit changes a service. Terraform provisions new infrastructure. Kubernetes rolls out the deployment. OpenTelemetry traces begin showing increased latency while Prometheus records SLO burn. The graph connects those events with a similar incident six months earlier and the remediation that resolved it. The graph has to be active, because yesterday’s view isn’t today’s world. And it has to be versioned, because every agent decision is made against a specific snapshot, and you’ll need to replay it. Without the graph, agents are slick demos. With it, they become possible: reasoning across all four bodies, acting within policy and blast-radius limits, and writing every result back so the next loop is better. Trust is a decision trace If the substrate is the graph, the thing that earns trust on top of it is auditability. The failure mode is real: a lot of impressive “autonomy” is a script with an LLM in the middle, where the prompt was different last Tuesday, the model version bumped on Thursday, and nobody captured the input context. That’s not production autonomy. It’s opaque automation whose behavior can’t be reliably reproduced or audited. The non-negotiable architectural commitment is the decision trace. For every action an agent takes, you need a durable record of: - The inputs it saw (which snapshot of the graph) - The policies in effect at the time - The model version used - The hypotheses it considered and rejected - The action it took, and the outcome This isn’t a compliance nicety. It’s exactly what your CISO, your risk officer, and your regulator will ask for the first time an agent does something interesting in production. Autonomy you can’t defend is autonomy you don’t actually have. This is also where the much-hyped metrics conversation finally fits. When agents reason over the four bodies continuously, embedded in the path rather than writing the post-mortem after it, incidents get rarer, and 2 a.m. pages become the exception. The number worth watching shifts from how fast you recover toward how often you never had a bad night. But that’s a consequence of getting the substrate and the traces right. It’s not where you start. The path So how do you get from eight-vendor bridge calls to autonomous operations? Two principles. - Treat operations as data. Stop letting code, infrastructure state, runtime signals, and operational knowledge live as four siloed, mutually-suspicious stacks. Integrate them into a unified knowledge graph you can query, version, and reason over. Agents come next, not first. Without that substrate, no agent will be trustworthy enough to put in the critical path. - Embed agents in the path to production, not after it. “Human does the work, agent writes the post-mortem” isn’t autonomy; it’s dictation. Agents have to reason over code, Infrastructure as Code, Kubernetes state, OpenTelemetry telemetry, Prometheus metrics, and operational memory as a continuous loop (one that makes incidents rarer in the first place), and every decision they take has to add a trace that makes the next decision better. Will we reach fully autonomous operations in 2026? No. But the trajectory is clear, and it doesn’t scale with more humans. It scales with better context and trustworthy agents acting on it. Don’t start with the agents. Start with the graph. Start with the four bodies. The agents will follow, and when they do, they will actually work.