I am an infrastructure guy at heart. Most of my time has been spent around data centres, servers, storage and backup, with a telco background somewhere underneath it all. Over the last 20 years, I have also had the benefit of working alongside some very talented network people. A fair bit has rubbed off.
Apparently, that includes Cisco and Juniper CLI commands from a decade ago that are still occupying space in my head. I can still think through the lower four layers of the seven-layer OSI model—from the physical link and data-link framing to IP routing and transport—and ask why traffic took one route, or why failover did (or did not) kick in. I have also spent enough time working through subnetting to know that a few digits can turn a tidy network diagram into an afternoon's detective work. I am not claiming to be a network engineer, but enough has rubbed off to make me curious about what happens between the connection and the application.
Those people taught me something more useful than the commands, though: “it must be the network” is not a diagnosis. You need to understand what the application is doing, where the information is going and what sits between the two.
That lesson feels particularly relevant now. We are getting very excited about AI models, agents and the infrastructure running them. I am excited too. But the infrastructure guy in me still wants to understand how the work gets there, where the bottlenecks are and what happens when something stops behaving. Are we waiting on the network, the storage, the model or an application that keeps sending everything back and forth? Buying a bigger connection is an expensive way to answer the wrong question.
Then there are the security boundaries that work crosses. Firewalls, intrusion detection and prevention still matter, but a secure connection does not make everything travelling over it trustworthy. We also need to think about prompt injection, malicious code and an agent treating untrusted content as instructions. More interesting technology, more useful possibilities—and a few more things to keep the infrastructure and security teams entertained.
That is why I want to revisit a question: in a world of SD-WAN, cloud services and increasingly capable AI, how much does the underlying network still matter?
My answer is quite a lot. Not because software-defined networking was a wrong turn, but because the work has changed—and the foundations need to support it.
MPLS and IP VPNs were not separate stops on a replacement journey
It is tempting to tell a tidy story: MPLS, then IP VPNs, then SD-WAN, and now AI factories. Each new thing replaces the old thing and we move on.
That mixes different layers together.
MPLS is a forwarding technology: packets carry labels that help direct them through a network. An IP VPN is a private connectivity service. A provider can use BGP and MPLS to deliver that service across its backbone, keeping customers' routes separated. The IP VPN did not have to arrive after MPLS; the service could be built using it.
For an enterprise connecting offices to centrally hosted applications, that managed private network could give the business a coherent service to buy and operate. Connectivity, traffic treatment, support and service commitments could be discussed together. What it actually delivered still depended on the design and the agreement—not simply the letters MPLS on a diagram. Private routing also should not be mistaken for end-to-end encryption.
As more work spread across SaaS, public clouds and different locations, the question became wider than how to connect branches to one centre. Which destination should this application use? Does its traffic need to come back through head office? Which connection is appropriate for this task?
SD-WAN gave us better tools for answering those questions. It can apply policy across different transports, including private connectivity, Internet and cellular services. It can use observed path conditions to steer application traffic. Depending on the implementation, it can also help mitigate impairments and improve the experience.
That is useful engineering. It is not the disappearance of the transport network.
An MPLS-based service can still carry an SD-WAN overlay. Internet access still relies on access networks, carrier backbones and interconnection. Software changes how we use those paths; it does not make their characteristics or shared dependencies stop existing.
Network foundations
Read the diagram
MPLS forwarding can support an IP VPN service. SD-WAN policy can use private or Internet transports. The AI fabric inside a compute environment is a separate domain from the enterprise WAN reaching it. These parts can coexist; this is not a replacement timeline.
The network adapted as the destinations changed
The evolution is not just faster interfaces. The shape of the traffic and the places it needs to reach have changed too.
Instead of assuming every important application sits in the organisation's data centre, we may need sensible paths to several cloud services, remote people and work happening at the edge. Sending everything through one location may be appropriate for some designs and an unnecessary detour in others.
This is also where SASE—Secure Access Service Edge—enters the conversation. As people and applications move beyond the traditional office perimeter, connectivity and security need to be designed together. The question is no longer just which path gets someone to an application. It is who or what is connecting, what they should be allowed to reach and how the required controls apply along that journey.
That changes the service design. It does not remove the need for a dependable network underneath it.
The core still has a job: carry the traffic between those places with the capacity, availability and performance the services need. Local access has a job too. An excellent backbone cannot rescue an overloaded wireless segment beside the person trying to work.
This is where I become wary of reducing the discussion to circuit speed. Bandwidth tells us something about capacity. It does not tell us the whole story about delay, variation, loss, congestion or usable application throughput.
A big pipe and a good experience are related. They are not the same measurement.
Nor is an SD-WAN tunnel reporting healthy proof that a person can complete the job at the other end. It is useful evidence about one part of the arrangement. We still need to look at the service people are using.
AI is not one kind of traffic
The endpoint is changing too. We can see that direction in Meta's smart glasses and the Samsung/Google Android XR ecosystem. It might be glasses helping a technician work hands-free, a mixed-reality headset bringing remote expertise into the room, a warehouse robot or an autonomous vehicle. We are no longer designing only for someone sitting behind a laptop. The network now reaches things that move, observe their surroundings and, in some cases, act on them.
That raises different questions about coverage, movement between connections, identity, information leaving the device and what happens when a service becomes unavailable. It also makes placement important: what belongs on the device, what can run nearby and what genuinely needs a remote service?
That does not mean every movement or safety-critical decision should wait for a cloud response. Some processing belongs on the device, some nearby and some in remote services. The design needs to say what continues locally, what becomes unavailable and what must stop safely.
An occasional text question and response is not the same workload as continuous video, a large data upload or a chain of dependent tool calls.
In the first case, model processing or service queueing might account for much of the wait. Buying more bandwidth may do very little. In another, the assistant must fetch information, wait for a tool, pass a result to another service and only then continue. Some exchanges can run in parallel; others depend on what came back before them. The placement of those services and the network journeys between them become part of the design.
Live voice, remote assistance and remotely rendered content bring another set of requirements. An interaction can be technically connected but awkward to use. The endpoint, codec and application adaptation matter alongside the network. Spatial computing does not automatically mean every movement or rendered frame travels across the WAN; that depends on the architecture.
Large files and datasets raise different questions again. Can we move them in the required window without making everyone else's work unpleasant? Where are the sources, and are we repeatedly transferring information that could sensibly remain closer to the processing?
AI does not invent these problems. Voice, video, storage and distributed applications have been teaching us about them for years. It gives us more reasons to ask the questions before the demonstration becomes something people depend on.
Inside the AI factory is another network problem
There is also a genuine infrastructure story behind the phrase AI factory. Here I mean the computing environment for AI workloads, not an organisation chart full of named agents.
Inside a large training system, accelerators need to exchange data as part of coordinated work. The fabric connecting them is part of the compute design, not just a way for users to reach a server. Inference designs vary, but can also depend on communication between compute, context stores and other services. Keeping expensive processors fed with useful work is an infrastructure concern as well as a model concern.
This brings attention to connections within accelerator systems, across servers and racks, into storage, and sometimes between sites. Those domains have different requirements. Their capacity, congestion behaviour, failure boundaries and operating visibility have to suit the workload.
But the fabric inside an AI factory is not the enterprise WAN that reaches it. A branch using a hosted assistant does not automatically inherit the requirements of a distributed training cluster. Equally, building an excellent cluster does not prove that the branch can reach its service reliably.
That is the connection I want to make across the evolution. We have added destinations, distributed the work and, in some cases, made network communication part of the computation itself. We have not found a layer where the underlying engineering no longer matters.
Follow one job from the regional office
Consider a fictional engineering business with a regional office. Someone uploads an inspection photograph, asks an approved assistant to compare it with work instructions and receives a draft note to review. No autonomous equipment control; just a useful piece of assisted work.
The office has two WAN connections and SD-WAN. The familiar dashboard looks healthy. At busy times, however, the task takes long enough that people start working around it.
I would not begin by declaring that the AI is slow or the network is undersized. I would follow the job.
How does the photograph get from the device to the service? What else is using the connection? Which path does the upload take through the required security services? Where are the instructions retrieved from? How long is spent moving information, and how long waiting for storage, a tool or the model?
These are different questions with potentially different answers. Wireless contention, a constrained upload, an unnecessary network detour, a slow retrieval service and a busy inference endpoint can all produce a frustrated person. They do not all need the same fix.
I would also want to know what the assistant is allowed to read and do. The photograph and retrieved instructions are inputs to the job, not permission to change its authority. A fast response that leaks information or triggers an unauthorised action is not a successful result.
The fictional inspection note
Read the diagram
Follow the whole task: device and local access, the approved network and security path, information retrieval and processing, then a useful draft for human review. Waiting can occur at several points. This is a conceptual illustration, not a measured trace or diagnosis.
Now move the office onto its backup connection. The overlay might successfully select the alternate path while the supported experience changes considerably. Can the person still upload the photograph and get a usable response? Do the required access and data-handling controls still hold? What happens when several people try? Should a large transfer wait while more urgent work continues?
That is the test I care about. Not merely whether the connection switched, but what work survived the switch. The example does not need an invented success story to make the point: it needs a design and a test that can tell us what is actually happening.
Resilience has to survive the diagram
Two services on an invoice do not tell us whether they share an access route, a building entry, power, equipment or an upstream dependency. Different providers do not automatically settle all those questions either. We need to understand the failure domains we are relying on.
Resilience beneath the diagram
Read the diagram
Two carrier services can share the same local duct. The cellular route shown avoids this particular trench, but that does not prove independence from power, upstream connectivity or other shared dependencies. Priority work continuing while a bulk upload waits is a design goal to test, not a claimed result.
Then there is the capacity of what remains. A backup path may be suitable for priority transactions but not the normal mix of uploads, meetings and AI-assisted activity. That can be a sensible business decision, provided we know the limits and have agreed what gets priority.
Planned maintenance matters as much as the dramatic outage. Can we take a component or path out of service without discovering that the alternate has never carried the real workload? Can we recognise a degraded service before a connection fails completely? Can the people supporting it see enough across the access, carrier, overlay, security and application layers to find the problem without an afternoon of passing it between teams?
For an AI factory, those same questions reach into its fabrics, storage access and management dependencies. Redundant links alone do not prove that the workload can recover. The application and platform need their own recovery arrangements, and the network has to support them under the conditions that remain.
Security belongs in that foundation too. Connectivity is not permission. Segmentation, access, encryption where required and approved data paths cannot become optional because a different route makes the demonstration faster.
A document can arrive through an approved service and still contain a prompt injection. AI is changing the pace of this work too: it can help defenders—or attackers—inspect software and binaries, look for weaknesses and connect clues across a system. That does not make encryption obsolete, but encryption alone cannot decide what an authorised agent should be allowed to read or do. The network team can help control which services are reachable and where data may leave; the application and agent design must enforce access and tool permissions, handle generated code safely and require human approval where needed. Those controls need to hold across the device and identity, network, application, the agent's tools and the software it depends on. None of that should depend only on the model deciding to behave.
We also need room for change. Growing demand, new destinations and different traffic patterns should be visible early enough to make a decision. That is more useful than buying to an impressive headline speed and assuming the foundation is ready for whatever follows.
Design the foundation around the work
The answer will sometimes be better connectivity or more capacity. It might instead be a better path, different service placement, fewer unnecessary exchanges, scheduled transfers or a fix to a non-network bottleneck.
Processing selected inputs locally can change what crosses the WAN. It can also add infrastructure to maintain, and the workflow may still need remote identity, current knowledge, tools or synchronisation. Moving the model is not the same as making the complete service independent.
Before calling the network ready, I would want to know which work matters, the experience it needs, where its dependencies sit, which trust boundaries it crosses and what useful work remains possible during degradation or maintenance. Then test that arrangement from where people actually use it—not only from a convenient point in the data centre.
This is not a return to treating every application as a reason to buy a premium private circuit. Nor is it a reason to assume every problem can be solved in the overlay. It is the ordinary infrastructure discipline of understanding what we are supporting and checking whether the design holds up.
MPLS, IP VPN services, SD-WAN and AI factories each belong in that conversation. They describe different parts of the system, not four generations in which the newest one makes everything before it disappear.
I still want the useful model, the capable assistant and the flexibility to put work in the right place. But as more of that work moves onto our faces, into vehicles and around warehouses, “the connection is up” becomes a fairly modest definition of success.
Before the next rollout, I would want us to answer three questions. What work are we making dependent on this connection? What can continue locally—or stop safely—when it degrades? And have we tested that, or are we taking comfort from a diagram with two lines on it?
We spend plenty of time asking what the next generation of AI will be capable of. Perhaps we should spend a little more asking what our foundations will let us depend on.
If the preferred connection or remote service became unavailable tomorrow, which parts of your business would keep working—and which would discover their dependencies for the first time?