Most of the regional fiber operators I talk to run network operations with a small team. The same few engineers handle alarms, escalations, change windows, and vendor tickets. As the network grows, the alarm count grows with it. The team usually doesn't.

A 2026 study by Omdia, commissioned by Cisco and covered recently in ISE, puts numbers on that gap. Across 1,000 IT and network operations leaders, the average organization generated about 4,100 monitoring alerts and events a day, roughly half of them network-related. One practitioner can work through about 21 network alerts a day. Not surprisingly, 46% of network alerts are closed without anyone investigating them, and the median incident takes 12.5 hours to resolve. The mean is 88 hours, seven times the median, which is a fair measure of how long the worst ones run.

Those respondents work at enterprises with 500 or more employees, not broadband operators. If anything, the math is harder for a regional operator with fewer engineers per device. That is why AI troubleshooting is so attractive, and why I think operators are right to be careful. A wrong recommendation in a chat window is an inconvenience. The same mistake executed on a live network is an outage.

My team has spent the past year running AI troubleshooting in beta, with our own engineers and a group of fiber operators. The lesson I keep coming back to is that the question isn't whether to use AI in the NOC. It's how to use it without losing control.

Treat Autonomy as Levels, Not a Switch

"Self-healing network" is one of the most overused phrases in our industry. It's usually presented as a finished state, as if networks will fix themselves once enough AI has been applied. That framing doesn't help anyone who must sign off on the risk.

I find it more useful to think about autonomy in three levels. At the first, assisted, the AI runs diagnostics and proposes a fix, and an engineer approves every change. At the second, supervised, alarms arrive as already diagnosed approval tasks, so engineers confirm them in bulk instead of investigating each one. At the third, autonomous, the system carries out the fix on its own, but only for specific fault types with a proven record.

The important detail is that you don't move your whole network up a level at once. You promote one fault type at a time, on your own evidence and your own timeline. Rebooting a single subscriber's ONT and rerouting traffic across a ring carry very different risks. They shouldn't share a permission setting.

The data suggests network leaders already think this way. Among organizations already running agentic AI, 56% said they wanted a human to approve actions, 24% were comfortable with full autonomy, and 20% wanted little or none. Yet 82% said they would let AI make production changes without asking first for at least some categories of action. That qualifier is the point.

So, when an operator asks me whether a platform "does self-healing," I suggest a better question: which fault types can you show running autonomously, and what evidence supports that?

A General-Purpose Model Isn't Enough

When we started, the limiting factor wasn't how capable the AI model was. It was that live networks punish the habits general-purpose models have by default.

The first is missing facts in long inputs. Researchers at Stanford and elsewhere found that language models use information at the start and end of a long input far more reliably than information in the middle (Liu et al., "Lost in the Middle"). Hand a model a full runbook and a large device dump, and it can skip the one line that matters. The second is inconsistency. The same question can produce different answers on different runs, while most fault resolution follows a correct sequence. The third is confidence: a model can recommend the wrong fix with complete certainty. The fourth is the long tail. Every mix of vendor, firmware, and configuration produces behavior no general model has seen, and that's where real incidents tend to live.

We saw this ourselves. Our first working version was a single large prompt carrying every instruction we could think of. Across a narrow set of faults it did well. As we extended it to cover more failure modes, accuracy fell away sharply, and no amount of rewriting recovered it. The problem was not the wording. We were asking one undifferentiated context to hold every rule for every fault at once. That is an architecture problem, and prompts do not solve architecture problems.

What made the difference for us was breaking troubleshooting into fault classes. Each fault class describes one failure mode: how to recognize it, which diagnostics separate it from similar causes, which fixes apply, and what proof of resolution looks like. When an alarm fires, the AI works only with the few relevant classes, so the input stays small and nothing gets lost in the middle. New classes can be added without disturbing the ones already in use.

I'd also encourage operators to ask whether these capabilities are built on open standards. The Model Context Protocol (MCP), which Anthropic contributed to the Linux Foundation's Agentic AI Foundation in December 2025, lets your own AI tools use diagnostic and repair tools rather than locking them inside one vendor's interface.

Make Sure the Loop Closes

In our experience, the difference between a convincing demo and a system you can run in production comes down to what happens at the end of the troubleshooting process.

The process itself is straightforward. An alarm triggers the AI automatically, so nothing waits in a queue for someone to notice it. The AI reads the current state of the devices and services involved, rather than relying on documentation that may be out of date. It matches the alarm to a fault class and runs that class's diagnostics. Because diagnostics are read-only, this part can run with no human involvement at all. It then proposes a specific fix, with its reasoning and the exact action it intends to take. Depending on the autonomy level, an engineer approves it or the system proceeds.

The step that matters most comes next. Most automation is optimistic: it runs a command and declares success. We require two things before an issue counts as resolved. The diagnostics must pass when re-run, and the alarm must clear. That separates "the command worked" from "the subscriber's service works."

If the fix surfaces a different error, the AI moves to that fault class and keeps going, because real incidents are often two problems behind one alarm. A failed provisioning job is a good example. The alarm says the ONT has not been discovered by the OLT, and that is the fault an engineer would work on. Clear it, and a second one often appears underneath: optical receive power outside its acceptable range. That fault was always there, but it was invisible, because the ONT has to be discovered before the OLT can read its optical levels at all. This is why we define success as the outcome the subscriber needs, an ONT in a working operational state on the PON, rather than as the clearing of the error that raised the alarm. The loop runs until that state is reached or the diagnostic path is exhausted. A system that stops after the first problem just hands your engineers half-finished work.

Build the Guardrails Into the System

Network leaders are clear about their conditions. In the study, only 1% would let AI act with no guardrails at all. Respondents picked an average of three from a list of six: explainable actions, human approval, policy-based limits, emergency override, role-based access control and immutable audit trails. Separately, 69% said they need detailed explanations of any action an AI agent takes.

Many vendors answer the safety question with process: a policy document, a review board, a promise of human oversight. Those help, but they don't enforce anything. I'd argue the stronger answer is an architecture where the unsafe action isn't available in the first place.

In practice, that means the AI works with the permissions of the person it's acting for, not its own. Your existing authentication and role-based access control stay in force, and the AI can't do anything that user couldn't do by hand. There's no privileged service account quietly holding broader rights. Every diagnostic and every action runs through one path and is logged, so a post-incident review covers what the AI did as completely as what a person did. And when the AI asks for approval, the request includes its reasoning and the exact change, so your engineer is deciding rather than clicking accept.

Where the AI runs matters too. Most respondents (86%) said a single integrated platform is the best path forward, rather than another point tool. For a fiber operator, an AI that works inside the system already handling provisioning, activation, and field dispatch can see a subscriber's service state and recent work orders. One attached to a separate monitoring tool sees only the alarm.

Measure Before You Trust

Promoting a fault class to autonomous action is only defensible if you can measure whether resolutions work. That makes measurement the thing that permits autonomy, not a report you produce afterward.

We use three independent checks together. A separate model scores each resolution against the expected outcome, providing a consistent score across many cases. For each fault class, we monitor specific diagnostic values to confirm the underlying condition has changed. The engineer also confirms whether the issue was resolved, which serves as the ground truth the other two checks are calibrated against.

These run as a regression suite against a labeled set of real past faults, so an improvement in one fault class can't quietly make another worse. The result is a first-pass resolution rate for each fault class. That's a number you can take to a change review, rather than a feeling that the AI seems to be working.

Sponsord by: