Login for Polarin
Lightstorm

Blogs

Latest Resources

The one tier of the AI stack nobody has funded
Blogs

The one tier of the AI stack nobody has funded

Every layer of AI infrastructure has a gap. Power, compute, memory and cooling get the headlines and the capital. The network between data centres gets neither — and the numbers say it is the layer falling furthest behind. At the AI Infra Summit in Santa Clara this September, Lightstorm and Nokia put a piece of work on stage that we have been building for most of this year: a quantified case that the wide-area network is the one tier of the AI stack the industry has not yet invested in, and a plan to measure exactly when that matters. The analysis behind it is public — a preprint on arXiv ( arXiv:2608.14967 ) that we tested with industry collaborators before publishing. This post is the short version, written for the people who run networks, data centres and GPU fleets. Every layer has a gap. One of them has no thesis. Ask anyone in AI infrastructure where the bottlenecks are and you will get a familiar list — power, GPUs, HBM, cooling, land. All real. All also well funded: every one of those constraints has an investment thesis attached to it, and capital is flowing at it. Now trace the path a byte takes between two GPUs in different cities: accelerator, HBM, NVLink inside the rack, the scale-out fabric inside the building, the wide-area network to the next site, storage. The industry has spent heavily on every hop in that chain — HBM stacks, NVLink and NVSwitch, 400G and 800G scale-out fabrics — except one. The link between data centres still runs on infrastructure that was sized for pre-AI traffic, and it is the only tier in the continuum without an investment thesis of its own. The number that shows it To compare tiers that have nothing in common — memory buses, switch fabrics, long-haul fibre — we use one metric: the bytes of bandwidth a tier can deliver to a GPU per FLOP of that GPU’s compute. We call it the compute interconnect ratio, or CIR, and report it in millibytes per FLOP. For an H100 at 989 TFLOPS dense BF16 the ladder looks like this: HBM sits at 3.39 mB/F, NVLink at 0.910, scale-out InfiniBand between 0.006 and 0.050, and a conventional shared WAN — 1 to 10 Gbps per eight-GPU node — lands somewhere between 0.0000158 and 0.000158. Four to five orders of magnitude, top to bottom. The gap is also widening. GPU compute has grown about 48% a year on a dense basis from the A100 in 2020 to the B200 in 2025, while network capacity at every tier has grown 25–32% a year — so the bandwidth available per FLOP beyond the package falls 11–16% a year, and the compute-to-bandwidth gap widens 12–19% a year. The shape of it is what I find most telling. On a consistent dense basis the B200 generation actually holds on-package CIR roughly flat — HBM at about 3.56 mB/F against the H100’s 3.39 — and lets NVLink slip only modestly. The tiers the industry funded have broadly kept pace with compute; the wide-area tier, which nobody funded, has not. That is what “no investment thesis” looks like when you plot it. Why inference, not training, forces the question Training tolerates the WAN — asynchronous gradient exchange between sites needs on the order of 5 Gbps in our model, and the workload can wait — and inference does not. A 70B multi-head-attention model at 4K context carries a 10.7 GB KV cache. Moving that between a prefill site and a decode site inside a 40 ms time-to-first-token budget takes 2,147 Gbps of transfer capacity: roughly 429× the training demand, and 215× a dedicated 10 Gbps link. I want to be careful with that number, because it is the multi-head-attention bound. Modern attention architectures cut cross-site demand by 8–37×: grouped-query attention at 1/8 KV heads needs about 268 Gbps, latent attention around 58 Gbps. Anyone who leads with the 2,147 figure and stops there is overstating the case. But the same architectures that shrink the demand also shrink the point at which moving state across sites becomes cheaper than recomputing it. For 70B MHA that crossover sits at 74–111 Gbps per stream; under GQA it drops to 9–14 Gbps, which is a link rate any wide-area service provisions routinely today. Modern attention does not make the network stop mattering. It makes cross-site disaggregation stop being exotic, and it moves the binding constraint from “can one stream cross?” to aggregate capacity and tail behaviour. Agentic workloads are where the aggregate shows up. A 20-step agent session with growing context, re-transferring its accumulated state on a fraction of its site-hops, moves around 25 GB under GQA; ten such sessions a second is roughly 2 Tbps of sustained cross-site demand — latency-tolerant per step, bandwidth-hungry in aggregate, and bandwidth-bound even at continental distance. The answer is not “more bandwidth everywhere” The industry collaborators we tested this with pushed us hardest here, and rightly. More bandwidth helps; the question is whether provisioned bandwidth beats the alternatives — recomputation, KV compression, locality-aware routing, or simply overprovisioning a packet backbone — and the answer is: only in specific regimes. At list GPU prices, recomputing the prefill is cheaper than transferring it. Transfer wins when GPU scarcity and KV reuse multiply the effective cost of a GPU-second by roughly 5–20× — hot fleets, agentic pipelines, GPU-scarce markets — and modern attention moves that breakeven an order of magnitude in transfer’s favour. Compression is a genuine substitute up to a quality ceiling: 8× KV compression lifts prefill-GPU utilisation on a 10G link from 12% to 52%, but the KV channel carries reasoning capacity, not just latency, and past a point only real bandwidth preserves both. The packet-versus-optical debate resolves the same way. A well-run IP backbone reallocates traffic in milliseconds, but statistical multiplexing and traffic steering allocate capacity that is already lit; they cannot create it. When aggregate demand between two sites approaches what is lit, queueing takes over regardless of routing intelligence — p99 queue wait runs about 3× the transfer time at 50% utilisation, 7× at 70%, and past 20× at 90%. At that knee there are exactly two remedies, permanent headroom or a change in the amount of lit capacity, and a hyperscaler overprovisioning its backbone three to five times buys the first at hyperscaler capital intensity while everyone else needs the second, triggered before the knee. There is a second, physical reason the optical layer matters, and it is the one I would ask every network architect to sit with. The transport the AI stack actually prefers is RDMA, and RoCEv2 was designed for lossless fabrics with microsecond feedback loops. At the loss rate of an ordinary shared WAN — one packet in a hundred thousand — a 400G RoCEv2 flow at 56 ms round-trip collapses to about 24% goodput; the pipe stays busy, mostly re-sending. Holding 90% goodput needs paths one to two orders of magnitude cleaner than a shared WAN, with no delay variation that reorders packets. A loss and jitter floor is therefore a bandwidth specification, not a quality garnish — and deterministic delivery at that level exists at layer 1, on dedicated wavelengths, in a way no queueing discipline provides at layer 3 under load. Put those together and the design that falls out is a two-timescale system: a packet-fronted service interface making per-request decisions in milliseconds, optical elasticity underneath changing lit capacity in seconds to minutes, triggered at the queueing knee, with tails engineered at layer 1. Our published India simulation gives a sense of the stakes: a 70B model at 4K context over 1,000 km moves from 9.75 s time-to-first-token and 12% GPU utilisation on a shared 10G link to 1.38 s and 84% at 400G. What Lightstorm is doing about it I will keep this section deliberately short, for reasons anyone in a competitive market will understand. The analysis makes falsifiable predictions, and predictions are worth nothing until someone measures them on production infrastructure. Lightstorm is building the network half of that measurement. We are assembling a three-site testbed on a new, deep-buried production fibre corridor in India, with open optical line systems from multiple vendors under interoperability test and an SDN-driven optical control plane on top. Polarin, our network-as-a-service platform, is being extended in the direction the paper describes: a control loop in which the inference layer asks for capacity and the optical layer supplies it, on the timescale of provisioning rather than of a request. Around that testbed we have published a ten-metric measurement plan — provisioning and capacity-step latency, delay-variation percentiles, allocation-loop timing, multi-tenant isolation, the real transfer-versus-recompute flip point, compression-quality curves, and measured cost per gigabit at pilot scale — with each metric tied to a specific prediction in the paper, so each one can prove us wrong. The pilot window opens in late 2026 and it is open to collaborators, and that is not a courtesy line. An operator can measure what only an operator can measure, but the workload truth — real time-to-first-token, real utilisation, an RDMA-class transport running over actual wavelengths — has to come from the GPU vendors, serving-stack and inference-fabric providers who own those layers. No single company can, or should, assemble this evidence alone. Where I land The workloads now arriving — agentic, multi-site, sovereignty-split — are the first that cannot route around the wide-area tier. My guess is that the evidence shows up first in Asia, and specifically in India, where the GPU fleets are hot, the distances between compute and demand are real, and new fibre is going into the ground that can be designed for this traffic rather than retrofitted to it. One thing I have not resolved in my own head is where the storage tier fits. Checkpointing state to NVMe and reloading it on demand sits somewhere between transfer and recompute, and we have not modelled it yet — the kind of contribution the open plan is meant to absorb. Two decades ago, Metro Ethernet’s requirements told the market: here is the missing tier, here is how to specify it, here is the evidence. That is what this work is for. The full analysis, reproducible model and measurement plan: arXiv:2608.14967 — “When Does Distributed AI Inference Need More Wide-Area Bandwidth? A Co-Design Evaluation of Optical, Packet, and Software Levers” (Prasanna C, Lightstorm, August 2026). To discuss participation in the late-2026 pilot window, contact Lightstorm.

22 September 2026

Read more
The Network Behind AI
Blogs

The Network Behind AI

When people talk about AI, the conversation usually revolves around models, GPUs and data centres. Which model performs best? How much compute does it need? Which cloud platform offers the right environment to train and deploy it? These are important questions, but they focus on the most visible parts of AI while leaving the infrastructure that quietly makes it all possible in the background. Every AI model depends on data moving continuously between data centers, cloud platforms, storage systems and users. Every training run, inference request and real-time AI application relies on a network that can move enormous volumes of data reliably and predictably. As AI workloads become larger and more distributed, that network is no longer simply transporting information. Increasingly, it is determining how effectively AI itself performs. For years, enterprise networks were built for applications with relatively predictable behaviour. If something went wrong, the network raised an alarm, engineers investigated the issue and service was restored. It was not instantaneous, but for most workloads, it was good enough. AI changes that equation. When a distributed training workload slows down because data cannot move efficiently between GPU clusters, or when an inference service experiences latency because the underlying network is struggling to adapt, the impact is not measured only in downtime. It shows up as lost productivity, delayed insights and expensive compute sitting idle. In that sense, the network has quietly become part of the AI product. That shift is becoming increasingly evident in our conversations at Lightstorm. Enterprises, cloud providers and AI-driven businesses are no longer asking only about bandwidth or uptime. They are asking whether their networks can keep pace with workloads that are dynamic, distributed and constantly evolving. They want infrastructure that does not simply recover when something goes wrong, but helps prevent disruption in the first place. That is a very different conversation from the one the industry was having just a few years ago. It raises an important question: can networks built for yesterday's operating model support tomorrow's AI economy? AI Is Changing the Rules for Networks Every major technology shift has redefined what businesses expect from infrastructure. The internet made connectivity essential. Cloud computing made scalability non-negotiable. Streaming transformed latency from a technical metric into a customer experience issue. Now AI is raising the bar once again. Unlike traditional enterprise applications, AI workloads rarely exist in one place. Training data moves across regions. Models interact with multiple data centres. Inference happens close to users, while orchestration may happen somewhere else entirely. The network is no longer connecting a handful of applications; it is coordinating an ecosystem of constantly moving intelligence. That changes the role of connectivity itself. For decades, organisations have viewed networks as infrastructure that carries business applications. In the AI era, networks increasingly become participants in those applications. Their ability to adapt, recover and optimise in real time directly influences how AI systems perform. This is why conversations around AI infrastructure can no longer stop at compute. Compute determines how much intelligence an organisation can create; the network determines how effectively that intelligence can move, collaborate and deliver value. This marks one of the biggest shifts the networking industry has seen in decades. AI is not simply increasing demand for faster connectivity; it is changing what customers expect connectivity to do. Reliability is no longer enough. Networks must become more aware of their own health, more responsive to changing conditions and more capable of protecting customer experience without waiting for manual intervention. In many ways, AI is asking networks to evolve from passive infrastructure into active participants. That is where traditional operating models begin to show their limits. Why Traditional Network Operations Are Reaching Their Limits The challenge facing modern networks is not that they have become unreliable. In many ways, they have never been more capable. Today's transport and IP networks generate an extraordinary amount of information about their own health. They can report changes in optical performance, monitor traffic flows, detect routing anomalies and identify early signs of degradation long before a customer notices anything is wrong. The irony is that, despite all this intelligence, most networks still rely on a decades-old operating model. When an issue occurs, the network raises an alarm. Engineers investigate the incident, correlate information from different systems, determine the likely cause and decide on the safest response. It is a disciplined process that has served the industry well for years, but AI has changed the pace of the game. Unlike traditional enterprise applications, AI workloads do not simply consume bandwidth. They depend on constant, predictable movement of data across distributed infrastructure. A brief interruption may delay thousands of GPUs working together on a training run. A momentary change in latency can affect real-time inference. What was once a minor operational event can quickly become a business event. The network is not becoming harder to manage because engineers are less capable. It is becoming harder to manage because the volume of information now exceeds what even the most experienced operations teams can reasonably interpret in real time. That distinction matters. For years, we have invested in making networks smarter by deploying better monitoring tools, richer analytics and more sophisticated management platforms. Yet the final decision in the operational chain has often remained the same: wait for a human to understand what is happening before the network responds. In the AI era, waiting is increasingly becoming the bottleneck. That does not diminish the role of engineers. In fact, it elevates it. The real opportunity is not to replace human expertise, but to stop asking humans to perform tasks that machines are now better equipped to handle. Detecting patterns across millions of telemetry signals, correlating events happening simultaneously across multiple layers of the network and identifying emerging risks in seconds are problems AI is uniquely suited to solve. Human judgment remains indispensable, but it should not be spent chasing every alarm. It should be spent designing resilient networks, defining policies, managing exceptions and making strategic decisions that technology alone cannot. From Reactive Networks to Autonomous Networks For decades, the networking industry has measured success by one simple metric: how quickly can we recover when something goes wrong? It's a sensible goal, but it's built on an assumption that no longer holds true—that disruption is inevitable, and the best we can do is respond faster. AI challenges that assumption by asking a fundamentally different question: why should the customer experience the disruption in the first place? That's the shift autonomous networks represent. They aren't simply faster at reacting; they're designed to anticipate. Rather than waiting for an engineer to investigate an alarm, an autonomous network continuously observes its own behaviour, recognises patterns that suggest something is beginning to drift, understands which services could be affected and evaluates the safest course of action before a minor issue becomes a customer-facing incident. Depending on the situation, that response may be as simple as notifying an engineer, rerouting traffic around a degrading path or restoring service automatically because the action has already been tested, approved and validated. The objective isn't to remove people from network operations—it's to remove unnecessary waiting. That distinction becomes increasingly important as AI workloads grow larger and more distributed. Even small delays in operational decision-making can have consequences far beyond the network itself. A few seconds of hesitation may translate into idle GPUs, interrupted inference services or degraded customer experiences. In those environments, operational excellence is no longer measured only by how quickly engineers respond after something goes wrong. It is measured by how quickly the network can recognise a developing issue and make a safe, informed decision before customers feel the impact. Far from making engineers less important, autonomous operations elevate their role. Instead of spending valuable time investigating routine events, engineers define policies, establish operational guardrails, validate automated actions and focus on the situations where human judgement genuinely adds value. That's a fundamentally different way of thinking about network operations—and one that better reflects the pace and complexity of the AI era. The Network That Decides Before It Disrupts At Lightstorm, we see this as more than another automation initiative. We see it as the next evolution of network operations. For years, automation has helped operators execute repetitive tasks more efficiently, but efficiency alone is no longer enough. AI workloads are inherently dynamic. Traffic patterns shift unexpectedly, infrastructure spans multiple clouds and data centres, and demand changes far more quickly than traditional operational processes were designed to handle. Responding effectively in that environment requires more than scripts and workflows; it requires systems that can understand context, interpret what they are seeing and act intelligently within clearly defined boundaries. This is where technologies such as streaming telemetry and AI-driven analytics become foundational. Instead of relying on periodic snapshots of network health, autonomous operations are built on continuous visibility. The network is constantly observing itself, allowing emerging issues to be identified earlier, responses to be evaluated with greater confidence and customer impact to be reduced before it becomes visible. The result isn't simply a more automated network—it's a network capable of making better operational decisions because it has a richer and more timely understanding of its own condition. Ultimately, autonomy isn't about building a network that operates without people. It's about building one that doesn't need to pause before protecting its customers. In the AI era, the most valuable network won't necessarily be the one with the fastest links or the greatest capacity. It will be the one capable of making the right decision at exactly the right moment—quietly, safely and often before anyone even realises there was a problem to solve.

21 July 2026

Dawn Of An AI Era
Blogs

Dawn Of An AI Era

"The best way to predict the future is to invent it." Alan Kay's famous observation has guided generations of technologists. Yet history suggests something equally profound: inventing the future is only half the challenge. The other half is building the infrastructure that allows it to scale. We rarely recognize transformational moments while we're living through them. The Industrial Revolution did not begin with a declaration, nor did the internet arrive with universal consensus that it would redefine commerce, communication and society. Their significance became obvious only in hindsight, once the supporting infrastructure had quietly reshaped the world around them. Artificial Intelligence feels remarkably similar. What began as a research discipline has, in just a few years, become one of the defining technologies of our time. AI is no longer confined to laboratories or experimental projects; it is writing software, accelerating scientific discovery, assisting doctors, reshaping customer experiences and changing how businesses make decisions. Every week seems to bring another breakthrough, another model or another capability that pushes the boundaries of what machines can accomplish. What makes this moment different is not just AI's capability, but its pace. Previous technological revolutions unfolded over decades, giving societies, industries and institutions time to adapt. AI is compressing those timelines into months. Capabilities that seemed impossible a year ago are becoming commonplace, forcing organizations to rethink strategies far more frequently than they ever have before. Unsurprisingly, much of the conversation has centered on models, algorithms and compute. They are, after all, the visible face of the AI revolution. But history teaches us that the technologies we remember are rarely the only reason revolutions succeed. The steam engine transformed industry, but without railways it could not have connected markets or enabled large-scale manufacturing. Electricity changed modern civilization, but only because power grids carried it beyond the laboratory. The internet reshaped the global economy, yet it was fibre networks, subsea cables, data centers and cloud infrastructure that allowed billions of people to experience it simultaneously. Every technological revolution has ultimately become an infrastructure revolution. AI will be no different. At Lightstorm, we see this shift unfolding every day. Conversations that once centered on bandwidth or cloud connectivity are increasingly centered on AI readiness, data gravity and how enterprises can move intelligence securely across distributed environments. The questions may have changed, but the underlying lesson has not: every leap in technology ultimately depends on the infrastructure that supports it. The Beast Has Been Built It is tempting to think of today's AI systems as simply another generation of software. They are not. Large language models and foundation models represent a fundamental shift in how machines interact with information. Rather than following explicitly programmed instructions, they generate responses, reason through problems, synthesize knowledge and increasingly perform tasks that once relied exclusively on human expertise. More remarkable still is the speed at which these capabilities continue to evolve. Only a few years ago, AI-generated content was largely viewed as an interesting novelty. Today, enterprises are using AI to assist with software development, customer engagement, operational planning, cybersecurity and scientific research. The conversation has rapidly shifted from "Can AI do this?" to "How do we responsibly integrate AI into everything we do?" This is more than the arrival of another digital tool. AI represents a new layer of intelligence that will increasingly sit across every application, every workflow and every industry. Much like electricity before it, AI is unlikely to remain a standalone technology. Instead, it will become an enabling capability embedded so deeply into business processes that organizations will eventually stop referring to "AI projects" altogether. AI will simply become part of how work gets done. That shift carries implications that extend far beyond the models themselves. Every interaction with an AI system involves enormous volumes of data moving between users, applications, cloud platforms and increasingly distributed computing environments. Every AI-powered recommendation depends on information flowing securely, reliably and at extraordinary speed between multiple systems. Intelligence, in other words, does not exist in isolation. It depends on connection. And as AI adoption accelerates, that dependence will only grow stronger. Beyond Compute Much of the conversation around AI has understandably centered on compute. Graphics Processing Units (GPUs), specialized accelerators and hyperscale data centers have become synonymous with the AI revolution, and for good reason. Without compute, there is no model to train and no intelligence to deploy. Yet focusing exclusively on compute risks overlooking another reality: AI is fundamentally a data movement problem. Training foundation models requires enormous datasets drawn from multiple sources. Enterprise AI applications continuously exchange information between cloud environments, private infrastructure and users spread across regions. As inference increasingly moves closer to where decisions need to be made, organizations are also witnessing a dramatic increase in east-west traffic between data centers, rather than simply north-south traffic between users and applications. In other words, AI is not confined to a single location. It is inherently distributed. Data, models and applications are constantly moving across cloud platforms, enterprise environments and edge locations, creating digital ecosystems that are significantly more dynamic than those built for previous generations of enterprise software. This shift is particularly evident in conversations with enterprises embarking on AI initiatives. While the discussion often begins with models, GPUs and applications, it quickly turns to practical questions around data movement, latency, cloud interconnection and resilience. Organizations are discovering that AI readiness is as much an infrastructure challenge as it is a technology challenge. As AI becomes embedded within day-to-day operations, organizations will discover that moving intelligence efficiently is becoming just as important as creating it. This is where the conversation naturally shifts beyond models and GPUs towards something less visible, but equally consequential: the infrastructure that connects them. Every AI Conversation Eventually Becomes an Infrastructure Conversation The first wave of enterprise AI has largely focused on applications. Boards are discussing AI copilots, CIOs are evaluating foundation models, and business leaders are exploring use cases across software development, customer service, cybersecurity and analytics. Those conversations are necessary, but they inevitably lead to a more fundamental question: can the underlying infrastructure keep pace? At Lightstorm, we've observed that this is increasingly where AI strategies succeed or stall. The organizations making the fastest progress are not necessarily those experimenting with the most models, but those building networks capable of connecting data, compute and cloud environments without introducing complexity or bottlenecks. That question reflects a broader shift in how networks are expected to operate. For years, enterprise connectivity was designed around relatively predictable traffic patterns. Employees accessed applications hosted in corporate data centers, branch offices connected back to headquarters, and even the transition to cloud largely followed well-understood communication paths. AI is rewriting those assumptions. Today's AI workloads are dynamic, distributed and continuously exchanging information between multiple environments. As a result, the network is no longer simply responsible for transporting data; it is becoming an active participant in how intelligence is created, distributed and consumed. The implications extend well beyond bandwidth. Latency influences the responsiveness of AI applications. Network resilience determines whether mission-critical services remain continuously available. End-to-end visibility becomes essential as organizations seek to understand how data, applications and models interact across increasingly complex environments. Above all, agility becomes a competitive advantage. AI is evolving at a pace that few organizations have experienced before, and infrastructure must evolve just as quickly if it is to support that change rather than constrain it. History offers an interesting parallel. The internet did not become transformative simply because websites existed. It became transformative because reliable, high-capacity connectivity made those services universally accessible. AI is following a remarkably similar trajectory. While breakthroughs in models and applications may capture the headlines, long-term value will ultimately be determined by the infrastructure that allows those breakthroughs to scale across enterprises, industries and economies. For network providers, this represents a fundamental shift in responsibility. Networks are no longer expected to simply connect locations; they are increasingly expected to interconnect intelligence itself—linking clouds, data centers, enterprise environments and AI workloads into a resilient digital fabric capable of supporting the next generation of applications. Sooner or later, every AI conversation becomes an infrastructure conversation. Building the Foundations of the AI Era The AI race is often framed as a competition to build the most capable model or develop the next breakthrough application. While those innovations will undoubtedly shape the future, they represent only one part of a much larger story. Every AI application, regardless of where it runs or what it does, depends on an ecosystem that can move data securely, reliably and at scale. Governments investing in sovereign AI are simultaneously investing in digital infrastructure. Enterprises deploying AI are rethinking how data moves between cloud environments, how workloads are distributed across data centers, and how intelligence can be delivered closer to where decisions need to be made. The common thread across these initiatives is not simply AI—it is the infrastructure that enables AI to function. For enterprises, this represents a significant shift in priorities. The competitive advantage created by AI will not come from experimentation alone, but from the ability to operationalize intelligence across the organization. That requires more than access to powerful models. It requires a digital foundation capable of connecting applications, data and compute seamlessly across increasingly distributed environments. Organizations that continue to view connectivity as operational overhead may find it becoming a bottleneck. Those that recognize it as strategic infrastructure will be better positioned to adapt as AI continues to evolve. This shift is already changing expectations of the network itself. Connectivity is no longer measured solely by bandwidth or uptime. Increasingly, it will be judged by its ability to support low-latency AI inference, enable high-volume data movement, connect distributed cloud environments and provide the resilience required for business-critical AI applications. At Lightstorm, we believe this marks the next evolution of digital infrastructure. Networks are no longer expected to simply move traffic between locations. They are increasingly expected to interconnect intelligence—connecting AI workloads, cloud platforms, data centers and enterprise applications into a resilient digital fabric that enables innovation at scale. History suggests that this is neither surprising nor unique. Every major technological leap has depended on an enabling layer that quietly made progress possible. Railways unlocked the Industrial Revolution. Power grids enabled electrification. Fiber networks transformed the internet from a niche technology into a global platform for innovation and commerce. The AI era will follow the same pattern. The breakthroughs will capture headlines. New models will continue to redefine what machines can achieve. Yet the long-term impact of AI will ultimately depend on something far less visible: the infrastructure that connects data, compute and people with the speed, resilience and trust that modern digital ecosystems demand. That is perhaps the most important lesson history offers. We often remember revolutions for the technologies that inspired them. We rarely remember the infrastructure that made them possible. Yet without that foundation, no revolution has ever truly scaled. At Lightstorm, this belief shapes how we think about the future. Building AI-ready infrastructure is not simply about delivering more bandwidth or connecting more locations. It is about creating networks that can adapt to the changing demands of AI, enabling enterprises to move data securely, scale intelligently and innovate without constraint. As the AI era unfolds, we believe the organizations that invest in this foundation today will be the ones best positioned to define what comes next.

15 July 2026

From Insight to Action: Driving Customer Loyalty in Telecom
Blogs

From Insight to Action: Driving Customer Loyalty in Telecom

Listening to customers forms the bedrock of a meaningful Customer Experience (CX) strategy. But collecting and interpreting feedback is just one battle won. The real test begins after that: turning insights into action. In industries built on reliability, responsiveness, and trust—especially those powering enterprise connectivity and digital infrastructure—customers do not only remember what was promised. They remember how consistently it was delivered, how quickly issues were resolved, and how confidently they could scale with their provider. Because understanding the customer is only half the journey; changing the system to serve them better is the harder half. As business expectations shift toward more flexible, service-led models, customer experience is increasingly shaped not just by support interactions, but by how seamlessly a provider enables agility, visibility, and performance across the relationship. That is what makes the second battle so important: not just listening well but evolving fast enough to stay relevant. Understanding the Difference: Customer Service vs Customer Experience One of the biggest challenges CX leaders face is that Customer Experience is still frequently misunderstood. Customer Service is often seen as the entirety of customer engagement. It is actually only one touchpoint within the larger customer journey. It is reactive and transactional—what happens when a customer needs support, has a question, or faces a problem. CX, on the other hand, is the entire relationship a customer has with a brand—every interaction, perception, emotion, and expectation from discovery to delivery and beyond. It is strategic, proactive, and deeply connected to retention, trust, advocacy, and growth. A simple way to think about it: Customer Service is what happens when help is needed. Customer Experience is everything that happens, always. The Silent Battle Within Every CX leader knows that when the moment the “listening” phase ends, a tougher challenge begins—the internal battle. The battle to influence teams, challenge systems that may no longer serve customers effectively, and drive accountability across departments not directly measured by customer experience metrics. And “outdated systems” doesn’t always mean something old or broken. Sometimes, it’s a process that once worked brilliantly but has gradually lost relevance as customer expectations evolved. In other cases, competitors may have raised the bar—introducing faster, simpler, or more intuitive experiences that redefine what customers now consider normal. This shift is especially visible in telecom, where legacy operators have historically struggled on customer experience. According to an STL Partners report, telecom’s average Net Promoter Score sits at 31, making it one of the weakest-performing sectors on customer satisfaction, while early NaaS (Network-As-A-Service) adopters in the report averaged 74. What was acceptable five years ago may feel frustrating today. CX leaders often find themselves in a unique position: sitting at the intersection of every function, advocating for the customer while balancing organizational realities like budgets, policies, operational comfort zones, and competing priorities. This is where assertiveness with integrity becomes a CX superpower. Being the voice of the customer isn’t just about representing pain points; it’s about speaking truth to Power —decisively. It’s about standing firm when short-term cost considerations threaten to override long-term customer trust, or when internal silos defend legacy processes that no longer create value. The CX leader often has no direct control over many of these functions—but immense responsibility for the outcomes they collectively deliver. That’s what makes internal advocacy such a complex and often underestimated pursuit. The Art of Assertive Advocacy Assertiveness in CX doesn’t mean confrontation; it means conviction. It’s the ability to translate customer stories into compelling business cases. It’s about connecting empathy with economics—showing how customer-centric actions drive measurable long-term value. Integrity is what sustains that assertiveness. It means choosing transparency over convenience. The best CX leaders therefore learn to balance two commitments simultaneously—the commitment to organizational success and the commitment to customer trust. The role is not about choosing one over the other. It is about ensuring neither is compromised. CX as the Integrator The most powerful CX ecosystems do not exist within a single team—they exist across every function. Every department—from operations to finance to technology—must understand how their decisions ripple outward and shape customer perception. At Lightstorm, A “Customer First” philosophy is deeply embedded in the culture. Leadership places a clear and consistent emphasis on supporting the CX function. The Senior Leadership Team remains closely connected to customer sentiment and operational realities. Leaders are accessible, involved, and only a call away when customer situations require urgency or alignment. Customer sentiment, service experiences, network performance, and even softer experience indicators are reviewed consistently every week—not as isolated operational metrics, but as strategic business signals. And when situations demand deeper collaboration, we go beyond standard escalation structures. Cross-functional war rooms are established to ensure rapid alignment and resolution, keeping the customer firmly at the center of every decision. At Lightstorm, decision-making is not made in isolation from customer voice—it is shaped by it. Most importantly, accountability for customer experience is not delegated away. It is reviewed directly by the CEO to ensure that no nuance, sentiment, or customer reality is lost in translation as information moves through layers of the organization. This level of leadership commitment creates a culture where CX is not treated as a reporting function—it becomes a business philosophy. Perhaps that is why Lightstorm has consistently delivered world-class Net Promoter Scores for three consecutive years. As of this year to date, our NPS stands at 90—a reflection not just of process excellence, but of leadership intent. Because ultimately, exceptional customer experience does not happen accidentally. It happens when leadership genuinely believes that customers are central to the organization’s existence. The Road Ahead: From Insight to Impact Collecting insights is straightforward. Acting on them requires courage. It means holding up a mirror to the organization and saying, “This may not be comfortable, but it is necessary.” At Lightstorm, our commitment to listening does not end with collecting feedback. It extends into alignment, accountability, and action—the second and more demanding battle of CX. We believe listening earns trust, but acting on what we hear sustains it. It is about building a culture where every voice—customer or internal—is heard, respected, and translated into continuous improvement. Because in the end, CX is not just about the experience customers have with your company—it is also about the experience your teams have while building that experience for others. Win both, and you master the art of Customer Experience transformation. The bottom line is that the first battle is won when you listen. The second, when you change. And enduring success comes when listening and changing become inseparable parts of organization’s DNA. Frequently Asked Questions About Customer Experience in Telecom Q) What is Network-as-a-Service (NaaS), and how does it improve customer experience? A) Network-as-a-Service (NaaS) is a flexible, consumption-based networking model that allows businesses to access and manage connectivity services on demand. Compared to traditional network models, NaaS can enable faster service provisioning, greater scalability, improved visibility into network services, and more agile management of changing business requirements. Q) How does Lightstorm’s approach to NaaS support better customer outcomes? A) Lightstorm’s approach to NaaS combines high-performance network infrastructure, operational agility, and customer-focused service delivery. This helps enterprises respond more quickly to changing connectivity requirements, scale digital operations efficiently, and maintain reliable support for business-critical workloads. Q) Why is customer experience important in network infrastructure and digital connectivity? A) In network infrastructure, customer experience goes far beyond uptime. It includes how quickly issues are resolved, how proactively providers communicate, how easily services can be scaled or modified, and how effectively a provider supports critical business operations over time. Q) What helps organizations turn customer feedback into meaningful change? Turning customer feedback into meaningful change requires more than collecting insights. It takes leadership commitment, cross-functional accountability, and the willingness to challenge processes, systems, and habits that no longer serve the customer effectively.

1 June 2026