Self-driving networks have been the headline promise of every networking vendor's AI story for years. Like most things wrapped in AI marketing, the gap between what the technology can do and what most organisations are currently utilising it for is much wider than it should be.

Our honest take, after working in both the Juniper Mist and HPE Aruba Networking environments every week, is that the technology has matured much faster than the operational practices around it. So, if you have read the announcements and assumed this was still aspirational, the more accurate framing is that the platforms are well ahead of where most customers are leveraging them.

This is one of those topics where it pays to be specific about which vendor is doing what, where the genuine differences sit between the two platforms, and what good actually looks like once an organisation moves past the demo and starts managing the network leveraging the built in AI tools on a day to day basis. So that is what this blog sets out to do - with the caveat that the picture changes depending on whether you are operating (Juniper) Mist, operating (HPE Aruba Networking) Central, or maybe even in the position of running both.

Two platforms, two different journeys to the same destination

The most useful starting point is to recognise that Mist and Central have arrived at the AI-driven operations conversation from quite different directions, and the language each platform uses reflects that. Mist has been built around a closed-loop philosophy from the start, with a strong focus on what happens after the network is deployed, that is, Day 2 operations and beyond. The Marvis layer, and in particular Marvis Actions, has been the clearest expression of that philosophy, in which the system not only identifies an issue but increasingly proposes or executes the remediation. That is the closed loop in practice, and it is the area where Mist has been running ahead of the rest of the market for some time.

Central has taken a different approach. Its AI capabilities have leaned more heavily into configuration, monitoring, reporting, and the conversational copilot experience, where the system tells you what it thinks and recommends what to do, often leaving the action itself to the operator. That is changing, and closed-loop capabilities are progressively being built out, but it is fair to say that, as of today, closed-loop maturity is more visible on the Mist side. Anyone evaluating the two on the basis of AIOps alone should weigh that distinction carefully rather than assume parity.

Under both platforms, the engineering investment is increasingly shared. HPE's combined networking AI ops team is developing models that are pushed across all three deployment options, namely Mist in the cloud, Central in the cloud, and Central on-premises. The principle is “build once and deploy across both platforms”, meaning that a model developed or improved for one is improved for all over time. The catch, worth flagging because it often comes up in customer conversations, is that AirWave does not benefit from any of this. If your management plane is still AirWave, the AI ops conversation is essentially happening without you.  Even outside of AIOps, both Central and Mist provide incredible platform level features well beyond the scope of AirWave.

Clearing up the on-premises misconception

There is a fairly persistent assumption that AI-driven networking only works if you are willing to put your data into someone else's cloud. That assumption needs correcting because it is shaping decisions in the wrong direction; mainly in that if you have Central on-premises, it can still leverage a meaningful subset of the same models that the cloud platforms use.

The models themselves have been trained on vast volumes of data across the vendor's customer base; however, the data they process at runtime is entirely yours. For organisations in regulated environments, such as government and health, or anywhere data sovereignty is a live concern, that distinction matters and opens the conversation rather than closing it down.

There is also a financial tipping point for larger customers in our region, where the on-premises option can become more attractive, depending on the financial structures in place for capital investment versus opex.

What good actually looks like

Talking about self-driving networks in the abstract is easy, and it is also where most of the credibility leaks out. So it is worth grounding the discussion in a couple of examples:

  • A deployment often talked about by HPE is the Milan Winter Olympics, where the Mist platform underpinned back-of-house operations across more than 40 sites[1]. It’s not the front-of-house spectator Wi-Fi story that gets the marketing coverage; it’s the work that had to happen behind the scenes to keep media operations, team coordination, organising committee functions, and venue operations running across a highly dynamic three-week window.

A small team of IT professionals ran that environment across the full set of venues, and the only way that was achievable with a team of that size was because the network was largely self-managing. The dynamic nature of the deployment, where venues changed configuration daily, and traffic profiles shifted constantly, is exactly the kind of environment that reveals whether a platform is genuinely closed-loop or merely appears to be in a controlled demo.

  • Another example is the integration between MIST and ServiceNow. ServiceNow has built a dedicated application that triggers actions in the Mist environment without the operator needing to log in to the Mist dashboard at all. The integration also pulls signals back the other way, so optimisation suggestions and support tickets bubble up into ServiceNow as the system of record. The result is a closed loop that sits within the customer's existing operational platform, rather than asking the team to context-switch into a new dashboard, which is often where adoption breaks down in practice.

The reality at most customer sites

If the platforms are this capable, the obvious question is why the technology is not already running everywhere.

  • For those using Aruba, there are many who have not yet moved to Central. There’s no single reason for this; either they are running legacy on-prem management (eg. AirWave), or having mixed vendor environments, to name a few. We do know that those on Central have experiments and trials underway, but full operations using these capabilities remain in the minority.
  • Then there are the day-to-day barriers - Network teams are busy; consumed by migration projects (such as moving from AOS-8 to AOS-10), keeping AirWave alive for another quarter, or working through the consolidation of acquired environments.
  • And finally, it’s a case of “you don’t know what you don’t know”. Training is not extensive for many teams, and the value may not always be obvious from a vendor demo. Other priorities might take the time, and/or absorb whatever discretionary capacity is available.

How to actually get started

The most common mistake we see when an organisation decides to engage with the AI capabilities of either platform is treating it as a single, large initiative, which is the surest way to stall before anything tangible is delivered. The better pattern, is to ring-fence a specific use case, deliver real value within it, and use that as the reference point for the next conversation.

Practical examples we have helped customers with include:

  • Taking a single problematic site, building, or floor and using AI to resolve a recurring performance complaint that has been in the operational backlog for months
  • Resolving connectivity issues with an application that has been consistently flagged as troublesome
  • Ensuring priority service is available to a defined group of VIP users with higher SLA stakes, or in critical environments - such as in healthcare.

The point is to pick something narrow enough that the result is provable and important enough that it matters to someone in the business who can advocate for the next step.

From there, the conversation tends to broaden naturally. Once the team has direct experience of the platform performing real operational work, the appetite to extend its scope grows. The change management challenge is significantly smaller when the team has watched the system work on something they cared about, rather than having read about it in a vendor brief.

The question everyone is too polite to ask out loud

Any honest piece on self-driving networks has to address the question that inevitably arises in every customer conversation: whether this technology will reduce headcount in the network team. The short answer, based on what we are seeing across our customer base, is that it is the wrong question. Most organisations and education providers we work with are still short of skilled networking people. The bottleneck is rarely the cost of headcount; it is access to capable practitioners who understand modern networks well enough to operate them safely. AI tooling is starting to address that bottleneck rather than create a new one.

The pattern is more likely to be that organisations end up with similar headcount but materially greater capacity, because the same engineers spend less time on repetitive triage and more on the work that actually matters to the business. The networking profession has been carrying a do-more-with-less expectation for a couple of decades, and AIOps is the first credible answer to that expectation that does not rely on engineers simply working harder. The practitioners who learn to use these tools well are the ones whose careers benefit, while those who do not will find themselves at a disadvantage relative to colleagues who do.

That said, self-driving does not mean unattended, and the term itself is a step ahead of the operational reality, even in the most mature environments. Governance, oversight, and the human judgement that surrounds automation remain essential, and the organisations that get the most out of these capabilities are also the ones investing in the operational disciplines that support them. The technology is mature enough to be trusted for specific, well-defined decisions. It is not yet mature enough, on either platform, to be left entirely to its own devices.

Mature technology, immature adoption

If there is one framing we would push back on, it is the assumption that AI in networking is somehow an early-stage technology that the cautious organisation should hold off on engaging with. The capabilities in Mist and Central today have been developed over a long arc, with Aruba in particular having a long history of programmed optimisation algorithms such as AirMatch and ClientMatch that pre-date the current AI framing by years. What has changed is that those algorithms are now models, which can be queried and combined through agentic frameworks, and the sophistication of the responses has stepped up considerably as a result. The pace of improvement over the past two years has been notable, and anyone who looked at this space eighteen months ago and concluded it was not ready should look again.  Equally Mist has really innovated on conversational assistants and closing that loop for troubleshooting through Marvis actions.

In our experience, the maturity question is no longer really about the technology. It is about the customer's operational readiness, the willingness to invest in the small set of skills required to use these platforms well, and the discipline to start with a focused use case rather than an enterprise-wide rollout. Those are the variables that determine whether an organisation gets value from this category, and they are the variables we spend most of our time working through with customers.

Where to from here

Whether you’re considering or using Mist or Central, the practical next step is a conversation about what a focused, ring-fenced use case might look like in your environment, or what it would take to get genuine operational value from the AI capabilities you have already paid for. We work with customers across both platforms every day, and can help you scope that out. Get in touch for a discussion with one of our engineers.