Reimagined ITOps is a weekly series about what IT operations becomes when AI stops assisting and starts operating. This is article 8 of Season 1. Stay with it.
Forty minutes into a P1 bridge, someone asks the question I have heard on every bridge I have sat on. What changed?
Fourteen people go quiet while one of them searches. Meanwhile, a director has joined on mute, the business is asking for an update, and the engineer closest to the fault stops diagnosing to write three sentences for a status mail.
That is what a major incident looks like in most enterprises I have worked with. Not a technical problem. A context problem and a communication problem, fighting the technical problem for the same few people’s attention.
The market’s answer this year is an agent that resolves the incident for you. Autonomous remediation, pages answered before a human wakes, resolution times cut by most of their length. An industry survey of reliability teams found more than half planning to put agentic AI into production within a year.
My claim runs the other way. We put an agent on live P1 bridges, and the first design decision was to take its hands away. The value of an agent on a major incident is not that it acts. It is that it holds the whole context, writes everything down, and drafts the record, while the decisions stay human.
The First 15 Minutes: Answering “What Changed” Before Anyone Asks
The bridge’s first quarter hour is spent assembling what should already have been assembled.
With the agent on the call, the bridge opens with the ticket data, the alerts correlated across the affected services, the changes that touched those services in the preceding window, the dependency map, and every prior incident that resembled this one, already laid out. The engineers can also ask it questions over the runbooks and the vendor documentation, in plain language, without leaving the bridge.
That is only possible because the context underneath holds changes, dependencies, and ownership as relationships rather than as rows, which is the floor this series keeps returning to. An agent on a bridge without that floor is a chat window with opinions.
Two rules govern what it says. Evidence, analysis, recommendation, and next action are shown separately, so nobody mistakes a hypothesis for a finding at 2 am. And where it has no precedent for the pattern in front of it, it says so, which on a P1 is frequently the case, and is far more useful than a confident guess.
The Next Two Hours: The Scribe Nobody Had
Here is the part that surprised me. Ask the engineers who have run bridges with the agent what they value most, and the first answer is rarely the diagnosis. It is the notes.
The agent keeps the timeline as the bridge runs: who joined, what was tried, what the result was, what was ruled out, and when. From that timeline, it drafts the periodic stakeholder update, in the shape the business expects, on the cadence the incident process demands. A human reads it and sends it, or edits it and sends it. Nobody stops diagnosing to write it.
That removes the quiet tax every major incident pays, where the most knowledgeable people on the call spend a share of the bridge producing prose for people who are not on it. Recent survey work on incident readiness found 9 in 10 security leaders expecting coordination problems during a significant incident, and most citing communication delays as a drag on decisions. Operations bridges are no different.
And when the incident closes, the RCA is not written from memory three days later. It is drafted from the record that was kept while it happened, with the timeline, the evidence considered, and the actions taken, for a human to correct, complete, and own.
Why It Has No Hands
Now the concession, and it is a large one. On the bridge, the agent executes nothing. Each action is taken by a human.
This is deliberate, and it follows from everything the series has argued. Autonomy is earned on convergent, high-volume, well-precedented demand, where the system has seen the pattern hundreds of times and verification is cheap. A P1 is close to the opposite: novel by definition, high blast radius, and frequently a pattern the system has declared it has no precedent for. In a risk-based execution model, that is exactly the work that requires human approval.
I hold that human-in-the-loop should be a guardrail rather than a dependency. On a major incident bridge, it is a dependency by design, and I am comfortable with that. The bridge is where autonomy lands last, not first.
Which also answers the objection that this is alert correlation with a new name. Correlation reduced noise and stopped there. What is on the bridge now is a system that carries the record, the context, and the draft of every artifact the incident process requires, and that knows, and says, where its own knowledge ends.
What This Changes
First, give the agent the scribe role before any other. It is the lowest-risk, highest-relief job on the bridge, and it builds the trust that everything after it depends on.
Second, measure the bridge on different numbers. Time to the first accurate status update. Time from closure to a complete RCA. How often the “what changed” question was answered from the record rather than from a search. Resolution time matters, but on a major incident the slowest part is rarely the fix.
Third, hold the line against auto-remediation on the bridge until the convergent queues have earned it elsewhere. A vendor who offers to resolve your P1s autonomously before it has resolved your password resets has the order backward.
The Question for IT Leaders
Think back to your last major incident. How long before the first accurate status went out, and who stopped diagnosing to write it?
So my question: on your bridges today, is the person holding the record also the person you most need holding the fault?
Next week: why L1 and L2 converge into one exception layer, and why that must happen after coverage is proven, never as a cost move first.
Sanjesh Rao leads product strategy and innovation for Hexaware’s Agentic ITOps platform.
