runrc

Article ยท July 2026

Operational Context Engineering: The Missing Layer Between Observability and AI Ops

AI Ops needs more than copilots. It needs operational context across telemetry, topology, ownership, change history, runbooks, and governance.

Last week I chased a failure that looked trivial and wasn't.

A staging environment came up after its scheduled weekly rebuild, and the WebLogic application server couldn't reach its Oracle database. The log was unambiguous: the app's primary datasource could not be resolved. One line, one clear error, the kind an AI assistant summarizes in seconds: datasource misconfigured - check the connection pool.

That answer was fluent, plausible, and wrong.

The datasource configuration itself was fine. The real problem lived in three places the log line never mentioned: the datasource had never been bound to that particular managed server after the rebuild (topology), the rebuild itself was the change that introduced the gap (change history), and the environment depended on a separate database host finishing its own restore before anything downstream could connect (a cross-host dependency). The error I was staring at was a symptom four steps removed from the cause. Nothing in the telemetry connected those dots. I did, because I knew how the environment was assembled.

That gap between what the telemetry says and what you actually need to know to act is the entire subject of this article. It is also exactly where most AI-in-operations efforts quietly stall.

Telemetry vs. Context
Telemetry vs. Context

AI is entering infrastructure operations quickly, but the strongest signal from 2026 is not that agents can magically run production. It is that serious operators are becoming more precise about what agents need before they can be trusted.

Google SRE's May 2026 article on agentic AI says its incident investigation agents use observability data together with system topology, taxonomy, dependency data, playbooks, alerting, anomaly detection, and incident insights before forming hypotheses or proposing mitigation. That is the point. The useful AI system is not just a model over logs. It is a model grounded in the operating reality of the system.

That operating reality is what I call operational context.

Operational context engineering is the discipline of making infrastructure knowledge usable by humans and AI systems during operational decisions. It connects telemetry, topology, ownership, change history, incident history, runbooks, SLOs, policies, and governance into a form that supports better investigation and safer action.

For SRE, platform, cloud, and infrastructure leaders, the question is no longer whether AI will enter operations. It is whether the operating environment is ready for AI to be useful without becoming another noisy system to manage.

Telemetry Is Not Context

Observability is necessary. It is not sufficient.

OpenTelemetry defines the core observability signals around traces, metrics, logs, baggage, and profiles. Those signals help teams see what is happening across distributed systems. But during a real incident, engineers need answers that cross the boundary between system behavior and organizational knowledge:

Raw telemetry does not answer those questions by itself. A log line becomes operational context only when it is linked to the service that owns it, the dependency path it sits inside, the change that preceded it, the SLO it threatens, the runbook that applies, and the policy boundary around the next action.

This is the gap where many AI operations efforts stall. A model can summarize logs, but it cannot safely invent missing ownership. It can correlate alerts, but correlation is not causation. It can draft an incident summary, but a summary is not the same as a trustworthy root cause hypothesis.

Useful AI in operations needs context that is current, connected, retrievable, and governed.

Why The Market Is Moving This Way

This is not just a theoretical distinction.

Datadog's DASH 2026 announcements included Bits Memories, a capability explicitly aimed at retaining operational knowledge from investigations, runbooks, postmortems, Slack conversations, prior remediations, and similar work. The product framing is telling: live telemetry alone is not enough for the hardest incidents because teams need historical patterns and service-specific memory.

Dynatrace's 2026 agentic AI survey, as reported by ITPro, found that many agentic AI projects remain stuck in proof-of-concept and that security, privacy, compliance, and the technical challenge of managing agents at scale are major blockers. The same reporting noted that many AI-powered decisions still require human verification. Whether or not every vendor number should be taken at face value, the direction is clear: companies want AI in operations, but trust and control are the bottlenecks.

Recent research points in the same direction. SREGym, a 2026 benchmark for AI SRE agents, argues that realistic SRE evaluation needs live systems, high-fidelity failures, ambient noise, correlated failures, and diverse failure modes. ContextNest, a July 2026 paper, formalizes context governance for autonomous agents, focusing on provenance, version identity, traceability, and point-in-time reconstruction of what knowledge an agent used. A 2026 Causely benchmark argues that agents relying on raw observability data pay a semantic interpretation tax and improve when given a structured causal model of topology and dependencies.

The pattern is consistent: AI agents do better when the environment is not just observable, but interpretable.

The First Good Use Case: AI-Assisted RCA

The best first use case is not fully autonomous remediation. It is AI-assisted RCA.

RCA means root cause analysis. In practice, the near-term value is not a machine declaring the one true cause of an incident. The better first version is an assistant that gathers evidence, links related signals, checks recent changes, identifies affected services, surfaces similar past incidents, and explains which hypotheses are supported by which evidence.

That distinction matters. An AI assistant that says "database latency caused the outage" without citations is not operationally useful. An assistant that says "latency increased after deployment X, error rates rose only for services A and B, the dependency map shows both call service C, and a similar incident happened on March 12" is more useful, even if a human still makes the call.

AI-assisted RCA evidence chain
AI-assisted RCA evidence chain

An AI-assisted RCA system should be able to answer:

The lesson is not "do not use AI." The lesson is "do not confuse fluent reasoning with reliable operational evidence."

The Operational Context Stack

Operational context engineering becomes easier to discuss when we separate it into layers.

The Operational Context Stack
The Operational Context Stack

Layer 1 is the signal layer: logs, metrics, traces, events, alerts, health checks, SLOs, and error budgets. This is where most observability programs already invest.

Layer 2 is the system map: services, dependencies, infrastructure, data stores, queues, cloud resources, Kubernetes objects, network paths, and third-party systems. This tells the assistant what is connected to what.

Layer 3 is the ownership and change layer: service owners, escalation paths, on-call schedules, deployments, config changes, feature flags, infrastructure changes, and pull requests. This tells the assistant who should care and what may have caused the change in behavior.

Layer 4 is operational memory: runbooks, postmortems, tickets, known failure modes, previous mitigations, architecture decisions, and repeated incident patterns. This prevents teams from rediscovering the same lessons every quarter.

Layer 5 is governance and decision context: policies, approval boundaries, audit logs, risk classifications, compliance constraints, and human-in-the-loop rules. This tells the assistant what it may recommend, what it may execute, and what must be escalated.

Most organizations have pieces of this stack. Few have it connected well enough for AI to reason across it reliably.

The Hard Part: Keeping Context Fresh

The skeptical SRE objection is obvious: "This sounds nice, but how do you keep the context from going stale?"

That is the right objection.

Operational context engineering is not a one-time documentation project. It is an ongoing production discipline. Context has to be generated from systems of record and refreshed by operational events.

Service ownership should come from the service catalog and on-call system. Deployment and config changes should come from CI/CD, Git, feature-flag systems, and infrastructure automation. Topology should come from live discovery, tracing, service mesh data, cloud inventory, Kubernetes metadata, or declared architecture where discovery is impossible. Runbooks should be updated when incidents expose gaps. Incident memory should come from postmortems and confirmed remediation history.

Every context element should carry freshness metadata:

This is where "context engineering" differs from a CMDB reboot. The goal is not a giant repository that slowly decays. The goal is context that stays close to live workflows and proves its value during incidents.

A Practical Maturity Model

Teams do not need the whole stack on day one.

Level 1 is basic context. A team can map alerts to service ownership, recent deployments, core runbooks, and on-call paths. This is enough for better triage and escalation.

Level 2 is connected context. The team links telemetry, topology, change history, runbooks, SLOs, and incident history for one important service domain. This is enough for AI-assisted RCA and better post-incident review.

Level 3 is governed context. The team adds freshness checks, evidence citations, approval boundaries, audit trails, and evaluation sets. This is where regulated industries and larger enterprises need to land before trusting AI with higher-impact recommendations.

The right first move depends on the segment.

Startups need lightweight context before tribal knowledge disappears. Growth-stage SaaS companies should focus on alert fatigue, ownership, and change history. Mature SaaS and platform teams need cross-team consistency, evaluation sets, and context quality checks. Enterprises need scoped pilots across ITSM, CMDB, observability, cloud, and security tooling. Regulated organizations need decision provenance, auditability, and human approval before autonomy.

The common theme is simple: context first, autonomy later.

A Credible Pilot

A practical pilot should be narrow enough to evaluate.

Start with one critical service or platform domain. Pick one incident workflow. Choose one primary outcome, such as reducing time to triage or improving escalation accuracy. Keep the assistant read-only or recommendation-only until it proves useful.

The minimum useful context set is:

The pilot should not be judged by whether the AI sounds smart. It should be judged by operational outcomes:

The key metric I would add is context freshness score: how current were the topology, ownership, runbook, SLO, and change-history elements used in the recommendation? If the assistant used a stale owner or an old dependency map, the output should be downgraded even if the prose was convincing.

The Counterarguments

The strongest objection is that observability platforms already solve this. In some areas, they do. Modern observability and incident platforms are adding AI features quickly, and many will become better at summarization, anomaly detection, alert grouping, operational memory, and workflow automation.

But no vendor automatically knows your real service ownership, your informal escalation practices, your stale runbooks, your regulatory boundaries, your last three painful incidents, or the deployment that everyone knows was risky but never documented properly.

Another objection is that agents will infer the missing context automatically. Sometimes they will infer pieces of it. But operational decisions need trusted sources, not plausible guesses. In incident response, false confidence can be worse than uncertainty.

A third objection is that this sounds like another CMDB project. That warning is useful. The answer is not to build a giant enterprise knowledge graph before doing anything. The answer is to keep context close to live workflows: service catalogs updated from code, ownership from on-call systems, changes from CI/CD, runbooks from actual incident use, and incident memory from postmortems.

The context layer should earn its keep through operational workflows, not exist as a documentation museum.

The Better Question

The wrong question is:

"How do we add AI to infrastructure operations?"

The better question is:

"What operational context would AI need to help us make better decisions during an incident?"

That question changes the work. It moves the conversation away from generic copilots and toward the actual operating system of modern infrastructure: signals, systems, ownership, changes, memory, governance, and trust.

AI in infrastructure operations will create real value. But the value will not come from models alone. It will come from teams that make operational context clean, current, retrievable, and governed enough for AI to use.

The future of AI Ops is not magic.

It is context, discipline, evidence, and trust.

Sources