Most incident time is not lost finding out that something is wrong. It is lost working out why. AIOps earns its place when it closes that gap by assembling evidence for an engineer to judge, rather than by handing down an answer nobody can check.

The alert is the easy part

At AWS Cloud & AI Day 2026, TechX CEO Ngô Mạnh Hà described a moment every operations team knows: "When an alert fires at two in the morning, the investigation cannot rest on someone's memory of how the system is wired. It needs service context and operational signals."

Picture that alert on a payment API. Within a minute the on call engineer has acknowledged it, so detection has done its job. What follows is the part no dashboard measures.

The engineer opens the APM console, then the log platform, then the cloud provider's alarms. They check whether last night's release touched this service, search the chat history for the last time this alert appeared, and find a runbook that only half applies. Then they start ruling out causes one at a time.

By the time a hypothesis forms, most of the incident's duration has already passed. None of it was spent on detection, and very little of it was spent on the fix. It was spent gathering and connecting evidence that already existed in five different places. That stretch, from alert to evidence, is where AI can do the most useful work and where it has to be designed most carefully.

Why investigation stays slow

Investigation stays slow for three reasons, and none of them is a shortage of data.

Signals arrive without context. A modern estate on AWS produces alerts from CloudWatch, from APM and log platforms, from database monitoring and from vendor tools bundled with core systems. Each alert describes a symptom on one component. None of them says which business service is affected, what that service depends on, or what changed recently. The engineer has to supply that context by hand, every time.

Evidence is scattered across tools and teams. Metrics live in one console, logs in another, deployment history in the CI pipeline, and the record of past incidents in a ticketing system that nobody searches at 2 a.m. Correlating them means switching screens and copying timestamps. The work is skilled, repetitive and almost entirely unrecorded.

The most valuable knowledge lives in people. Every operations team has an engineer who knows that a particular alert always follows the nightly batch job, or that a certain error pattern means the upstream partner is throttling. That judgment shortens investigations dramatically when that person is on shift. When they are not, the team starts from zero, and when they leave, the knowledge leaves with them.

Adding another dashboard does not fix any of this. A single pane of glass answers the first question, which is what is happening. It does far less for the questions that actually consume the incident: what this means for our services, what we have seen before, and what we should do next.

Evidence over answers

The useful job for AI in an incident is to assemble an evidence pack, not to announce a root cause. An answer without its reasoning asks the engineer to trust the model. An evidence pack asks the engineer to judge the facts, which is the work they are trained and accountable for.

A good evidence pack, assembled in the first minutes of an incident, contains five things.

The defining property of the pack is that every item cites where it came from. A correlated alert links to the metric. A suspected change links to the deployment record. A similar incident links to its ticket. When the AI drafts a hypothesis on top of this, the engineer can see exactly which evidence supports it and which evidence is missing.

This changes the engineer's first ten minutes. Instead of collecting facts, they start by reviewing them. Instead of asking whether the model is right, they ask whether the evidence holds up. A hypothesis that is wrong but well cited is still useful, because it is fast to disprove. A hypothesis that is right but uncited is hard to act on, because nobody can defend the decision afterwards.

Human guided by design

Keeping engineers in the loop is not a temporary compromise until the models improve. In regulated environments such as banking, it is the design decision that makes the rest of the system usable.

The division of labour is simple to state. AI does the gathering, correlating and drafting, which is high volume work where speed matters and an occasional miss is cheap. People do the judging, approving and acting, which is low volume work where accountability matters and a wrong call is expensive.

In practice that means three points where a person stays in control:

1. Scoping the investigation. The engineer can steer the evidence gathering by confirming the affected service, excluding a known noisy signal, or asking a follow up question in plain language. The AI works inside the boundaries they set.

2. Accepting or rejecting the hypothesis. The draft root cause arrives with its evidence. The engineer confirms it, amends it or discards it, and that choice is recorded.

3. Approving any action. A recommended remediation, drawn from approved runbooks and past resolutions, is executed only after a named person approves it. The approval, the approver and the reasoning are captured as they happen.

   
   

The evidence first incident loop · 6 steps, 2 owners

The system gathers and drafts in the top lane. Every judgment and approval sits with a named person in the bottom lane, and each outcome feeds the next investigation.

This structure solves a problem that often blocks AI adoption in operations. Teams hesitate to let automation near production because they cannot explain afterwards why a change was made. When the evidence, the hypothesis and the approval are written down at the moment of decision, the post incident review, the audit question and the regulator's enquiry all have the same answer, and it already exists.

It also means the system gets better in a way the team can see. Every confirmed or corrected hypothesis becomes a labelled example of how this organisation actually investigates. The knowledge that used to live in one senior engineer's head becomes something the whole team owns.

What to measure

Mean time to resolve (MTTR) is the number most teams report, but it hides the stage this approach targets. To see whether investigation is actually getting shorter, split the incident timeline and measure the stages separately.

Three cautions apply. First, write down how each metric is defined, because MTTR is used for repair, recovery, response and resolution, and MTTU is not yet a standard industry term. Second, establish a baseline before any change, using your own incident history, so that improvement is measured against your environment rather than a vendor's benchmark. Third, read the trust metrics alongside the speed metrics. A falling MTTU with a falling acceptance rate means engineers are moving faster on evidence they do not believe, which is a warning sign, not a win.

The TechX view

At TechX, we see this shift as the core of what AI native managed services should mean. The goal is not to remove people from operations. It is to give them the evidence sooner, keep the decision with them, and make every decision traceable.

That is the thinking behind Xora Observe, which provides governed operational visibility by consolidating approved telemetry, service context, alerts and evidence. It works across the observability tools a customer already runs rather than replacing them, and it follows the same loop described above: observe signals, understand context, investigate with evidence, review recommendations, approve actions, and learn and improve. Representative use cases include alert noise analysis and correlation, evidence backed root cause analysis, and human reviewed runbook and remediation recommendations. Xora Observe assessment and implementation, along with the full list of use cases, is available through the Xora Agentic AI Platform Professional Services listing in AWS Marketplace.

The teams that shorten incident investigation will not be the ones with the most dashboards or the most automation. They will be the ones whose engineers start every incident with the evidence already assembled, and finish it with a decision they can explain.