Why Context Is at the Heart of Automated RCA

An AI SRE investigating an alert in systems it doesn't know is querying blind. It doesn't know that checkout calls payments, which dashboard is canonical, or what was deployed yesterday. Every question an engineer would answer from memory becomes a discovery task.

Most of what reads as intuition in a good on-call engineer is accumulated knowledge of the system. They don't search the whole system; they check the three things that are usually the problem. An agent without that knowledge is running an open-ended search against a system it's meeting for the first time, during an outage.

Context is what closes the gap in automated RCA. It's what the agent knows about your systems before and during an investigation.

Key facts

• Context is what an automated RCA agent knows about your systems before and during an investigation.
• Its three working parts are a context graph of your systems, fluency with your observability tools, and context engineering that controls what the model sees at each step.
• Roughly 70% of outages follow a change to a live system, which makes change history the highest-value context an agent can hold.
• Every source the graph is derived from is partial, so the graph is a continuously reconciled product of all of them, not a config file someone maintains.
• A standing context graph, built before the alert fires, avoids spending the outage on discovery.
• Scoped, context-aware queries are what keep model and observability costs under control.

What an investigation agent needs to know to automatically get to RCA

Context is everything the agent knows about your systems before and during an investigation, and it comes in three types.

• Production systems context. What your systems are and what they're doing. Services, dependencies, ownership boundaries, change history, what each service's custom metrics measure, what its errors mean. It's derived from telemetry, code, and cloud infrastructure, which means it can be built by machine and refreshed continuously. It also changes fastest.
• Operating context. How your team runs production. Which alerts are known noise and during what window, who owns what and who they escalate to, what your severity levels actually mean in practice, which actions are pre-approved and which need a human, which dashboards are canonical and which nobody has maintained in a year. None of this is in telemetry. It lives in runbooks, retros, Slack threads, and the heads of the people who have been on the rotation longest. This is what turns a correct answer into an actionable one.
• Investigation context. What previous investigations established. Confirmed causes, engineer corrections, hypotheses that looked right and weren't, dependencies that no source documented until an incident exposed them, which query actually answers a given question in your environment. It doesn't exist before the agent runs, which makes it the only type that can't be acquired at setup.

Change history earns its place in that first type. Google's SRE book puts roughly 70% of outages down to a change in a live system, so "what changed near the blast radius in the last few hours" is the single highest-value question in most investigations. Answering it means connecting systems that don't naturally communicate with each other, such as deployment pipelines, flag services, and telemetry.

Resolve AI's architecture holds that context with three working parts.

• A context graph of your systems. The services, their dependencies, ownership, and change history, derived from telemetry, code, and cloud infrastructure.
• Tool fluency. The agent queries your actual stack, with tools such as Datadog, Splunk, Grafana, and Kubernetes in it, not through generic API calls but the way an engineer who uses those tools daily would.
• Context engineering. Deciding what enters the model's window at each step of the investigation, so the model sees signal instead of raw log dumps.

The context graph is how production systems context gets stored and traversed. Operating context comes in through the sources you connect, the runbooks, docs, and channels where the team works. Investigation context accumulates as the agent works and gets folded back into what the system knows. Context engineering is how the right slice of all three reaches the model at each step. Neither the graph nor the engineering is a kind of context. They're how context gets stored and delivered.

Shallow versions of context get sold under the same word. Some tools treat context as retrieving doc snippets when a question comes up, or as pasting raw telemetry into the prompt. That simply isn't enough true context for a production environment. Neither gives the agent a model of your systems.

Context sits in the middle of that architecture for a reason. It is what models use to reason about your production environment, and learning writes what each investigation finds back into it.

Why investigations fail without context

Picture a checkout latency alert handed to an agent with no context. It pulls checkout's logs, finds nothing unusual, and reports that. The actual cause is a payments deploy from twenty minutes earlier, one hop upstream, and the agent never looked there for a simple reason. Nothing told it checkout calls payments.

That's what missing production systems context looks like. Each of the three types fails in its own way:

1. Missing production systems context. Without the dependency map, the agent can't get from symptom to cause across service boundaries. Every hop is a guess, and most production root causes sit two or three services away from the alert. The checkout example is this failure.
2. Missing operating context. The agent correctly identifies a cause in a service owned by another team, and either routes it to the team listed in a stale catalog or doesn't route it at all, so the finding sits in a channel until someone reads it. Or it flags a nightly batch anomaly the team has ignored for two years, and the on-call engineer stops reading its output.
3. Missing investigation context. The agent re-derives the same dependency map for the fortieth time, or repeats a hypothesis that a previous investigation already disproved, because nothing carried forward.

There's a cost failure on top of all three. An agent that doesn't know where to look runs unscoped queries against massive log volume, and model costs and observability query fees blow up fast.

In practice, those failures look like this:

• The agent investigates the wrong service because two share a name prefix.
• It treats a dashboard nobody has maintained in a year as ground truth.
• It pulls half a million tokens of logs, summarizes them into mush, and misses the one deploy event that mattered.
• It finds the correlation (CPU spiked) but not the cause (the deploy that introduced the spike), because deploy data was never connected to telemetry.
• It silently excludes an entire class of hypotheses because one tool wasn't connected, and nothing in the output indicates as much.

The three types of context go stale at different rates

Production systems context needs continuous derivation, because the environment changes underneath it constantly. Autoscaling replaces nodes hourly, deploys land daily, and services appear and disappear, which is why manually curated service catalogs rot within weeks. A dependency map from last month produces confidently wrong hypotheses, so this type has to be rebuilt by machine, continuously, from telemetry, code, and cloud infrastructure.

Operating context has no automatic refresh, which is why it's the type that fails silently. Some of it comes from engineers telling the system, and some can be inferred from behavior. If an alert fires two hundred times and is acknowledged and closed without action every time, that is the team telling the system it's noise. Resolve AI takes both routes, explicit feedback from engineers plus signals inferred from how the team works. Ask any vendor which parts they infer and which require a human, because a vendor claiming operating context updates itself is not credible.

Investigation context only accumulates, and its risk runs the other way. A wrong learning compounds, because a bad heuristic gets applied to every investigation after it. So it needs correction mechanisms, engineers able to overrule what the system learned, and evals that catch a learned heuristic that stopped being true.

Why RAG and raw telemetry both fall short

Two shortcuts get sold as context.

The first is retrieval. RAG answers similarity questions. “Find docs that mention checkout errors” works fine. “What depends on payments-db two hops out” doesn't, because that's a graph traversal, and nearest-neighbor search over text can't perform one. The structure has to exist before you can query it.

Retrieval also can't do identity resolution. The same service is checkout-svc in Kubernetes, checkout in Datadog, payments/checkout-service on GitHub, and “the cart” in Slack. Joining evidence across tools means resolving all of those into a single entity, and that's preparation work. Doing it for the first time mid-outage means spending the outage on it.

Resolving those names is also harder than it sounds. Some joins come from shared tags or trace metadata; some from naming conventions; and some have to be confirmed against deploy manifests and then maintained as services get renamed and split. Getting it mostly right isn't enough. At 90% accuracy, one join in ten attaches the wrong service's evidence to a hypothesis, and the resulting chain still reads as coherent. The agent doesn't know it's reasoning about the wrong system, and neither does anyone reading the output.

The second shortcut is loading everything into the model, and it fails in three ways.

1. Cost. You pay per token on the model side and per query on the observability side, and production log volume makes both explode.
2. Accuracy. Models degrade with long contexts, recall the middle poorly, and get distracted by irrelevant material. Past a point, more context makes answers worse.
3. Signal. A million raw log lines contain maybe five patterns worth reasoning about, and the model shouldn't be the thing doing that compression at full price.

Context engineering is the discipline that deals with this. In practice, it means a few habits:

• Cluster and summarize logs before the model sees them.
• Scope queries to the graph neighborhood of the alerting service.
• Expand the search hop by hop as hypotheses demand, rather than loading the world up front.
• Hold each investigation step to a token budget and select evidence against it.

Standing context vs. context assembled per incident

There are two ways to give an agent all of this. Assemble it when the incident starts, connecting sources, fetching data, and summarizing on the fly. Or maintain a standing context graph, built and updated before the alert ever fires.

The difference is best shown in multi-hop investigations. Follow the checkout example one hop:

• Without a graph, to even look at payments, the agent first has to establish that payments is worth looking at, which means pulling traces for the window and hoping the path is instrumented, or reading checkout's config and code for what it calls. Then it has to find payments in each tool, the right Datadog service, the right log index, the right dashboard. Only then can it query for actual evidence. That's minutes of setup before a single relevant log line gets read, and it repeats at every hop.
• With a standing graph, each of those steps is already done. Checkout's neighbors are an edge lookup, and every service is already resolved to its names in each tool, so the agent goes straight from hypothesis to evidence. Following a failure three services deep costs the same as one hop, because the map and the joins exist before the alert fires.

A tool that assembles context per incident pays that discovery cost during the outage, and the discovery time counts against your MTTR.

No single source is the graph. The graph is the reconciliation of all of them, cross-checked and continuously refreshed, which is why it's derived infrastructure rather than a config file someone maintains.

What context does to the investigation

Context cuts the investigation down before reasoning starts. If the agent knows the alerting service has four dependencies and two of them deployed today, it has a short list of likely causes to check first. Without that knowledge, it has to consider everything.

Baselines help similarly. If the agent knows what normal looks like for this service at this hour and which alerts are noise, it can ignore most of the anomalies it finds. Without that, every unusual number looks like it might be the cause, and the agent wastes time on things an experienced engineer would ignore immediately.

Context also lets the agent admit when it can't find the answer. Saying the cause isn't visible in the available data requires knowing what data is available, which sources exist, what they cover, and what they don't. An agent without that knowledge will always produce some answer from whatever it can reach.

This is the relationship between the context layer and the reasoning layer. Reasoning works by considering candidate causes and testing them against evidence. Context is what keeps the candidate list short and the evidence relevant.

Where memory fits

Memory and context are related but not the same thing. Memory is what the system learns across investigations, confirmed causes, engineer corrections, and dependencies that an incident exposed. Context is the working set the agent uses during this investigation, drawn from the context graph, live telemetry, and memory. What memory learns gets written into the graph, which is how past investigations improve future context.

What context changes in practice

With context in place, an investigation runs differently:

• An alert fires, and the agent already knows the affected service, what it depends on, and what was deployed recently, so there's no discovery phase.
• It runs scoped queries against the right telemetry rather than trawling through everything.
• It follows the dependency chain across services, checking each hypothesis against evidence.
• The engineer gets ranked hypotheses with evidence attached within minutes of the alert.

The results are a faster path to the cause, fewer escalations to senior engineers who hold system knowledge, and a lower cost per investigation because the agent only queries what matters.

How to evaluate context in an automated RCA tool

• Where does it get your operating context? Which alerts are noise, who owns what, what's pre-approved. Ask what happens after a reorg.
• What does it retain from one investigation to the next, and can you see what it has learned and correct it?
• Does it build a model of your systems before the first incident, or start cold? A tool that learns your architecture during the outage is spending your MTTR on discovery.
• Does it connect change data to telemetry? If deploys, flags, and config changes aren't linked to the metrics they affect, the most common root cause class remains invisible.
• Does it query your tools in place, or require you to centralize data first? Migration projects delay value and add another pipeline to maintain.
• How does its picture of your systems stay up to date? Ask what happens after a deploy, a scaling event, or an infrastructure change.
• Can it tell you what it can't see? A system that knows its blind spots can abstain honestly. One that doesn't will produce a confident answer from whatever it can reach.
• Does cost scale with your log volume? Context engineering should keep queries scoped, so growth in telemetry doesn't translate directly into growth in spend.

Few vendors will show you their model of your systems, how it was derived, or when it last updated. Until that changes, ask to see the graph built on your own stack during a trial, and watch what happens to it after your next deploy.

How Resolve AI builds context

Resolve AI builds context as a standing layer. Its agents maintain a context graph of your services, dependencies, and changes, derived from your telemetry, code, and cloud infrastructure, and they query your tools natively, from Datadog and Splunk to Kubernetes. Context engineering keeps each investigation step scoped to the evidence that matters.

That context compounds. Every investigation refines what the system knows about your environment, so the graph gets more accurate with use instead of drifting stale.

The results show up in resolution time. DoorDash Ads reduced time to root cause by up to 87% with Resolve AI, and Salesforce reduced it by roughly 60%. Book a demo to see the context graph built on your own systems.

FAQ

What is context in automated RCA?

Context is what the investigating agent knows about your systems, the services and their dependencies, change history, ownership, and how to query your observability tools. It's what lets the agent go from an alert to a root cause without a human supplying the system knowledge.

Is context just RAG over logs and docs?

RAG alone isn't enough context for automated RCA. Retrieval answers similarity questions, and an investigation needs graph traversal and identity resolution that nearest-neighbor search can't perform. Context in automated RCA includes a context graph of services and dependencies, fluency with your tools, and control over what the model sees at each step.

How does context reduce AI investigation costs?

Context keeps queries scoped. An agent that knows which service, time window, and telemetry matter pulls a fraction of the data an unscoped agent would, which cuts both model token costs and observability query fees.

What keeps a context graph from going stale?

Continuous updates from the same sources it was built from. As deploys land, infrastructure changes, and new services appear in telemetry, the graph updates to match, and investigations themselves feed corrections back in. A manually curated catalog can't keep up with production, so the graph must be derived rather than maintained by hand.

Can automated RCA work without a context graph?

It can run, but every investigation starts with discovery. The agent has to work out dependencies and identify the right data sources while the incident is live, which makes investigations slower, more expensive, and more likely to be wrong.