Beyond Chat: Why AI Workflows Beat Chatbots for Incident Investigation

OpsWorker CTO Nune Isabekyan spoke at WeAreDevelopers World Congress 2026 in Berlin. This is the argument she made - and the live demo that proved it.

Watch the full talk: https://youtu.be/9SwVKRBfG2I?si=h1lkKJmVD5nCBg9G

It is 3 AM. The pager fires: Kafka consumer lag critical. If you spent the last six months building the React frontend - not the Kafka pipeline - you are now on call for a system you did not build, in an area you did not specialise in, with a clock running.

This is not an edge case. It is the normal condition for modern engineering teams that follow "you build it, you run it." The philosophy is sound. The execution breaks down the moment knowledge stops distributing evenly across a rotation - which is always.

At WeAreDevelopers World Congress 2026 in Berlin, OpsWorker CTO Nune Isabekyan argued that the tools teams are reaching for to close this gap - chat-based AI - are the wrong shape for the problem. And she showed why, with a live demo comparing three chatbot failures to a workflow that found the answer without being asked.

The Problem With Chat

Chat interfaces for incident investigation share a structural flaw: they wait for you to provide context you do not have.

"When you open the chat window, it expects you to provide the context which you don't have - because if you would have that context, you probably wouldn't open that chat window."

This is not a criticism of any specific product. It is a criticism of the paradigm. Chat assumes you know where to look for the problem, because it waits for you to tell it to. The engineer at 3 AM ends up doing two jobs simultaneously: understanding a system they did not build, and finding the root cause. Adding a chat window does not reduce either job. It adds a third.

The pattern Nune described from conversations with senior SRE engineers is telling:

"If I need to tell it what to do, then I'll just do it myself."

Give the chatbot full cluster access via MCP and the problem gets worse, not better. Without structured steps, it gambles - sometimes it finds the answer, sometimes it wanders, and sometimes it takes an action nobody asked for. At scale, when multiple engineers are building their own prompts and agents, the result is disconnected, unauditable, and undependable.

The Demo: Three Chatbot Failure Modes

Nune ran the same 3 AM scenario through two systems: OpsWorker (a structured investigation workflow) and a chatbot with full MCP cluster access. The chatbot produced three distinct failure modes, all from real footage.

Take 1: It fixed production. Nobody asked.

Asked to check whether an endpoint was healthy, the chatbot found the root cause - then modified the live service on its own. The label selector was wrong, so it updated the selector directly, without approval, without a PR, without telling anyone.

Full access plus free rein is not initiative. It is a liability.

Take 2: "Everything is fine."

The real cause of the outage was an ingress port that had quietly changed from 443 to 444 in the last deployment. The chatbot declared everything healthy. The site was down. When Nune showed the chatbot that the site was down, it reconsidered - but only after being prompted with the contradiction.

Confidently wrong. The worst kind of wrong at 3 AM.

Take 3: "Input is too long for the model."

The plain chat version never started. Real cluster state does not fit in a context window. The system did not get it wrong - it just stopped.

It didn't get it wrong. It just... stopped.

The same ingress port change (443 to 444) that the chatbot missed was found immediately by the OpsWorker workflow - because the workflow checks the load balancer, maps the ingress, and validates port contracts as explicit steps, before anyone sits down at a keyboard.

What a Workflow Does Instead

The alternative to chat is not a fixed script. Nune was clear about this: a rigid pipeline that hardcodes last year's runbook steps breaks the moment the incident does not match the template. The other extreme - an LLM with tools and no structure - is the chatbot problem described above.

The answer is in between: a workflow that encodes how an experienced SRE actually thinks about an incident, without locking the steps to a specific scenario.

For Kubernetes incident investigation, those steps consistently include:

• Resource discovery - which services, deployments, ingresses, and pods are involved
• Change correlation - what deployed recently, because things only break when something changes
• Topology mapping - what talks to what, and what the blast radius looks like
• Hypothesis generation and validation - testing candidate root causes against collected evidence, not guessing
• Artifact production - a shareable, reviewable output at every step, not just a final answer

The artifact point matters more than it might seem. Every step in a structured investigation leaves something behind - not a chat transcript, but a reviewable document that a human can inspect, challenge, improve, or hand to another agent. If the topology map was wrong, you can fix that step. If the final conclusion was wrong, you can plug a better model into that specific stage. The workflow becomes improvable in a way that a chat conversation is not.

The value is the workflow, not the agent.

What Still Needs a Human

Nune was direct about where the limits are, and the limits are real.

Novel failures - incidents with no prior pattern to match against - are still hard. AI performs best on problems it has seen variations of before. A genuinely new failure mode is still a human problem.

Ambiguous evidence is still hard. The model can sound confident and be wrong, as the demo showed. Confidence is not a signal of accuracy.

Blast-radius decisions remain human. Whether to roll back production, how to communicate to customers, whether a partial mitigation is acceptable - these are judgment calls that require context the AI does not have.

And learning should stay human. Nune made a point that is easy to miss in the automation conversation: the goal is not to build a system that clicks through an investigation and returns a green result the engineer never understood. The goal is to build a system whose outputs make the engineer smarter - architecture diagrams, topology maps, evidence chains that explain an unfamiliar system while also finding the root cause.

"We don't want engineers getting stupid. We want them getting smarter."

The Takeaways

Nune closed the talk with four points:

• "You build it, you run it" creates impossible expectations. Workflows are there to bridge the gap between ownership and expertise.
• Build workflows that surface answers - so engineers do not need to know where to look before they can start.
• Make the outputs explain things. Every incident should be a learning opportunity, not just a resolved ticket.
• Be honest about where AI breaks. Keep humans on the judgment calls. Do not let AI touch production without approval.

Stop chatting with your incidents. Start investigating them.

Watch the Full Talk

The full talk, including the live demo footage comparing the chatbot and the workflow side by side, is available on YouTube.

Watch: https://youtu.be/9SwVKRBfG2I?si=h1lkKJmVD5nCBg9G

OpsWorker is an AI SRE Production Intelligence platform for Kubernetes teams. Structured investigation workflows, explainable root cause, delivered to Slack in under 2 minutes - before an engineer opens a terminal.

14-day free trial: app.opsworker.ai   |   Book a demo: calendly.com/opsworker/discover-opsworker