Systems Don't Lie: Abhishek Kundalia on the First 15 Minutes of an Incident

The AI SRE Files is a new series where we talk to the speakers about AI in the SRE world and distill them into one idea worth keeping.

This article draws from the "Killing the 90-Minute War Room" session at AISRENext Bengaluru, held on June 12, 2026. 

If you've ever been in one, you know exactly what that name is pointing at. An alert fires at 2 AM. Engineers from five different teams join a bridge call. Everyone starts pulling up their own dashboards. The infrastructure team looks at infrastructure.  Service owners look at their services. And for the next 90 minutes, the team works through one theory after another.

Early in the session, Abhishek Kundalia, Director of Engineering at PocketFM, was asked about the most critical phase of any incident: the first 15 to 30 minutes.

His answer set the direction for the rest of the discussion:

"The first 15 minutes of any incident is all about reducing uncertainty."

SRE Teams Have Always Had Enough Data

That question connected to an idea Sanjeev Sharma, Field CTO at StackGen, had introduced, which he calls the 4-body problem of SRE: the compounding complexity that emerges when infrastructure, services, teams, and organizational context all interact simultaneously, and no single engineer holds the full picture.

Abhishek took it further.

"The missingness of data is not the issue. The issue was having a shared knowledge base. As Sanjeev said, there's one person who has full context, because that person knows how these systems integrate, while others know specific systems in silos."

Every SRE team has that person. The one who gets paged first, regardless of who is actually on-call, because they know how everything connects. Which deployment affects which service? Why a change in one system ripples into another? What that alert actually means at 2 AM?

That person is also a single point of failure.

For years, incident response depended on institutional memory. It lived in people, not systems. When that person was unavailable, the knowledge went with them.

AI Queries Systems Directly, Humans Rely on What They Remember.

This is the shift Abhishek kept returning to:

"Previously, we were asking humans how the system worked. Now it has changed to relying on systems, and systems do not lie."

That changes the starting point of an investigation entirely.

Traditional incident response depended on engineers reconstructing context from memory and experience. Teams would ask: Has anyone seen this failure before? Was there a recent deployment? Did someone change the configuration? The answers often existed, but they were distributed across people, teams, dashboards, and tools.

Systems retain the entire chain of events.

• Deployments remain in deployment records.
• Configuration changes remain in change histories.
• Feature flag rollouts remain in feature management systems.
• Infrastructure changes remain in audit logs.

An AI SRE agent can query all of those sources simultaneously and surface relationships that would take multiple engineers to uncover manually. The result is more than an efficiency gain. It is a shift in where teams derive ground truth. Instead of beginning with what engineers remember, investigations begin with what the system knows.

A Month-Old Feature Flag Can Trigger Today's Incident

Abhishek gave an example that captures why human correlation breaks down at scale.

"A feature was launched one month ago, and recently somebody in the product team took a call and did 100% rollout. That would have caused an influx of a certain different kind of pattern. Those kinds of changes are very difficult for humans to figure out or correlate very quickly."

Nothing about that scenario immediately points to the root cause.

The feature was already in production. The rollout had been gradual. No alarms were raised when it was first introduced. Then, weeks later, an alert fires.

Most investigations start with recent changes: the deployment from yesterday, the infrastructure change from this week, the service that was touched most recently. A product decision made weeks earlier rarely makes it into the initial conversation.

That's what makes these incidents so expensive. The signal exists, but it sits outside the timeframe that engineers instinctively search.

Systems don't have that limitation. A rollout from this morning and a rollout from last month are both part of the same history. When investigations start from system state rather than human recall, older changes stay visible, even when nobody in the room is thinking about them.

For PocketFM, that shift has materially changed the early stages of incident response. Instead of spending time reconstructing timelines across teams and tools, engineers now focus on validating likely explanations. They get to root-cause candidates within 5 to 10 minutes.

Context Is More Valuable Than Correlation

Finding anomalies is only part of incident response. The harder question is understanding which anomalies matter.

"There is a business context layer which talks about what the importance of each component is, what it is meant to do, and how they are correlated to each other."

Not every service carries the same weight. Not every alert deserves the same urgency. Two components can show unusual behavior at the same time, but the business impact can be completely different.

Context helps answer: What is this component responsible for? How critical is it to the business? Which other systems depend on it? What happens if it fails?

Without that layer, teams interpret technical signals in isolation. This shows up most clearly when new engineers join an on-call rotation. The limitation is rarely technical ability. It is context — the kind that experienced engineers accumulate over years of operating the platform. The more that context lives in the system rather than in individuals, the less dependent teams become on a small group of people who carry it in their heads.

AI SRE Shifts Engineers From Gathering Information to Making Decisions

PocketFM's experience also highlighted an important shift:

"It has moved towards engineers taking more decisions rather than figuring it out or gathering more information."

For years, a significant portion of incident response was spent answering basic questions: What changed? Which systems are affected? Are these issues connected? Has something similar happened before?

Before teams could make decisions, they had to assemble context. As systems became more complex, that process consumed an increasing share of incident response time.

The shift is not that engineers are removed from the process. The shift is that they enter the process later, past the information-gathering phase, at the point where engineering judgment creates actual value.

Reducing Uncertainty Is the New Incident Response Advantage

The most interesting idea from the discussion wasn't that AI can process more data. It was that the bottleneck was never data in the first place.

The challenge was context. Context about how systems interact. Context about which changes matter. Context about what the business depends on. Context that, for years, lived in the heads of a small number of experienced engineers.

What PocketFM's experience illustrates is that incident response is becoming less about collecting information and more about applying judgment. When systems can surface relevant changes, preserve operational knowledge, and provide business context alongside technical signals, engineers spend less time reducing uncertainty and more time deciding what to do next.

That shift has implications beyond faster incident resolution. It changes how teams scale knowledge, onboard new engineers, and operate increasingly complex systems without becoming dependent on a handful of people.

The 90-minute war room was never really a tooling problem. It was a context problem.

At StackGen, Aiden treats context assembly as the first step of incident response. It queries system state across deployments, change histories, and service dependencies simultaneously, so engineers arrive at the decision point faster, with the context already assembled.

Try Community Edition for free today!