Why root cause lives between your tools and systems, not inside any one of them

Why isn't one observability tool enough to find root cause?

Because the evidence is split across tools by default. One signal sits in Grafana, a related one sits in Splunk, and infrastructure logs go to a third provider entirely. A large engineering organization accumulates telemetry in different places for reasons that made sense at the time, and no single tool has a complete view.

An on-call engineer already works around this. They pull up three tools, correlate a metric against a log against a recent code change, and reason across all of them. Anything that only reads one source is doing a fraction of the work a human does.

Why don't more tools reason across the whole stack?

There are two hard parts, and most of the discussion only covers the first one.

Building and maintaining observability integrations is difficult in a way business application connectors are not. Connecting to Slack or HubSpot is a solved shape. Observability systems are not. Grafana is a system with its own data sources underneath it, so connecting to Grafana means dealing with Prometheus, ClickHouse, and Tempo behind it. Splunk environments can carry a large number of indexes, and querying across them efficiently is its own problem.

The second part is orchestration. Even with every integration built, something has to decide which one to use for this specific question and how to use it, at runtime, while an investigation is in progress. That decision is where most of the difficulty actually sits.

How does an agent decide which tool to query?

Through a purpose-built agentic harness that knows what it is trying to do. Resolve AI's agents are built around a single goal, which is getting to root cause, and they are aware at runtime of which integrations are connected and what each of those integrations can be asked. When an alert fires, the agent already has that context and can narrow to the relevant source rather than querying everything.

The comparison worth making is to a general-purpose assistant with tool access. Knowing that Splunk is connected is not the same as knowing which index to query, in what order, and what a result rules out.

What does this look like during a real page?

The hard version of this problem is distance. A service ten hops upstream of the person being paged develops an issue, and some code changes went in around the same time. The engineer on call gets paged in the middle of the night for a service they own, caused by a system they may not have worked on.

Without help, that engineer has to dig into unfamiliar territory to find a change they had no reason to know about. An agent that can correlate the signal across tools and pull the relevant code change can hand the on-caller the actual explanation instead of a starting point.

Why query data at runtime instead of ingesting it?

Because ingestion creates two problems that never go away. The common approach is to pull a copy of the customer's telemetry into the vendor's system and then run search over that copy. The first problem is staleness, since the copy is always behind the live system by some interval. The second is that the vendor has quietly become a telemetry provider, with all the storage, cost, and data-handling obligations that implies.

Resolve AI does not ingest the data. The agents craft queries in real time against the systems the customer already runs, which is closer to how an engineer works. An engineer does not maintain a private replica of production telemetry. They go and look when they need to know something. The design goal is for the agent to resemble an experienced engineer as closely as possible, and this is one of the places that resemblance is architectural rather than cosmetic.

Why can't a team build this in-house?

Building the integrations is the visible cost and the smallest one. Maintaining them is continuous, because every observability vendor changes its interfaces and behavior on its own schedule. On top of maintenance sits the requirement to rigorously evaluate and instrument each integration, so you can tell whether a query strategy is returning useful evidence or just returning results.

The orchestration layer is where the effort concentrates. A team that starts down this path is committing to build and keep tuning a system that decides, live, which of many possible sources to consult for a question that has not been asked before.