The bottleneck moved from reasoning to context
On July 25, 2026, InfoQ reporter Mark Silvester described a quiet but consequential shift in how AI assists incident response. For the past two years, teams assumed better root cause analysis would come from better models. The Coroot engineering team, and specifically Nikolay Sivko, now argue the opposite has happened in practice. In Sivko's framing, the reasoning turned out to be the easy part, and the real challenge is the harness that feeds the model the right context. That reframing matters because it changes where engineering effort and money should go.
The claim traces back to Coroot's June 30, 2026 post, bluntly titled that the hard part of AI root cause analysis is no longer the model. The observation is grounded in operational experience running RCA against production telemetry. When a modern model is handed a clean, correlated view of what changed during an incident, it explains the failure competently. When it is handed raw logs, metrics, and traces with no structure, it flounders. The difference in outcome comes almost entirely from the pipeline, not the parameters.
Why the reasoning problem quietly got solved
Sivko's headline conclusion is that the reasoning part of AI RCA is basically solved. That is a strong statement, and it deserves scrutiny, but the logic is straightforward. Diagnosing an incident is a bounded reasoning task once the relevant evidence is in front of you: correlate a latency spike with a deployment, tie an error rate to a config change, connect a saturated node to a noisy neighbor. Current frontier models handle that class of inference reliably. The hard cognitive work that once justified model upgrades is now table stakes.
What remains hard is everything upstream of the reasoning step. Production systems emit enormous volumes of telemetry across metrics, logs, traces, and events, most of it irrelevant to any given incident. Selecting the small slice that actually explains a failure, and presenting it in a form the model can use, is an unglamorous data-engineering problem. Coroot's argument is that this selection and correlation work, not raw model capability, is what separates a useful RCA system from a demo that impresses in a slide deck.
Agent-based versus deterministic harnesses
The debate has crystallized into two design patterns. In the agent-based pattern, the model receives a set of tools and autonomously decides which telemetry to fetch, iterating until it converges on an explanation. This mirrors the general agentic trend across the industry and feels natural to teams already building with tool-calling frameworks. Its appeal is flexibility: the agent can chase an unexpected thread the way a human on-call engineer would, pulling a dashboard here and a trace there without a predefined path.
The deterministic pattern inverts that control. Signals are pre-correlated by the pipeline, and a single compact context is assembled and handed to the model in one shot. The model reasons over a curated evidence bundle rather than deciding what to gather. This trades the agent's open-ended exploration for predictability. The same incident produces the same context every time, which makes the system easier to test, cheaper to run, and simpler to reason about when it gets an answer wrong.
Why deterministic pipelines are winning the argument
The reported momentum is toward the deterministic approach, and the reasons are operational rather than ideological. Reliability comes first: an SRE team cannot ship an incident tool whose behavior varies run to run for the same failure. Evaluation is cleaner too, because a fixed context lets teams measure whether the model's explanation was correct against a stable input, rather than debugging both the reasoning and the wandering data-gathering path at once. For an on-call system, reproducibility is worth more than cleverness.
Cost seals the case. Agent loops that repeatedly query telemetry and re-prompt the model consume tokens at every step, and incident volume at scale makes that meaningful spend. A deterministic pipeline pays the correlation cost once in ordinary compute, then makes a single model call over a compact payload. The tradeoff is real: deterministic systems can be brittle on genuinely novel incidents that fall outside their correlation rules. For the large majority of recurring failure modes, though, that flexibility is a fair price to pay.
The budget question this hands to VP Engineering
For the leaders who own incident response, this reframing changes the spending decision. The instinct over the past two years was to reach for the most capable model available and assume RCA quality tracked model quality. Coroot's argument implies that dollar is better spent on the telemetry-correlation layer: the instrumentation, the pipeline that joins signals across metrics and traces, and the logic that assembles a tight context. That is an investment in your own data plumbing rather than in a vendor's model tier.
This is a build-versus-buy call with a clearer shape than it had a year ago. If the reasoning is commoditized, the differentiation and the durable value live in how well your organization captures and correlates its own operational signals. A VP of Engineering evaluating RCA tooling should ask vendors how they build context, what their evaluation methodology is, and how token cost scales with incident volume, rather than which foundation model sits underneath. The model is increasingly interchangeable.
What SRE leaders should do next
The practical move is to audit your telemetry before you audit your models. Many organizations discover during a real incident that their signals are neither correlated nor consistently labeled, which means no harness, agentic or deterministic, has good material to work with. Investing in clean instrumentation, stable service identity across logs and traces, and a correlation layer pays off regardless of which RCA vendor or open-source tool you ultimately adopt. That groundwork is the part no model upgrade can substitute for.
When you do pilot an AI RCA system, structure the evaluation around context quality. Feed it your worst historical incidents and judge whether the assembled evidence would have let a competent engineer reach the right conclusion. If the context is good and the explanation is still wrong, that is a model problem worth chasing. If the context is thin, the fix is in your pipeline, and that is squarely within your team's control. Coroot's thesis, if it holds, means the advantage goes to teams that treat RCA as a data-engineering discipline first.
