Self-Driving Networks Need a Graph: Causal Root-Cause AIOps
Rami Rahim, who runs HPE's networking business, says AI will handle every network trouble ticket without a human within two to three years. It sounds like a detection claim. It is really an attribution claim, and attribution is a graph problem.
The claim is bigger than it first sounds
HPE's numbers are not modest. Rahim puts 70–80% of trouble tickets as already resolvable without a human, climbing to "all of them" in two to three years. SDxCentral reported the same curve from the HPE side: more than 80% of incidents either fully self-remediated or answered immediately with a known cause — up from roughly 50%, then 60%, then 70% over the preceding years. Customers in HPE's case studies report ticket volume falling by more than 90%. The UK Ministry of Justice is cited at roughly 75% fewer service-desk tickets after bringing about 15,000 devices back in-house.
The machinery behind those numbers is a fabric of "Marvis" assistants, an agentic framework HPE calls an agentic mesh, and OpsRamp observability folded into network fabric management. The interesting part is not the size of the model. It is what the model is allowed to look at — and act on.
"The Wi-Fi sucks" is the whole problem in three words
Ask any network team what their top ticket is and you will get some version of a bad Wi-Fi complaint. The complaint is about the experience; the fault is almost never in the Wi-Fi. It is an application, a WAN link, a cloud region, DNS, an identity provider, or a saturated uplink sitting deep behind the access point. The user's symptom is the far end of a dependency chain.
This is why detection is the easy half. Any observability stack can raise a thousand alarms when one upstream link degrades. What a human does in the next thirty seconds — and what an autonomous system must do — is collapse that storm to a single origin. That is causal attribution, and doing it well means reasoning over the dependency structure, not the alert list.
Model the estate as a graph, because it already is one
A network is already a graph: access points, switches and routers as nodes; links, VLANs, tunnels and service chains as edges; and above them, a second layer of dependencies — this access point serves these users, this service is hosted on that cluster, this app depends on that API. Health is a property of nodes and edges; a fault is a node going bad that drags its descendants down with it.
Under that model, fault localisation becomes a precise question: find the smallest set of nodes whose failure explains the whole set of observed symptoms. The classical formulation is a Bayesian network with noisy-OR gates; the modern one is a graph neural network over the topology, or a causal graph scored with do-calculus. Either way the graph is the substrate, and the answer is a subgraph, not a score on a dashboard.
A concrete HPE demo makes the loop legible. A "bad user minutes" metric ticked above 6%. Rather than page someone, the system localised the experience regression to a handful of over-utilised access points, enabled the dual-band 5 GHz radio, and drove peak utilisation from 90% down to 54% — before a single user filed a ticket. Measure the experience, localise on the graph, act on the localised node. That is the pattern worth copying, whichever vendor you run.