Obseria Intelligence 3.0: Agentic Root Cause Analysis with Evidence
The next generation of our causal AI investigates problems on its own, documents the chain of evidence and proposes verified fixes.
Summary
- Obseria Intelligence 3.0 replaces the static root cause report with an agentic investigation: agents plan, test hypotheses against telemetry and discard anything they cannot prove.
- Every answer contains a chain of evidence from topology, deployments, metrics, logs and traces that humans can follow in seconds.
- Proposed fixes are tested against SLOs in a simulation before execution; execution remains bound to your approval policies.
When we released the first version of Obseria Intelligence in 2022, the promise was simple: no more alert floods, but an answer to the question why a system is behaving the way it is. Causal analysis based on automatically discovered topology delivered on that promise for thousands of teams. But it had a limit: it produced a report, and the investigation ended there.
With Obseria Intelligence 3.0, we are changing that. Root cause analysis becomes an investigation that an agent conducts on its own, documents and concludes with a chain of evidence. In this post, we show what is behind it, what it looks like in practice and why we made explainability non-negotiable.
Why correlation is not enough
Most "AI-powered" analyses in observability tools are correlations: metric A goes up, metric B goes up, so they must be related. In distributed systems, that is rarely the whole truth. When the checkout service slows down, the latencies of twelve services calling it rise at the same time, as do the error rates of three services it calls itself. All the curves look the same. Which one is the cause?
Obseria Intelligence answers this with causality instead of statistics. Obseria TopoGraph knows the call chains, processes, hosts and cloud resources. Along this graph, a hypothesis can be tested: can a change at node X produce the observed symptoms at nodes Y and Z? And was there actually a change at X, such as a deployment, a configuration change or a resource bottleneck?
What "agentic" means in concrete terms
In version 3.0, an investigation agent runs the process an experienced SRE goes through during an incident, only in seconds instead of hours:
- Narrow down. From the problem context (affected services, time window, symptoms), the agent forms causal hypotheses along the topology graph.
- Test. For each hypothesis, it queries telemetry in a targeted way: deployment events, resource metrics, error logs, trace spans. Not everything, only what would prove or disprove the hypothesis.
- Discard. Hypotheses without evidence are dropped and documented as checked so nobody investigates them again on the incident call.
- Explain. The remaining cause is described with a chain of evidence that backs every step with a link to the underlying data.
- Propose. If the cause matches a known pattern, the agent proposes a fix and simulates it against the affected SLOs.
The decisive difference to a chatbot on top of your data: the agent may not claim anything it cannot back up with a query. Every statement in the report is a link.
A chain of evidence in practice
This is what a result looks like, as a pilot customer from retail received it last week. The times are real, the names anonymized:
Cause: memory leak in checkout-svc after deployment v2.14.0 (14:21).
Chain of evidence: deployment event 14:21 → RSS memory from 1.2 GB to 3.9 GB in 11 minutes (metric) → OOMKilled events from 14:32 (Kubernetes) → 502 errors in api-gw from 14:32 (traces) → revenue per minute −38% (business metric).
Checked and discarded: database latency (unchanged), upstream provider (no errors), traffic spike (traffic −2% versus last week).
Proposal: roll back to v2.13.2. Simulation: error rate < 0.1% within 90 seconds. Approval required (policy: production, business hours).
What is not in there matters just as much: no probability without a basis, no list of twenty "possibly related" alerts. Three discarded hypotheses, one proven cause, one simulated fix.
Natural language questions, answers with queries
The investigation agent is interactive, too. You can ask follow-up questions, and the answer comes with the query that produced it. The question "Which customers were affected?" generates, for example, this Obseria Query Language (OQL):
fetch spans
| filter service.name == "checkout-svc" and status == "ERROR"
| filter start_time >= "2026-10-05T14:32:00Z" and start_time < "2026-10-05T14:47:00Z"
| summarize orders = count_distinct(order.id), customers = count_distinct(customer.segment), by: {customer.segment}
| sort orders desc
The query runs with the permissions of the user asking. Anyone who is not allowed to see the customer segment column will not get it from the agent either.
Guardrails and governance
Agents that act on production systems need clear boundaries. We built three principles firmly into 3.0:
- Read yes, act only with policy. The agent may always investigate. Every action (rollback, scaling, ticket) runs through Obseria Automation with approval rules per environment, service and time window.
- Complete audit trail. Every query, every discarded hypothesis and every proposed action is logged and becomes part of the incident report.
- No data for model training. Customer data does not leave the selected region and is not used for training, not even anonymized.
Availability and next steps
Obseria Intelligence 3.0 is available today for all Pro and Enterprise customers in the EU and UK regions and will be enabled for trial accounts over the next two weeks. Existing root cause reports remain unchanged; the agentic investigation appears as a new section in every problem.
If you want to combine the investigation agent with your own agents or assistants: the MCP server and the CLI expose the same investigation functions. The documentation describes how to connect your own hypothesis sources, such as change management systems, as evidence.