The 4-Body Problem of SRE: Why Autonomous Operations Require Unified Context

The physics concept that gives this framing its name is apt: in a three-body gravitational system, predicting motion is already intractable. Add a fourth body and the complexity becomes qualitatively different. The same dynamic applies to SRE decision-making — and most teams are trying to automate it without first solving for context.

How It Works

The CNCF analysis from Dotan Horovitz identifies four “bodies” of operational knowledge that any SRE agent must reason across simultaneously:

Code — commits, pull requests, branches, build artifacts, versions, and configuration changes. Every deployment creates a new state of this body.

Infrastructure State — cloud accounts, networks, Kubernetes clusters, databases, and IAM policies. Both the desired state (what Terraform says should be true) and the actual state (what’s running right now) are required, and they frequently diverge.

Runtime Signals — metrics, logs, traces, events, error budgets, SLOs, and alerts. This is the body that observability platforms optimize for, and it’s well-instrumented in most mature orgs.

Operational Knowledge — post-mortems, architectural decisions, runbooks, and the tribal wisdom that senior engineers hold in memory. This body is the least structured and the hardest to surface programmatically.

Each body is individually well-addressed by existing tooling. Git, Terraform, Datadog, and Confluence handle one body each. The problem is that decisions — real incident response, deployment risk assessment, capacity planning — require reasoning across all four at the same time.

What This Means for You

The bottleneck in autonomous operations isn’t model quality. As the CNCF analysis puts it: “the bottleneck isn’t model quality.” The gap is that organizations currently bridge the four bodies through “people putty” — senior engineers who hold the cross-body context in their heads, bridging fragmented systems through experience and pattern recognition.

This arrangement is expensive, scarce, and unsustainable as infrastructure complexity scales. It’s also what makes autonomous agents produce plausible-sounding but wrong answers: they have access to some bodies of context but not others, and they reason fluently within the gap.

The path forward isn’t better models — it’s context infrastructure. Horovitz argues for three specific changes before deploying operational agents:

Unified knowledge graph — connecting all four bodies with real-time, versioned data about the relationships between commits, infrastructure changes, deployments, and observable system behavior. Not four separate APIs, but a queryable graph of their intersections.

Decision traces — recording inputs, policies, model versions, considered hypotheses, and outcomes for every agent action. This makes autonomous decisions auditable and learnable, rather than black-box.

Integration into production paths — agents embedded in live incident response and deployment workflows, not limited to post-incident analysis where the consequences of errors are lower.

This pattern is consistent with what’s emerging across AWS DevOps Agent deployments and Google’s SRE agentic operations research: the organizations making progress on autonomous ops have treated context engineering as the primary problem, not model selection.

Source: CNCF

Content created with AI assistance and reviewed for accuracy.