An AI Mission for Network Operations

A network alarms on what stopped working and stays silent about what broke. Everything difficult in network operations lives in the gap between those two things, and closing it is the part of the job that no one has ever managed to write down.

At ten past two on a Wednesday afternoon, an enterprise network operations queue goes from quiet to sixty events in under two minutes. Branch routers are reporting that their BGP sessions have dropped. A wireless controller is reporting that a block of access points has deregistered. Two synthetic transaction monitors are failing against the ERP, a replication job between data centres is falling behind, a DNS resolver in one region is timing out, and voice quality alarms are lighting up for a call centre that was fine ninety seconds ago. Every one of these reports is accurate. Not one of them is the problem. Somewhere underneath the noise there is a single link, or a single line of configuration that took effect at 14:08, and it is not alarming at all — because the device that owns it believes itself to be perfectly healthy, and by its own instrumentation it is.

This is the shape of nearly every serious network incident, and it is worth stating plainly because so much of the tooling built for network operations quietly assumes the opposite. A network is exceptionally good at telling you what it cannot reach. It is nearly incapable of telling you why. The alarms are the blast radius; the cause sits at the centre of it, usually silent, occasionally reporting green. The work of the next forty minutes is not gathering information — the information arrived all at once and in overwhelming quantity — but collapsing it: taking sixty correlated symptoms and reducing them to the one fault that explains all sixty, and being confident enough in that collapse to touch production.

Every alarm is a first-person account of a boundary

The reason the storm cannot resolve itself is structural rather than a failure of monitoring coverage. Each device reports from inside its own view of the world, and its view ends at its own interfaces. A router that loses a neighbour knows only that the neighbour stopped answering; it cannot distinguish a peer that crashed from a transit path that went away from a policy that stopped advertising the prefix it needed. A wireless controller that loses access points knows they stopped checking in, not whether that is a power event, a switch stack that reloaded, or a route that no longer exists between two subnets. Every alarm is a truthful first-person account of a boundary being crossed, and the union of sixty truthful first-person accounts does not add up to a cause, because the cause is generally the one thing in the topology that experienced no boundary event at all.

Worse, the most diagnostic fact in the entire incident is usually an absence. The interface that did not flap, the region that did not degrade, the branch on the same circuit that stayed up, the alarm that should have fired and didn't — these negatives carry more information than the positives, and no alarm system emits a negative. You have to know the topology well enough to notice what is missing from a list you were never given. That is a skill, and it is not a skill anyone is taught directly; it accumulates over years of having been wrong in interesting ways.

Which is why the collapse, when it happens, tends to look like intuition. A senior engineer scrolls the queue, discards forty events in about a minute, asks what changed in the last twenty, pulls up one device that nobody has alarmed on, and says something like "it's the second uplink, and the failover isn't taking because the policy on the backup path was edited on Monday." They are usually right. Ask them to explain how they got there and you will get a plausible narrative that is not actually the reasoning — it is a reconstruction assembled after the fact. The real derivation drew on topology held in memory, three prior incidents that felt similar, a vague recollection of a maintenance window, a sense of which alarms in this environment are chronically noisy, and an instinct about which timestamps cluster tightly enough to share a parent. None of that fits in a runbook, and every attempt to write it into one produces a decision tree that is obsolete by the next topology change.

The tooling stalled at the storm and never reached the collapse

This is the honest explanation for why automation in network operations has plateaued where it has. A great deal of engineering has gone into managing the symptom storm — deduplication, flap suppression, event correlation by time window or by parent-child relationship in a topology model, thresholds tuned to stop the pager firing at three in the morning. All of it is genuinely useful and all of it operates on the same side of the gap. It reduces sixty alarms to eight, which is a real service to the person on shift, but it does not tell them which of the eight is the parent of the other seven, and it certainly does not tell them that the true parent never alarmed. Correlation rules encode the failure modes someone anticipated. The incident that costs you an afternoon is almost always the one for which nobody wrote the rule, because it emerged from an interaction — a change, a redundancy path, a protocol timer, an MTU, a policy edit — that no static model contained.

The current wave of AI in operations is at real risk of repeating this, dressing the alerting layer in new language while leaving the inferential work exactly where it was. Gartner has predicted that over forty percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear value, and what it calls "agent washing" — established tooling relabelled without any change in what it can actually do unattended. A correlation engine that summarises the storm in fluent English is still a correlation engine. It has made the alarm queue more pleasant to read, which is not the same as having named the fault.

What it would mean to put the collapse itself into software

An AI mission for network operations, done properly, is not an alerting product with better prose. It is a system that treats the storm as the beginning of an investigation it is responsible for pursuing rather than a list it is responsible for tidying. The distinction shows up in what it does with the first ninety seconds. Instead of grouping events, it forms hypotheses: if these particular branches lost sessions and those did not, what do the affected ones share that the unaffected ones do not — a transit path, a route reflector, a firewall policy, a change window, a physical circuit. Then it goes and checks, because the systems that hold the answer are all reachable. Topology and interface state live in the management systems. Recent edits live in the change record and the configuration archive. Prior incidents with this signature live in the ticket history. Path and reachability facts can be gathered by asking devices read-only questions. A reasoning core with those observations available to it, working through specialist agents that each know how to interrogate one of those systems over a protocol such as Model Context Protocol, can do in a few minutes the narrowing that a human does by feel — and, unlike the human, it can enumerate the negatives, because comparing what alarmed against what should have alarmed and didn't is exactly the kind of exhaustive set comparison that machines are better at than people.

The output of that work is not an action. It is a defensible hypothesis with its evidence attached: this policy edit at 14:08 is the only change that intersects every affected path, here are the four branches it explains and the two it does not, here is the earlier incident that looked like this, and here is the proposed remediation. Then it stops, because production network configuration is not a domain where software should be permitted to change state on its own initiative. A qualified network engineer reviews the reasoning, agrees or disagrees with it, and authorises the change — under whatever change control the organisation already runs. Human-in-the-loop is not a hedge bolted on for comfort here; it is the correct architecture, because the cost of a confidently wrong configuration push is a larger outage than the one you were investigating. What the mission legitimately removes is not the judgment. It is the forty minutes of narrowing that precedes the judgment, which is where the outage minutes actually accumulate and which almost nobody enjoys doing.

This is the more interesting reading of what the autonomous enterprise is converging on, and what platforms like StudioX are built around: not systems that act without people, but systems that carry the inferential load between a signal and a decision, and hand a human something worth deciding on. In network operations that load has always been carried by a small number of people whose value to the organisation is precisely the thing they cannot articulate, cannot document, and cannot be in two places for at once.

The mental model worth taking from this is that a network does not have a monitoring problem, and it has not had one for a long time. It has an inference problem, and the two are almost perfectly inverted: adding monitoring makes the inference harder, because every new sensor adds symptoms to the storm without adding causes. The metric that would actually tell you whether your operations are improving is not how many alarms you receive or how quickly you acknowledge them, but how many alarms it took to name the fault — the distance, in events and in minutes, between the network telling you that fifty things are unreachable and something telling you which one thing is broken. Drive that distance down and everything downstream of it gets shorter. Leave it where it is, and you can buy every monitoring product in existence and still be waiting on one tired person to squint at a queue and know.