AI-Native
Support Operations

1 · The Support Model Is Under Pressure

For thirty years enterprise support has been tiered, and for good reason. Expertise is scarce and expensive, so a broad, cheaper, always-available first tier filters the queue and only the incidents that genuinely need scarce expertise reach it. The economics are sound. Nobody has invented a better structure.

What has changed is the volume arriving at the front of that filter. Every new service, every migration, every acquisition adds alerting surface. Estate growth is compounding; the tiering model responds to it linearly, by adding people.

The tier boundary, not the tier

Time a real incident and the largest single block of elapsed time is usually not the investigation. It is the handoff — and the handoff carries two costs that per-tier metrics cannot see.

The evidence is gathered twice. L1 opens the dashboards, reads the logs, then writes three lines in the ticket. L2 receives three lines, cannot reconstruct what L1 saw from them, and opens the same tools again. The work is repeated because the first pass was never captured in a form the second person could use.

Context degrades at every hop. What L1 saw becomes a sentence; what L2 concluded becomes another. By the time it reaches an engineer the original signal has been through two rounds of lossy summarisation, and their first question is usually for something that was on L1's screen forty minutes earlier.

There is a second, quieter effect. L1 escalates more than it should — not through lack of skill, but because the information needed to stop is not available at L1. The runbook says check whether the error rate has recovered; following that instruction requires access to the metrics tool, knowledge of which query represents "the error rate" for this service, and the judgement to read a bouncing number. When one of those is missing, escalating is the only safe action for the individual — whatever it costs the organisation.

2 · Anatomy of an Incident

Averages hide the shape. Below is one production incident, timed end to end: an error-rate page on a payments-adjacent service at 02:14, handled by a competent engineer following a runbook that existed and was roughly accurate. It closed in forty-one minutes, which most teams would call a good night.

Sorted by what each minute was for, rather than when it happened, the shape is stark. Roughly half the incident — twenty-one and a half minutes — was locating and reading information that already existed. Seven minutes were genuine judgement.

The two-sentence ticket that closed it records neither — not the error rate, not that the dependency looked healthy from outside, which was the genuinely confusing part. When the same alert fires in five weeks a different engineer spends their own twenty-one minutes. Not through carelessness: writing that down at 02:55 is not a reasonable thing to ask of someone who has to work tomorrow.

3 · What Should Be Automated, and What Should Not

There are two failure modes in AI-for-operations programmes and they are mirror images. Automating too little produces a chatbot that summarises what everyone can already read. Automating too much produces a system that restarts a database at 3am on a model's say-so and is wrong. Both come from skipping the same step: separating the mechanical from the consequential.

The failure mode that ends pilots

An assistant reads the logs and reports: "Root cause: database connection pool exhaustion. Confidence 92%." The engineer checks. The pool is at forty per cent utilisation. Nothing in the evidence supported ninety-two per cent; the number was generated, not measured.

The damage is not the wrong answer — engineers are used to monitoring tools being wrong. The damage is that the confidence was fabricated. Once an engineer catches a system doing that they stop reading its output permanently, and they tell their colleagues. Trust in this category is spent once. So the question that matters is not how often it is right, but how it behaves when it is wrong — and whether it knew.

A corollary vendors rarely volunteer: for much of this work a rule beats a model. Thresholds need arithmetic, not inference; known signatures should be encoded, not guessed; and anything a reviewer will question is better served by a deterministic rule you can point at. A system that cannot run without a model has put a probabilistic component on a critical path.

4 · Runbooks Have To Become Data

Every organisation has written its incident knowledge down. It is in the wiki, and it is out of date. This is not a discipline problem, and exhorting the team to maintain it harder will not work. Prose cannot be executed; what cannot be executed cannot be tested; what cannot be tested drifts from reality one deploy at a time. The decay is structural.

The difference is not tooling preference. It is that the second form can be tested, and therefore relied upon. A runbook held as data can tell you, before you activate it, that step four references a variable nothing sets, that step six depends on a system this deployment has never been given credentials for, and that step two would page someone.

The knowledge-capture argument

This is where the operating-model case is stronger than the cost case, and it is the part CIOs tend to recognise immediately. The engineer who knows that this alert on that service is almost always the payment gateway is a single point of failure your org chart does not show. When they are on holiday the same incident takes four times as long; when they resign, the organisation loses years of tacit knowledge and discovers it only during the next outage.

5 · Not Every Alert Needs an Action

The most common wrong answer in automated remediation is doing something. A meaningful share of pages — consumer lag, queue depth, replication delay, batch backlog — need nobody to act. They need somebody to watch a number come down and confirm that it did.

Humans are poor at this and resent it. It occupies an engineer who cannot do anything else while occupied, it happens disproportionately at night, and the correct outcome is indistinguishable from having ignored it. Patience, however, is mechanical.

An incident the agent watched rather than acted on: three readings, the direction, the threshold it was waiting for, and the conclusion — "19855 is < 25000 — the condition has cleared on its own after 3 checks." No action was taken, and the readings stay on the record.

Blast radius belongs to you

Reading is safe; writing is not. Where the boundary sits is a decision for your change-management policy, not for a vendor's default. Three controls make it explicit: steps that change something outside the platform are marked as such and surfaced before activation; anything consequential can be gated behind a human approval that suspends the run until a named person answers; and the dry run rehearses a whole runbook without executing a single step, so a rehearsal can never page anyone.

6 · Reference Architecture

The shifts above come together in five layers. The top is where alerts arrive from whatever is already installed; the bottom is the estate that must not be put at risk. Every layer in between exists to translate the speed of the top into the safety of the bottom.

Two properties matter more than the boxes. It runs inside your environment — your cloud, your credentials, your model endpoint if you have one — so incident data does not leave. And it degrades honestly: a step whose system is not configured reports that and is skipped, rather than guessing something plausible to fill the gap.

7 · What Leaders Should Do Next

This is a programme of work, not a procurement decision, and it earns trust before it asks for it: read-only first, writing later, autonomy last.

Measure your own starting point first

Three questions, answerable in a fortnight from systems you already have. Do not buy anything before you can answer them.

1 · What share of incidents reaching L2 were escalated without any change made at L1? This is the escalation the information gap caused, and it is usually the largest surprise in the exercise.
2 · What is the median gap between escalation and first action at the receiving tier? Measured separately from handling time. It belongs to no team, so nobody reports it.
3 · What share of incidents close with no change made to anything? If it is a third, you are paying full incident cost for alerts that only needed somebody to wait.

Then time three incidents by hand — an observation, not a survey. The assembly share from three real incidents will be the most useful number in your business case, and it will be yours rather than a vendor's.