O-RAN PlugFest Spring 2026: Smaller, Sharper, More Ambitious

The O-RAN ALLIANCE published results from its Global PlugFest Spring 2026 on June 4. Conducted from February to May 2026, it brought together 31 companies and institutions across 9 labs worldwide, co-hosted by 13 operators, OTICs and independent institutions. Those numbers will look like a step backward to anyone tracking PlugFest participation over time — and they are, deliberately.

For comparison: the Fall 2024 PlugFest ran across 28 labs with 115 participants. Spring 2025 had 19 labs and 69 participants. Spring 2026 cut the footprint by more than half again. This is not a loss of momentum. It is a deliberate shift from ecosystem-building to integration hardening. Getting everyone in the tent was the objective of the first five years. Making what exists actually work together is the objective now.

Massive MIMO — finally the main act

The centrepiece of Spring 2026 was multi-vendor end-to-end integration of massive MIMO O-RAN components, including mMIMO beamforming. This matters more than it might appear. Massive MIMO has always been the credibility gap for Open RAN. Traditional vendors have proprietary beamforming pipelines refined over a decade of commercial deployment. High-band, high-capacity urban coverage — stadiums, CBDs, transport hubs — has been essentially off-limits for disaggregated RAN. Demonstrating that multi-vendor mMIMO beamforming can be integrated in a structured, neutral lab environment is the first necessary step toward closing that gap.

AmpliTech's O-RAN CAT-B 64T64R Massive MIMO radio was the only radio of that configuration at the event — the only American-designed and commercialized O-RU at that specification level — and it demonstrated multi-vendor interoperability alongside operators including AT&T, Deutsche Telekom, Korea Telecom, LG Uplus, Orange and Rakuten Mobile. That combination — 64 transmit, 64 receive antennas, multi-vendor integration, neutral lab, named Tier-1 operator validation — is the kind of result that shifts a proof of concept into a procurement conversation.

Commercial-grade performance parity with incumbent vendors is a separate question, and a longer road. But you cannot get there without first doing what was done here.

AI-RAN — directionally consistent, details deferred

Several labs focused on AI-RAN solutions targeting network performance improvements and energy savings. The press release did not publish quantified results — a contrast with Spring 2025, which reported 25–30% intelligent RAN energy savings delivered by rApps on Non-Real-Time RICs. Detailed results will follow in technical session readouts. The direction is not in question. AI-driven energy efficiency via the RIC architecture has been the dominant AI-RAN use case in structured testing for two years running, and the logic is clear: energy is the largest controllable operating cost in RAN, the levers are cell on/off switching and power scaling, and the RIC is the right control point. What the Alliance needs to demonstrate next is that these savings hold at scale, under real traffic conditions, not just in lab scenarios with predictable load profiles.

The open-source stack is growing up

Four open-source frameworks were deployed at the PlugFest: Open Air Interface, OCUDU, O-RAN SC, and Sylva. Each represents a different layer of the stack, and their simultaneous presence in integration testing is worth noting.

OAI has become the de facto open-source O-CU/O-DU choice in lab settings — widely trusted, well-documented, increasingly operator-deployed in production pilots. O-RAN SC provides the RIC and SMO components from the Alliance's own software community. OCUDU is a combined CU/DU implementation targeting simplified deployment at the edge. And Sylva — the Linux Foundation's cloud-native telco infrastructure framework — is where the container orchestration and lifecycle management work happens. Carrier-grade Kubernetes for RAN workloads, in plain language.

The intersection of Sylva and O-RAN SC is the one to watch. Cloud infrastructure meeting RAN software — not as a research experiment, but as a jointly validated integration — is where operator confidence in virtualized open RAN will be won or lost operationally. It is still early. But it is no longer theoretical.

ISAC — a 6G signal in a 5G event

Initial tests were performed on Integrated Sensing and Communication, or ISAC — using the RAN simultaneously for wireless communications and environmental sensing. Object detection, positioning, radar-like environmental awareness, all from the same radio infrastructure. This is a 6G-era capability appearing in 5G Advanced specifications, and its inclusion in a 2026 PlugFest is a deliberate statement by the Alliance. They are not waiting for a new standards cycle to begin building the interoperability baseline. Given how long it took Open RAN to move from specification to commercial deployment, starting ISAC integration work in 2026 is not premature. It is probably necessary.

Who was there, and who wasn't

The full participant list is a useful read. Operators present included Korea Telecom, LG Uplus, Orange and Rakuten Mobile, with AT&T represented at the governance level through Brian Daly's TSC co-chairmanship. Academic institutions — Virginia Tech's Commonwealth Cyber Initiative, Iowa State University, North Carolina State University, ETRI and Fraunhofer HHI via the i14y Lab — signal that the research-to-commercialisation pipeline is being built at the institutional level, not just the vendor level. Software Radio Systems, the team behind srsRAN, continues to appear — their open-source 5G stack is quietly becoming a reference DU/CU implementation in operator testbeds.

What is absent is equally notable. No traditional vendors. The large incumbents engage with the Alliance at the specification level; they do not typically show up at PlugFest lab level. This is not surprising, but it is a structural tension. The integration maturity of disaggregated RAN will ultimately be measured in Tier-1 operator deployments, and those operators currently run incumbent infrastructure. The path from PlugFest to procurement runs through a comparison the incumbents are not participating in on neutral terms.

What this PlugFest actually means

The O-RAN Alliance has always faced a version of the same challenge: translating credible lab results into commercial deployments at scale. PlugFests prove interoperability in controlled conditions. Operators need it in live networks, under real traffic, with real SLAs and real interference environments. That gap has not closed. But the Spring 2026 agenda — massive MIMO beamforming, AI-RAN energy efficiency, integrated open-source stacks, ISAC first tests — reflects an ecosystem that knows precisely where it needs to focus to close it. That is not a small thing. Three years ago, the conversation was still largely about whether disaggregated RAN could work at all. That question has been answered. The question now is how fast it can reach performance and cost parity with incumbent solutions in high-capacity, high-stakes deployments. Spring 2026 moved that needle. Not dramatically. But in the right direction, on the right problems.

Innovating and Monetizing in Telecom: The Lean Telco

 

As alluded to in my previous posts, I have integrated the Lean Startup methodology, the design thinking framework and the Wardley Map model to create value in a telco environment.

Value is a subjective topic but in a Telco context, my efforts have been aimed at creating sustainable growth strategies. Very simply, sustainable growth comes from sustainable differentiation, which stems from the creation and evolution of technological, commercial and operational characteristics that become difficult, expensive and time consuming to emulate from your competition.

Sustainable growth comes from sustainable cost reduction and revenue growth (Duh!).

Sustainable cost reduction can be achieved through drastic cost structure changes. In 2026 Telco, it can be attained through the implementation of a cloud native architecture and principles, underpinned by strategies of network disaggregation, extensive use of open APIs and open network topologies; control / user plane separation and systematic automation. While these goals are challenging by themselves, particularly in a brownfield legacy telco environment, they are the bare necessary changes for survival. The challenges associated with the organization, skill sets and methodologies to evaluate, test, deploy, purchase and maintain these technologies are even larger.

Every telco is extremely skilled at managing technological and operational risk, through iterative, waterfall evaluation and tests, resulting in deployment of high availability and capacity networks. This methodology has also led to lengthy evaluation periods and deployments. Most vendor will recognize that the sales cycles in telco are over 2 years long and that making any change in a commercial network takes several million of dollars or euros. This has led to an oligopoly where only a handful of specialized vendors are able to sustain economically these drastic processes.

Lately, telcos have been trying to diversify the pool of vendors to increase competition and innovation by promoting open source and open API projects such as open RAN.

While these projects have shown interesting progress, the real cost reduction comes from the change in methodology and processes to take advantage of these more nimble vendors offering.

What I am proposing with Lean Telco is a methodological framework for identifying, evaluating, testing, sourcing, deploying telco products and services that will provide sustainable differentiation with drastically different cost structure than the incumbent versions.

Once you have successfully changed the cost structure of evaluating, buying, deploying and managing telco infrastructure and capacity, you can survive as a high capacity, low overhead provider of connectivity. But if you want to strive and grow, you need to attack the revenue part of the equation. Actually, one would argue should start with growth objectives, and look at cost structure as an optimization challenge.

Growing revenue sustainably, in a telco environment comes from either having more people using your existing services, or using more of them, connect new people or create new services. I have prototyped, tested and launched projects in each of these categories in my role at Telefonica.

1. Having more people use your existing products is difficult for telcos, because those products (residential and enterprise mobility, internet, telephony, TV...) are poorly differentiated, since they rely on the same technology from the same vendors. As a result most telcos end up trying to deploy first (5G, SDWAN...) or to claim a performance advantage, usually derived from a superior spectrum or infrastructure investment. The only real differentiation ends up being pricing. This is very expensive and not sustainable.
2. Having your customers using more of your service does not necessarily lead to more revenue, as bundles and unlimited plans are periodically rolled out to counter internet hyperscalers offering who rely on a different cost structure and revenue model. Again, since these services are mostly the same from one operator to another, differentiation comes from bundling and pricing. This is not sustainable.
3. Connecting new people / clients is a worthy endeavour, but the last unconnected live mostly in rural, low density areas and selling services to new corporate clients usually mean competing against public cloud offering that are more cost effective and flexible than what most telcos can offer. There are possibility of growth there, but it requires breaking out from the current telco technological framework and a willingness to assemble new value chains.
4. Creating new services is certainly where there is the most value, if we look at the growth of telephony over internet, video streaming services, social media and social messaging, SDWAN, cloud security, SASE, AIaaS... it is also the area with the most uncertainty and risk.

Telcos are not well equipped to manage the risk and uncertainty inherent in the discovery and creation of new services. The methodologies, organization and processes they use is to deliver with absolute certainty a product or utility with zero default to a mass market without variation. This model works well for mature, disciplined technology and vendors, not at all for exploration and innovation.

Too often, some Telcos build an extremely detailed plan, with contingencies. They budget it, staff it, resource it to execute it within a given timeframe, only to discover that the client didn't really want / need / value what was proposed (cf. push to talk, IMS/VoLTE, RCS, private networks...).

Just like in Lean Startup, the methodology I propose allows the progressive liberation of resource and funds as commercial uncertainty is shed by direct client interaction, testing and feedback. In a typical telco environment, the client interaction is at the very end of the process, here we are going to intersperse it throughout the development process to allow pivots, or early termination if the hypothesis are not met.

Trained, mentored and helped by many, I have adapted a few methodologies to enable Telcos to identify, validate, and deploy new services in an agile and cost effective fashion. I call it the Lean Telco Methodology.

How do I create a Lean Telco?

I use Wadley Maps for situational awareness and create a topographical representation of the current environment, which in my area of interest range from AI (sovereign, factories, grid, agentic, physical...), telco network cloud, orchestration, cloud native distribution and orchestration (K8, micro services) and hybrid cloud / edge computing (telco private stacks, AWS outpost, MS Azure, AI grid...). This is not a map until we apply the level of maturity (Genesis / handmade, Custom / solution, Product, Utility) to each of them, as well as their direction and barriers on the horizontal axis. On the vertical axis, instead of using Wardley's traditional visibility method, I use technology stacks such as access, transport, core network, OSS /BSS, orchestration... The purpose of the map is not to be precise or even right, it is to share and compare understanding of the environment, the players, their direction, velocity and the barriers. This visualization enables a level of shared understanding necessary to strategic discussions and gameplay around permutations and what-if? scenarios.

Once identified priorities and areas of risks / opportunities to investigate, I use the Lean UX framework and Lean Startup methodology to systematically identify potential current problems needing solving, unmet customer needs, unsatisfactory experiences and potential new products / services that customer wouldn't even know or have an opinion about. A series of workshop is usually best to crystalize the ideas. Once identified, they need to be refined into customer centric objectives. Design thinking frameworks help, but contrary to popular belief, customer centricity is not necessarily going to ask prospective customers about what they think. Most wouldn't have any idea about what to do with 6G, physical AI or a token exchange if you asked them. This is where lean UX and empathetic composite models are useful.

Each idea is reviewed by a jury and graded, the jury defines which ideas can make it to the next stage. The ideas are shaped and staffed as independent projects, with dedicated resource, budget and time box. Each project lead has the overall responsibility for moving the project to the next phase and to deliver the results of the current phase to justify additional resource and budget for the next one.

At a high level, the phases are:

• Ideation - ($5k-10k /1 - 3 months) -the idea is shaped into a project, with central opportunities, areas of innovation, right to play for the company, sustainable differentiating factor, commercial high level opportunity and cost / timing for the next phase.
• Prototyping - ($20k - 50k / 2 - 6 months) - In this phase a prototype is built, that might or might not incorporate any development or use of technology for the target invention. The idea is just to emulate the resolution of the problem and put it into customers hands as early as possible to identify whether the objectives, assumptions are framed properly and whether the client would value the resolution.
• Beta - ($300k - $600k / 3 - 6 months) -  once the central problems are identified, and we know the client values their resolution, it is time to create a MVP to prove that it is technically, commercially, organizationally possible to solve that problem and that the value created exceeds the costs.
• Product - ($1m - $3m / 3 - 6 months) - In this phase, once proven that the solution is possible, it is necessary to prove that the solution will scale and will be deployable with a mature operational and commercial model.
• Growth - (TBD) This is the phase where the project needs to be commercially and economically sustainable.

Each phase require client interactions, in the form of actual tests in conditions as close as possible to commercial network. Within each phase, we decompose the project into customer centric objectives. Each objective into hypothesis. Each hypothesis into series of experiments that will validate or invalidate the hypothesis. It helps to set clear expectations and success criteria for each of these.Wardley maps helps again, within each phase understanding what tasks, experiments are more suited for pioneers, settlers or town planners and indeed whether the project lead can adopt this mental posture in this phase or whether someone else needs to take the lead.

The result is a portfolio of new revenue making projects, that are systematically validated by customer feedback, capacity and propensity to pay; together with a robust operational and commercial model. Each project is periodically reviewed and graded, all projects must pass a gate review before the next phase and liberation of funds, which allow a nimble, measured, progressive investment plan, as risks and uncertainty decrease throughout the life of the project.

Non-RT RIC, AI-RAN, and the AI Grid: Three Different Bets on the Future of the RAN

I have been asked a few times lately what the difference is between the Non-Real Time RIC and AI-RAN. The question itself tells you something. Both sit under the broad "AI in the RAN" umbrella, marketed aggressively by the same vendors, debated in the same conference sessions. But they are fundamentally different in architecture, ambition, and business model. And neither is quite the same as what NVIDIA formally branded the AI Grid at GTC 2026 — which is where the most important and most misread opportunity actually sits.

The Non-RT RIC: the pragmatic bet

The Non-RT RIC is an O-RAN defined software layer that sits in the Service Management and Orchestration layer above the RAN, not inside it. Control loops over one second. rApps for energy saving, traffic steering, slice assurance, automated optimization. Think of it as the evolution of Self-Organizing Networks, re-platformed on open interfaces with a proper application model and a genuinely lower barrier to entry — cloud-native and OSS skills are sufficient. No RAN silicon expertise required.

This is precisely why the early commercial traction is here, not in AI-RAN. AT&T is deploying Ericsson's SMO and Non-RT RIC to replace two legacy C-SON systems. TELUS has launched an RIC platform alongside its Open RAN rollout. Swisscom is deploying one for multi-technology network management. These are not trials. These are production decisions.

AI-RAN: real performance gains, speculative revenue

AI-RAN embeds AI natively into the RAN stack itself .The AI-RAN Alliance — founded in February 2024, now at 109 member companies — defines it across three working groups: AI-for-RAN, AI-and-RAN, and AI-on-RAN.

AI-for-RAN is the most mature: using AI to optimize the RAN itself — the scheduler, link adaptation, beamforming, interference management. T-Mobile and Ericsson have been trialing an AI-driven scheduler and link adaptation engine on a live 5G Advanced network since Q2 2025, targeting commercial deployment in Q3 2026. Nokia and NVIDIA, backed by a $1 billion equity partnership, are testing GPU-accelerated AI-RAN with BT, Elisa, NTT DOCOMO, and Vodafone.

AI-and-RAN is where the narrative gets more ambitious — and more speculative. The idea is that RAN sites become shared compute infrastructure, running both network workloads and enterprise AI workloads on the same hardware. The tower becomes a distributed AI compute node. New revenue streams. Operators escape the utility trap.

AI-on-RAN is the monetization layer for the above. The commercial mechanisms are still being defined. That tells you where the maturity is.

The AI Grid: follow NVIDIA's sequencing, not its marketing

At GTC 2026, NVIDIA formally introduced the AI Grid as a reference design — geographically distributed AI infrastructure, using the telco footprint to run inference workloads closer to users. The numbers are interesting: early Comcast benchmarks showed inference cost reductions of up to 76% versus centralized deployments. HPE, SpectroCloud, and others have already announced implementations aligned to the reference architecture.

I have used this concept in my own work for years to describe the evolution from isolated MEC deployments into a coherent, programmable distributed inference fabric. Good to see NVIDIA put a formal architecture behind it. But the marketing obscures a critical sequencing question.

NVIDIA's own GTC announcements noted that many operators are starting by lighting up existing wired edge sites — central offices and mobile switching offices — as AI Grids they can monetize today. The cell site layer is a later phase. AT&T's CTO Igal Elbaz has been direct about questioning the value of pushing compute all the way to the far edge to save one or two milliseconds of latency. T-Mobile's SVP of network infrastructure defined her AI edge strategy as what is at a data center at a mobile switching office. Verizon's CTO has flagged the cost and complexity of far-edge GPU deployments.

These are the three largest US operators. They are not being conservative for the sake of it. The economics are straightforward: central offices and mobile switching offices already have power, cooling, connectivity, and physical security. They aggregate traffic from hundreds of cell sites. The sub-500ms latency threshold that NVIDIA's own reference design targets is achievable from a well-positioned CO. It does not require a GPU at the tower — not for the use cases that have a business case today.

I have seen this movie before with MEC. The industry led with its most ambitious architectural vision, ran the infrastructure investment ahead of the demand, and recovered slowly. The AI Grid does not have to repeat that pattern.

What to actually do

Start with the Non-RT RIC. The contracts are being signed, the ecosystem is opening, the business case is defensible.

On AI-RAN, wait for AI-for-RAN where your vendors have credible near-term roadmaps. Treat AI-and-RAN at the cell site as a long term speculative option — worth tracking, too early to fund at scale.

On the AI Grid, follow NVIDIA's own sequencing rather than the brochure. Central offices and mobile switching offices first. Build the orchestration and service layer from there outward. Expand to the far edge when the use cases and economics justify it — not because a GPU manufacturer's demand forecast requires it.

The cell site AI Grid is a compelling long-term vision. The central office AI Grid is deployable today. In this industry, deployable usually wins.

From AI-Native to Agentic-Native Networks

Recent announcements at NVIDIA's GTC 2026—including major pushes into agentic AI frameworks like OpenClaw, NemoClaw, and agentic systems for reasoning, planning, and autonomous action—have reinforced several convictions I've held about the trajectory of AI-native infrastructure, especially in telecom and networked industries. We're seeing the emergence of two distinct paradigms:

• AI-Native networks that observe, detect, optimize, and predict in real time. These systems augment human decision-making, providing powerful assistance in planning, deploying, and managing both physical and virtual infrastructure.
• Agentic-Native networks, by contrast, eliminate the human-in-the-loop entirely. When equipped with real-time data access, transactional capabilities, and fulfillment capacity, they execute at the speed permitted only by the slowest link in the supply chain.

This second model doesn't just accelerate execution—it fundamentally reprices time itself as a competitive asset.

As Jordi Visser articulates in his insightful piece "The Repricing of Time: Equity in the Age of Agents", agentic AI compresses competitive cycles dramatically. Velocity of execution no longer merely helps fulfill a plan faster; it redefines the playing field. When capabilities can be reconfigured almost overnight through model iterations or agent orchestration, durable moats erode. What once took decades to build—layered expertise, entrenched positions, regulatory barriers—can now be challenged or leapfrogged in months.

In this environment, equity behaves more like a call option on execution speed than on long-duration stability. "Execution speed replaces installed base. Iteration cadence replaces headcount." The advantage shifts decisively toward those who can pivot, adapt, innovate, and execute rapidly.

This dynamic hits telecom particularly hard.

Most operators are desperate to escape the "utility trench"—the low-margin, commodity perception that has trapped connectivity providers for years. They aspire to new revenue streams beyond pipes and bandwidth.

From my own experience modeling, teaching, and advising organizations on this challenge (see earlier pieces on innovation micro-strategies, telco relevance and growth, and the lean telco), there is no single silver bullet. No grand transformation program that magically reinvents the business.

Instead, the path forward involves thousands of micro-services and experiments: create, test, fail fast, pivot, scale the winners, and launch repeatedly. The era of one-size-fits-all offerings is over.

Agentic-native networks offer exactly the infrastructure to make this high-velocity approach viable at scale. They enable rapid creation, iteration, value capture, and deployment—turning velocity, flawless execution, and clear strategic vision into the new currency that outcompetes inertia, legacy systems, and eroding differentiation.

For telecom leaders, the message from GTC 2026 is clear: agentic AI can free up resources and help accelerate innovation at scale. Those who embrace this shift—building or partnering for agentic capabilities—will be the ones that don't just survive the repricing of time, but help define the next era of networked value creation.

The philosophical problem with agentic AI

Jensen Huang’s address at GTC gave me a lot to think about. So much so that I decided to drive to Sana Cruz for a taste of the ocean. I had to wait 30 minutes to get the table I wanted, just by the beach, in the sun but with a little shade… as I mistype table on my iPad, I am thankful for the autocorrect to sanitize my  somewhat boozy prose, while mostly appreciating the elegantly subtle blue underlying of the word batle, prompting me to consider “is that really what you meant to write, or do you meant table”?

I like that. I like that more than the blue pencil with the little star that insistently offers an AI assisted rewrite. Oh, sure, I am not a native English writer, so my grammar is somewhat tainted by the other 3 languages I might think in at any point in time. If I compound St Patrick and this weekend’s VI nations rugby results for France, you will understand if my writing is not the usual corporate polish. 

Having said that, I was at GTC for the first time, I listen to Jensen’s performance and I was left enlightened and a bit worried. By now, the headline and the sound bite out there must be the $1 Trillion line of sight on chip revenues for Nvidia over the next couple of years. Obviously, it is an extraordinary number. Unfathomable. Impossible to imagine for most of us. Almost impossible to think that we, collectively would spend 125$ ( at 8 billion people) of Nvidia stuff over the next couple of years. Surely that’s impossible. 

Unless this is not about need, but about demand.  Unless that demand is accelerated, compounded, exponentially nurtured beyond its natural curve. 

Essentially, what I retained from the presentation was that the larger the model, the more the interactions, the larger the demand, the faster and more the tokens have to be created to satisfy it. (I am sure AI could rewrite this sentence more elegantly, but screw it). The measurement unit becomes token per Watt,as it is a limiting factor for a given data center and tokens per second as it is the limiting factor for a given service. Jensen even alluded to the fact that they will factor in token per month grants in engineering packages as it becomes a productivity factor. 

The thesis for the 1T$ revenue relies on demand exploding and the emergence of low latency, high I/O token market. Low latency, high I/O is understandable. Multimodal, video models, requiring real time inferencing from vehicles, robots and generally physical AI will drive it. The demand explosion, though, even factoring in the integration of compute and AI in to its, devices, edges… if we look at adoption curves and industrial capacity is decades away,  not in 2 years. Unless…

Unless we are not the demand. Us, consumers, enterprises, industries, governments… Agentic AI and Clawdbot are just showing how, beyond automation, agency becomes a compounding factor. Agents, that you create, for specific purpose are understandable, useful controllable. 

Agents, that interpret your intent, create other agents to enact their interpretation, have access to your digital life, credit card, HR, accounts receivables, invoices, orders, security cameras, GPS movements better be accountable, auditable, controllable. Agents that create fleets of agents to parcel out their workload is where I have doubts. The d’explosion in demand relies on the hypothesis that we will let agents create agents consume tokens to satisfy our needs.

No doubt, we will have agents to control, audit, police agents, but it feels wrong to delegate tasks just because you can or for the concept of efficiency.

This is where the the philosophical debate clashes with the economic model. I learned that hard times create hard men. Hard men create easy times. Easy times create easy men. Easy men create hard times. We might have evolved from this adage, but I feel that, being a kinetic, rather than a literal learner, I’ve learned from trying. I’ve learned from friction. To this day, I write on my notebook with a pen. I don’t forget anything I write. I forget most of what I type. It feels to me that friction is an integral part of the learning experience. More, it is an integral part of the human experience. The taste for effort, trying the hard things, failing is not only what most mankind experience on a daily basis, it is also, at least for me a great  condition to happiness. I am infinitely happier labouring and succeeding than an automated, frictionless, efficient experience. Even with a better result.

As my children are about to enter the workforce, I am confronted daily to the question “what is a safe, fulfilling carrer?”. It used to be that medicine, law, engineering guaranteed a safe economic path. Nowadays, it looks like most entry level intellectual effort can easily, efficiently be replaced, and that agentic AI will only accelerate that trend. How are they supposed to master a domain they won’t be able to tinker and stumble? Maybe I am just an old fart and just like calculators and computers did not replace engineers, a higher level of abstraction will necessitate higher levels of intellectual efforts ? But this feels different. 

Particularly if compute keeps accelerating and artificial intelligence surpasses human intelligence, then what? What is the imperative to learn, labour, try, suffer, if is not necessary? Where do you draw the line between agents that help and augment and agents that enable and replace?

Until then, I’ll keep labouring and burdening you with poorly written posts, but somewhat original or at least unique, because they’re mine. I enjoy this table, i waited 30 minutes for because I chose it and waited for it. I am not sure it would have tasted better should my personal AI butler had booked it for me on my way there.

AI is a new G

I returned from MWC 2026 with an uneasy feeling.

The telecommunications industry has long been defined by its generational leaps—each "G" marking a profound shift in capabilities, use cases, and societal impact.

2G brought reliable digital voice and SMS, enabling mass mobile communication. 3G introduced mobile data and picture messaging, laying the foundation for internet on the go. 4G powered the explosion of social media, apps, and always-on connectivity. 5G delivered massive bandwidth, fueling high-definition video streaming.

These evolutions followed a predictable cadence governed by 3GPP standards, with operators methodically upgrading infrastructure, spectrum, and devices in multi-year cycles. Parallel to this, the network itself transformed through virtualization: from SDN separating control and data planes, to disaggregating hardware from software, and evolving VNFs (Virtual Network Functions) into cloud-native CNFs (Cloud-native Network Functions). These shifts improved flexibility, scalability, and cost efficiency but remained incremental within the familiar "G" framework.

AI is entering telecom in silos—AI-RAN for spectrum and energy optimization, agentic AI in OSS for autonomous operations and predictive assurance, customer service copilots for intent-based support—delivering proven cost savings (e.g., 25-40% OPEX reductions in network ops, up to 35% energy efficiency). Yet these domain-specific wins rarely connect into a unified, end-to-end intelligence layer. Data stays fragmented across RAN, core, edge, OSS/BSS, leading to duplicated efforts, incomplete visibility, and "agent sprawl" risks. Industry sources highlight how silos impede multi-agent ecosystems and true autonomous networks.

This misconception manifests in several ways:

Viewing AI as incremental tech add-ons — Operators often pursue isolated pilots (e.g., AI-RAN trials, genAI copilots, or agentic OSS agents) expecting quick wins without addressing deeper structural issues.

Underplaying organizational and cultural complexity — AI demands far more than engineering upgrades. It requires breaking down legacy silos (RAN/IT/OSS/BSS), fostering cross-functional agility, upskilling thousands in ML ops/data governance, and driving cultural shifts to trust agentic systems. Cultural resistance, job security fears, and fragmented skills often stall progress, with many projects failing to move beyond pilots (only ~30% of genAI use cases reach production in some analyses). Organizational challenges—including change management and silo-breaking—as top barriers, yet leadership frequently delegates AI to a separate function rather than owning it as a CEO imperative.

Misjudging the scale of change needed — Unlike past "G" evolutions (hardware/spectrum-driven, standardized via 3GPP), AI is a software-defined, data-hungry, adaptive intelligence layer that reshapes workflows, decision-making, operating models, and even business identity (from connectivity provider to intelligent platform). Treating it as "just tech" ignores the need for unified data fabrics, intent-based orchestration, governed multi-agent ecosystems, and radical process redesign—efforts that can take years, not quarters, and demand massive internal rewiring.

New vendors (hyperscalers, specialized AI-RAN players, agentic platforms) disrupt legacy supplier models, while operating models evolve toward intent-driven, cloud-native, agent-orchestrated environments requiring cross-functional agility and new skills. Massive CAPEX uncertainty surrounds compute (GPUs, accelerators), high-bandwidth memory, power, and cooling—often in the hundreds of billions globally—amid unclear ROI timelines and risks like underutilization. AI excels at cost management through optimization, but revenue-generating services (e.g., enterprise AI platforms, GPUaaS, network APIs for AI workloads, personalized offerings) remain nascent for most operators. This imbalance—cost wins without broad revenue upside, vendor shifts, and compute investment risks—demands an AI strategy that starts with organization and operational models, not technology.

This underestimation risks turning AI from a greenfield opportunity into added complexity: persistent silos, agent sprawl, duplicated investments, and missed revenue potential. Proven cost optimizations are real, but without holistic transformation, operators may achieve efficiency gains while remaining commoditized pipes in an AI-driven world. Warning to operators: AI is not "plug-and-play." Underestimating its demands—starting with organization, leadership alignment, operating model redesign, and cultural renewal before heavy technology scaling—will lead to stalled initiatives, wasted CAPEX (especially on compute/infra), and competitive disadvantage. Frontrunners recognize AI as a radical reinvention requiring bold, enterprise-wide commitment; the rest risk being left behind as the intelligence generation unfolds.