IT Operations Is Automating Away Its Own Brakes

Two camps in IT are currently announcing the same funeral, and neither seems to have noticed the other one.

In observability, the argument is that the human reader is finished. The case, made repeatedly over the past year, is that the entire history of the discipline has been an effort to compress vast volumes of telemetry into something a person could take in at a glance, and that AI removes the need for that compression. Commentators now argue directly that observability was built for humans and that AI agents need something else. Corey Quinn used a keynote at O11yCon, a conference devoted to the subject, to tell the room that the primary reader of their telemetry is no longer sitting in the chair.

In service management, the argument is that the ticket is finished. Industry predictions for 2026 hold that ticketless operations will eclipse ticket automation, and the distinction is drawn sharply: ticket automation reduces human effort, while ticketless operations sets out to eliminate it. Vendors across the category now promise service desks where problems are detected, diagnosed and corrected before anyone thinks to raise an incident.

Both camps are right about what they are killing. What neither has noticed is that they are dismantling opposite halves of the same structure, and that some of what they are pulling out was holding weight.

Two Disciplines, One Constraint

Consider what observability actually consists of, underneath the tooling.

Sampling exists because nobody can read every trace. Aggregation exists because nobody can read every metric. Dashboards exist because a person needs to glance at a system and form an impression in a few seconds. Alert thresholds exist to convert a continuous stream of state into a binary signal, so that a human is interrupted only when interruption is warranted.

Every one of those is a compression mechanism. Observability, structurally, is the practice of rationing information down to what one person can hold in their head.

Now consider service management.

Severity levels exist to decide who gets attention first. Queues exist to hold work that nobody is free to do yet. Escalation tiers exist because expertise is scarce and expensive. Change advisory boards exist because you cannot have everyone reviewing everything. Service level agreements are, at bottom, a promise about how quickly a limited number of people will get to you.

Every one of those is an allocation mechanism. IT service management, structurally, is the practice of rationing human attention across more demands than there are humans.

So the two disciplines are solving the same constraint from opposite ends. Observability rations information going into a person. Service management rations attention coming out of one. The person in the middle is the reason both fields have the shape they have.

Two disciplines, one constraint.

Neither discipline has ever described itself this way, and that is precisely why neither can see clearly what it is about to give up.

The Industry Has Decided the Constraint Is Gone

The case for removing the human from the middle is stronger than its critics admit, and I want to state it fairly.

Sampling really is a compromise made under duress. It throws away data that a machine could use, in order to produce a volume a person could survive, at a time when storage was expensive. Machines do not need the dashboard. They can hold more of a system in working memory than any engineer, and they do not get tired at three in the morning. A password reset does not need a queue. It needs an API call. If most service desk volume consists of a handful of routine request types, then a service desk built to route and triage those requests is a monument to a problem that no longer needs solving in that way.

All of this is true, and most of it is overdue.

But here is the move the industry is making without examining it. Having identified that human slowness shaped both disciplines, it has concluded that everything slow in both disciplines was there because of human slowness.

That does not follow. When you remove a constraint that influenced every design decision in a field, you cannot assume every design decision was only ever about that constraint. Some of them were about something else, and the fact that they happen to be slow is incidental.

Not Everything Slow Was a Bottleneck

Some of what these disciplines contain is a bottleneck. It exists only because a person is slow, it produces nothing except delay, and it should be removed without ceremony.

Sampling is a bottleneck. Manual correlation across three tools at two in the morning is a bottleneck. Categorising an incoming ticket by hand is a bottleneck. Routing it to the right queue is a bottleneck. First-line triage of a password reset is a bottleneck. None of these steps adds anything. They are tax.

But some of what these disciplines contain is a brake, and a brake is a different object entirely.

Severity classification is not a delay. It is a forcing function. It makes a named person state, on the record, what they believe the business impact of this event is. The output is not the label. The output is the commitment.

A change advisory board is not slow because the people in it are slow. It is slow because deliberation is what it produces. The meeting is not overhead attached to the decision. The meeting is the decision.

A postmortem is slow on purpose. Reflection is not latency. An organisation that learns from failure in four seconds has not learned anything.

These are brakes. They exist to introduce friction deliberately, at exactly the moments where speed is not the thing you want.

And from the outside, a brake and a bottleneck are almost impossible to tell apart. They look the same in a process diagram. They produce the same complaint in a survey. They both show up as a gap between when something could have happened and when it did.

They both look like waiting.

Bottleneck or brake? Both look like waiting.

What Removing a Brake Actually Costs

This is where the argument stops being a matter of taste, because there is now evidence.

Google’s DORA research has spent two years measuring what happens to software delivery as AI adoption rises. The 2024 findings estimated that increased AI adoption came with a decline in delivery stability of around seven percent. The following year, the throughput picture improved, but the negative relationship with stability held. Google’s own summary was that AI accelerates development, and that acceleration exposes weaknesses downstream.

The obvious defence is that speed pays for the damage. Ship faster, break more, fix faster, come out ahead. DORA tested that. The researchers checked whether AI’s throughput gains offset the harm from increased instability, and the data did not support the hypothesis. The instability was not paid for by the speed. It was simply absorbed somewhere else.

Now look at the sharpest forecast in the agentic market. In June 2025, Gartner predicted that over forty percent of agentic AI projects would be cancelled by the end of 2027. The number gets quoted everywhere, usually without its date, and usually as a verdict on the technology.

The number is not the interesting part. The causes are. Gartner named three: escalating costs, unclear business value, and inadequate risk controls. Model capability is not on the list. Not one of those three failure modes would be fixed by a better model.

Read that as an operations diagnosis and it becomes much sharper. Gartner is not describing organisations whose AI was not good enough. It is describing organisations that took the brakes off.

The causes Gartner named, and the one it did not.

“One observation from the field. The ideal shape is a case where a team automated a step that turned out to be load-bearing and discovered it afterwards, or a customer who kept a slow process against advice and was right to. It does not need to be dramatic. It needs to be specific and true.” 

The Sorting Exercise Nobody Is Running

If the argument holds, the work of the next few years in IT operations is not speed. It is sorting.

Take every slow step in both disciplines and ask one question of it. Is this slow because a human is slow, or is it slow because judgment takes time?

The first category should be automated without sentiment. Nobody should be defending manual ticket categorisation on grounds of craft. Nobody should be defending sampling once the economics no longer require it. These steps are not sacred. They were never anything but a tax on scarcity, and the scarcity is lifting.

The second category needs something more careful than removal. The point is not to keep a person in the loop for the sake of it, which is how human oversight usually degrades into a rubber stamp. The point is to change what the person is asked for.

Stop asking them to perform the work. Start asking them to decide on the record. Not “review this change,” but “state what you believe the blast radius is.” Not “triage this incident,” but “put your name on this severity call.” The machine can do the investigation, assemble the evidence, propose the action, and execute it. What it cannot do is be accountable for it, and accountability is not a slow version of a fast thing. It is a different thing.

The Ticket Was the Brake

Which brings me back to the funeral.

The industry has decided the ticket is dying. I think the opposite is closer to the truth.

Strip out everything around the ticket that was a bottleneck. Take away the routing, the categorisation, the queue, the tiers, the manual triage, the waiting. All of that was scaffolding built around a slow human, and all of it can go.

What is left is the ticket’s one irreducible function. It is the artifact where a named person accepted responsibility for an outcome. That is not a workflow step. That is the record of a decision, and it is the only thing in the entire apparatus that does not get faster when the machines get faster.

The service desk gets automated. The dashboard becomes optional. The queue disappears. And the thing everyone was most eager to bury turns out to be the one component that was never about speed at all.

So the question I would put to any team about to remove a slow step from their operations is a simple one. Do you know which kind of slow it was?