What "Self-Driving Networking" Actually Means

Nearly a year has passed since Hewlett Packard Enterprise and Juniper Networks came together, and the industry has been watching closely to see whether that combination would produce something customers couldn't get from either company alone. Kevin Hutchins explains how the combined organization is shaping the future of networking in the AI era.

At HPE Discover 2026 in Las Vegas, David Nicholson and Tom Hollingsworth sat down with Kevin Hutchins, SVP of Strategy and Corporate Development for HPE Networking, to examine how AI is reshaping networking requirements and what self-driving networking actually means once you move past the keynote positioning and into operational reality.

Hutchins shares what the HPE and Juniper integration has made possible for customers so far, why networking has become a critical foundation for AI initiatives, and where organizations are encountering the biggest challenges as AI moves from pilot projects into production. The conversation also explores the rise of self-driving networking, what that actually looks like in practice, why autonomous operations are becoming increasingly important, and how AI-native networking is changing the way enterprises manage and scale their environments. Hutchins closes with his perspective on the trends that will define the next generation of networking, and the steps technology leaders should take today to prepare for what's ahead.

‍

Key Takeaways:

🔹 Nearly a year after bringing together HPE and Juniper, the combination has enabled capabilities for customers that neither company could deliver independently.
🔹 AI places fundamentally different demands on network infrastructure across data center, cloud, and edge environments.
🔹 Networking has moved from a background consideration to a strategic priority in the AI era.
🔹 Organizations scaling AI past the experimentation stage are running into specific networking challenges. Hutchins identifies where those friction points show up most and how HPE is helping customers address them before they become production blockers.
🔹 Self-driving networking is moving from a vision to an operational discipline. Tom Hollingsworth asks Hutchins to define what that actually means in practice, why the shift toward AI-native and autonomous network operations is gaining urgency, and what it requires from enterprise infrastructure teams.
🔹 The next generation of networking will be defined by specific characteristics, not just faster speeds. Hutchins closes by identifying those defining qualities and what enterprise leaders should prioritize now to build toward them.

The Juniper integration gave HPE a networking portfolio with real breadth. Whether that breadth translates into AI-era leadership depends on the self-driving operations strategy.

Watch the full video at sixfivemedia.com, and be sure to subscribe to our YouTube channel so you never miss an episode.

Disclaimer: Six Five Media is for information and entertainment purposes only. Over the course of this webcast, we may talk about companies that are publicly traded, and we may even reference that fact and their equity share price, but please do not take anything that we say as a recommendation about what you should do with your investment dollars. We are not investment advisors, and we ask that you do not treat us as such.

Kevin Hutchins:
While the network has historically always been an important layer of design, it was never really viewed as kind of a first-class citizen. But now you really have to be thoughtful about the design of the network if you're going to deploy inferencing for production purposes or you're going to deploy agentic in production. Now the whole conversation is starting to shift that way.

David Nicholson: 

Hello and welcome to Six Five On The Road here at HPE Discover 2026 in Las Vegas, Nevada. I'm Dave Nicholson and I'm joined by Tom Hollingsworth. Tom, always good to be with you. 

Tom Hollingsworth:

Same, Dave. 

David Nicholson: 

We've got a very interesting guest, Kevin Hutchins, who's Senior Vice President of Strategy and Corporate Development for Hewlett Packard Enterprise. networking, which is quite an interesting subject because as we sit here some year or so into this combination of specifically Juniper and all the rest of HPE networking, where are we today versus where we were a year ago? How's it going? Is it a one plus one equals three or has this thing gone off the rails?

Kevin Hutchins: 

Well, it's an interesting start. First of all, thanks for having me. It's great to be with you guys and it's going really well. It is, I think, It's a little early to say it's 1 plus 1 equals 3, but in the 11 months, we've accomplished a lot. Our focus initially was on how do we make sure that we don't get sucked into the interior focus that can easily happen in this situation. But instead, we stay focused on customers, we stay focused on innovation, we stay focused on actually driving the business forward. And I think when you look at the first two quarters of official results, and you look at, you know, like announcements that we're making here at Discover, we're definitely doing that. The business is growing well. We grew 148% last quarter. We're continuing to win new business. We're driving both our strategic priorities of AI and networking and networking for AI. You know, we're getting a lot of new account wins. And, you know, the innovation, the number of things that we're actually driving, both within HP networking, but also across and taking advantage of all of HPE is also, you know, making a lot of progress. So I feel like all in all, you know, for a deal of this magnitude and complexity, that we're in really, really good shape, but I think there's a lot more upside to come. So that's why I'm sort of saying, I think, you know, to call it victory and say one plus one equals three, it's early. I feel like there's still work to do there. We can see a lot more come out of this over the next several months, and I'm excited.

David Nicholson: 

But so far so good. Big companies, sometimes when they acquire another entity, when they come together, that parent company, if you will, ends up responding to the acquisition like the human body responds to a virus. And, you know, seek it out, not invent it here. So, you're not seeing that. You're seeing good movement.

Kevin Hutchins:

No, actually, I mean, and there's multiple parts that, you know, we're sort of learning because HPE is a very large organization with a lot of business. But I would just say they've done a phenomenal job of really giving us the ability to focus on building the HP networking business, which is, you know, it's the number two OEM in the market. And that's before we start to really create a lot of acceleration that hopefully will give us a shot at taking leadership in a number of areas. But they've given us a lot of ability to really create that focus and energy around our business. At the same time, we are working across with the other business units to build solutions. We built the Helios architecture and solution, working with our compute colleagues, as well as with AMD. We're working closely with our compute team as well as the hybrid cloud team on NVIDIA-type solutions for private cloud, for AI, for AI grid. We have a lot of examples where we're getting that support, but we're also being left to operate so that we're not being slowed down from the business of delivering for our customers. Because at the end of the day, the real metric of success is, are you winning and capturing the hearts and minds of your customers? So it's been going pretty well.

Tom Hollingsworth: 

One of the things that we've heard a lot about over the last several months is AI. We can't escape it. Because one of the things that's happening is it's putting a lot of interesting challenges in front of people who are working in the data center, in the cloud, and on the edge. But now here at HP Discover, we've heard a lot about why networking is so important to AI. What's your take on that? Because that's not a conversation that I've really heard come up except here recently.

Kevin Hutchins: 

I think what's interesting is when you really think about AI, you kind of step back, I guess, maybe two or three years ago to what I call the chat GPT moment. And sort of before that point, most people were not talking a lot about AI, right? That was kind of, you know, sort of a niche thing. But since then, it sort of kicked off what I consider to be waves of adoption. So, like in my role, I tend to think about things in terms of big technology inflections and what does that mean in terms of the way the market's going to move. And, historically, the big ones that affected our business were, first, the internet, and then, second, the cloud build-out, and then, third, was digital transformation. Now, since the Chad GPT moment, we've transitioned into this period of AI But that's not like one sort of monolithic inflection. There's actually a series of inflections that are kind of, you know, taking place. So the first one was really almost like this, what I call the training wave, where people really started to focus on How do I build the biggest models with the most parameters? How do I build data centers to enable me to build those types of big foundational models? That's where you saw a lot of people start to think about Sovereign and that we're going to create specialization of models. So that's kind of like the first wave. And that's one particular type of networking, right? You remember like people were talking a lot about InfiniBand versus Ethernet. People were talking a lot about, like, how do we build these very large scale fabrics with RDMA over Ethernet? And can we actually deliver that type of scale? But that's kind of like the first wave. The second wave, which I think we're really just starting on now, is this inferencing wave. The classic thing is training is all about building the model. Inferencing is about using the model. Now it's about tokens per second. It's about latency. It's about the ability to actually monetize And that's creating a whole new set of questions about what do you need to do in order to deploy an application with inferencing into production. And that has networking implications. Especially when you think about latency requirements, you think about the ability to access a context cache, that has implications for the network. And then we're moving now increasingly into this agentic wave. And that's, you know, obviously that's a big theme for us here at Discover is talking about the enterprise adoption of agentic and what that's going to require. But, you know, if you just think about this idea that now we're going to have multiple models deployed as agents, they're all going to be consuming data, they're all going to be accessing tools, they're all going to be communicating with each other. All of that's going to require a network fabric that's designed to perform for that particular use case. And so I think that while the network has historically always been an important layer of design, it was never really viewed as kind of a first class citizen, because it was always the compute and the application and the application stack that really drove a lot of decision making. But now you really have to be thoughtful about the design of the network if you're going to deploy inferencing for production purposes, or you're going to deploy agentic in production. Because if you don't, you're basically going to see a suboptimal type solution. And that's why I think now the whole conversation is starting to shift that way. And I don't think it's just us. I think I'm hearing this sort of being echoed in other parts of the industry. But I think, you know, this is something that we're obviously very firm believers in. And so we're really starting to drive that agenda towards, you know, get your network in place before you start to really think about adopting and deploying these things at scale, because you are going to be limited by your network.

David Nicholson: 

Yeah. So if you're at a dinner party and you happen to be sitting next to a CTO, you know, there's obviously when you talk about AI and networking, there's two sides to that. There's the workload that is in the network, and then there's leveraging AI to actually manage the entire thing. And I know Tom wants to talk to you about self-driving networks and what that means, but aside from that, what are you seeing the challenges are for people when they're looking at networks in the era of AI now, and what's kind of that recurring theme that you're seeing people deal with right now?

Kevin Hutchins: 

Yeah, so I think what's interesting is, for networks for AI, you have to think about maybe three really important things. There's probably more, but I would just sort of maybe try to break it down into three important things. So one thing is, now we're talking about network performance that matters meaningfully. If I deploy a network, if I'm going to try to build a training cluster, I'm going to try to train a very high dimensionality model, If I'm going to deploy an inference workload, whether I'm going to deploy it at the edge or I'm going to deploy it in a central data center and try to consume that, or I start to get into a Gentic, the performance of the network fundamentally matters. It fundamentally matters in terms of things like congestion control, driving, tail latency, and a training workload. It fundamentally matters in terms of tokens per second. It fundamentally matters in terms of my ability to support the directionality of traffic, including East, West, and North, South type consumption. So I really have to be thoughtful about the performance of the network. When we start talking about some of the technologies that are now being developed for things like collapsing layers or enhanced load balancing and congestion control, these are necessary in order to enable that performance. The second thing is it's end-to-end. So there's very few clusters today that are being deployed that are just like one contiguous giant envelope of power and compute. It's almost impossible to get that kind of compute sort of allocated these days. So now what you're seeing is I have to actually start to think more about the scale across, right? not just scale up and scale out, but scale across. And I have to create logical clusters over distance. And that's when you have to start now thinking about, this isn't just a single data center. Now this is a collection of data centers. But the end-to-end performance is going to be driven by the end-to-end network. So I have to design each domain of the network to work together to deliver on that performance expectation. And then the third is, and I'll just touch on the point that you described about self-driving, it's as much of a ability to continue to observe and manage the network as it is to deploy a very high-performance network. So, you know, if you just think about, again, like, you know, I'm building these very large, complex networks that are very high-performance. I'm sending a lot of data over them very, very fast. I can build up hotspots, I can have temporary areas of failure, like a link flap or something like that. If I'm not sensing that and responding to that very quickly, then I'm going to see the performance of my entire job suffer. So you have to think holistically about this, not just at the network elements itself, but also how do I manage, orchestrate, observe, and remediate in real time? Otherwise, I'm going to suboptimize.

Tom Hollingsworth: 

Yeah. I think it's interesting you brought up the self-driving network idea because I know that was something that Juniper was really starting to investigate before the acquisition. And with Marvis, you guys have really pioneered a way to kind of put a face to that. And one of the questions that keeps getting asked around here is, well, that's great for people who are in kind of user land, but what happens when we move into the data center? Do you guys see moving the self-driving concept into the data center? as a big challenge or is it more that you've already built a great framework there that you're really extending into just a different kind of workload?

Kevin Hutchins: 

Yeah, so I would definitely say it's more of the latter. So we think the framework really is a good extensible framework because essentially the way that we designed Marvis, right? So Marvis being our AI engine now becoming our agentic framework. We designed it around the idea that we're not just trying to build a better system for what previously was the way that you would monitor and manage the network. What we're really trying to do is build a system that delivers better outcomes, right? Now, for a user network, right, which is, you know, what we've done with Mist and now extending that to the client to cloud network, It is predominantly about the user experience, right? Are they having a good experience? Is their Teams application working as expected? And can you isolate that down to the individual session where there may be potentially an issue? Inside the data center, a few things. One, you have things operating at much higher speeds. Right. So when something is actually going to go sort of maybe off the rails a little bit, it's going to happen in very, very short time increments. So being able to sense that very quickly and being able to make adjustments for that is really more important there, frankly, than it is even in client cloud. Right. Like you're going to notice those things much more. The second is that while I think most people think inside the data center like we have scaling mechanisms and failover mechanisms that are already built in place, there are limits to what those solutions can do and they can impact the performance of the application. So for example, if like I have a failover, but the failover is in another data center, and it's going to take time to actually move traffic over to that other data center. I'm going to notice that as the consumer of that application. But these are all things that we can manage as part of a self-driving network solution to help mitigate some of that. And then the last thing I would just say is the framework, what's really important about what we've done is not only did we think about creating sort of a reactive system, our system now is also proactive, right? So that's something that we pioneered as well, is creating sort of this continuous monitoring to say, like, if I know that the network needs to be like there's an issue in the network there's a service in the network that's not running properly and now i can address that proactively before something actually goes wrong basically i've saved operator cycles from having to get involved in the network and the end of the day we just have we have so many more things to go do. Our IT teams, our cloud teams, they have so many more things to go do than manage these set of issues. So are we going to take all the issues off their plate? Probably not. But if we can take number 24 through 30 off their plate, or we could take number three through 24 off their plate, and then they just focus on the top two that are ones that they need to address, then we've created a significant amount of value for our customers. So that's the way we think about it.

David Nicholson: 

So I've got something for you in our last moment. In bullet points, I tell you I want to make sure I'm future-proofing my networking. I'm an existing enterprise. I'm moving into the world of AI. I may be upgrading some stuff tomorrow, but over the next year or two, we're going to be going through a transformation. Give me the bullet points on what I can do to make sure I don't paint myself into a corner. How can I future-proof?

Kevin Hutchins: 

Yeah, it's a good question. So I think the first thing is, when you're deploying your network, the idea that I want it to be there for a long period of time, and I want it to live with me as I grow my business and I change. First of all, I know this is going to sound a little bit innocuous, but you should be standards-based, right? I think that the one thing that gets customers in trouble more often than not when they're thinking about future-proofing is they deploy solutions that are either proprietary or based on technologies that require only one company to innovate, and that sort of boxes them in down the road. And so, if they can be standards-based in terms of that deployment, that will make a big difference. And we saw that in the past with InfiniBand versus Ethernet. InfiniBand is a great solution, but it's very specific to a certain type of technology roadmap, and it creates limitations. So standards-based is one. The second thing is they should build with the idea that it really does have to be manageable, observable, and easily remediated when there's a problem. And so build the architecture for that early. So whether you're going to adopt our framework for self-driving, you want to adopt a different framework, you just have to build it with the idea being that you know, that's the more important part of the lifecycle of the network is it because those are all the interfaces that you're going to use to build, operate and scale that network over time. You know, go there early. And then the last is design for security integrated with the network. Don't don't think about it as two adjacent ideas. Design them together so that as your network grows, you're actually secure at the same time, because that also creates a lot of complexity. Yeah.

Tom Hollingsworth: 

Kevin, thanks for joining us. And thanks to all of you for tuning in for Six Five On The Road at HPE Discover 2026. Don't forget to subscribe, follow us on all the socials, and check out more coverage at sixfivemedia.com. But we've got more on the way, so don't go anywhere.

‍