OSS and BSS in 2026: From Automation to Autonomous Networks

Two years ago, OSS and BSS modernization was framed mostly as a migration problem: get off legacy, on-premises systems, onto cloud-native, microservices architectures, and prepare for whatever 5G would eventually require. That framing hasn't aged badly, but it has aged. The migration is largely underway. What's changed is what operators are migrating toward.

In 2026, the operative question isn't "should we modernize OSS/BSS" it's what a modernized stack now has to do: run autonomous agents that take real action on the network, expose network capability as a monetizable API, and survive a BSS vendor landscape that just went through its biggest consolidation in years. This update covers what's actually different since 2024, what's still overhyped, and where engineering leaders should be putting their attention now.

The 2024 version of this conversation talked about AI/ML "transforming network operations through predictive maintenance and automated anomaly detection." That was accurate but modest: it described AI that flags problems for a human to act on.

By 2026, the industry has moved a level further. TM Forum's own Autonomous Networks research describes 2026 as a point of genuine, structural change after years of what it calls "tinkering at the edges," with agentic AI as the primary driver: models capable of proactive, multi-step reasoning and taking action, not just surfacing an alert. Early adopters at Level 4 autonomy, China Mobile among them, are reporting steep, measurable cuts to maintenance costs and fault-repair times rather than pilot-stage anecdotes.

That shift is also forcing interoperability questions the industry hadn't needed to answer before. In mid-2026 the Linux Foundation, working with Huawei, China Mobile, and the GSMA, launched the OpenAN project specifically to build a shared technical foundation so that specialized telecom AI agents from different vendors can hand off work to each other safely, an anomaly-detection agent on the RAN side needs a way to trigger a remediation agent elsewhere in the stack without every vendor pair requiring a bespoke integration. That's a materially different engineering problem than the rules-based automation most OSS teams built five years ago.

Where the 2024 article flagged "TMF Open APIs" as an emerging standardization effort, that effort has since productized into something operators are actually booking revenue against: GSMA's Open Gateway initiative, built on CAMARA, the open-source API specification project run with the Linux Foundation.

The numbers as of Q1 2026 give a sense of scale: 33 certified, CAMARA-tagged APIs released (with another 40 in development), 81 operator groups and 61 channel partners representing 292 networks, covering roughly 80% of global mobile connections. Of that, 140 API instances are commercially live across 85 networks in 50 markets, and 27 of those markets have reached full API alignment across their operators.

Practically, that means capabilities like number verification, SIM-swap detection, and location verification are no longer one-off integrations negotiated per carrier; they're standardized, meterable APIs that plug into the BSS layer the same way a product catalog entry would. For engineering teams, that shifts part of the BSS mandate from internal billing and order logic toward treating network capability itself as a product to expose and monetize. The gap that hasn't closed: identity and anti-fraud APIs are where the commercial traction actually is right now, while the more ambitious "programmable network" APIs (quality-on-demand, edge discovery) are still working through the same pilot-to-revenue gap that slowed early 5G monetization generally.

This is the development that didn't exist in any form in the 2024 article, and it's arguably the single biggest structural change in the OSS/BSS vendor landscape since then: two of the industry's most consequential acquisitions both closed in 2026.

Amdocs completed its acquisition of MATRIXX Software, a real-time charging and monetization platform used by operators including Verizon, TELUS, Telefónica, Three, Virgin Media O2, and Telstra, in a deal worth roughly $197 million that closed in the first quarter of Amdocs' fiscal year. Separately, and at much larger scale, NEC completed its approximately $2.89 billion acquisition of CSG Systems in May 2026, with NEC's Netcracker subsidiary taking over leadership of the combined business.

For any operator or engineering partner whose modernization roadmap assumed a specific charging or BSS vendor would keep operating independently, that assumption no longer holds in the same way. It's not pure consolidation, though: cloud-native, usage-based challengers like Totogi and Optiva continue to compete for the MVNO and digital-telco segment specifically because they aren't part of a Tier-1 supplier stack. The practical effect is a market splitting into two tiers: large, converging full-suite vendors serving Tier-1 operators, and lean, API-first alternatives serving everyone who wants to avoid that lock-in. Either way, vendor-roadmap risk is now a modernization planning input in a way it wasn't in 2024.

The 2024 article described network slicing as a coming requirement for OSS systems to manage "dynamic, virtual network resources." Two years on, slicing has real commercial deployments, but concentrated in a narrower place than the original 5G marketing promised.

The prerequisite infrastructure is now in place at scale: the GSA counted at least 85 operators across 47 markets running commercial 5G Standalone networks by the end of 2025. On top of that, BT is preparing a commercial 5G network-slicing launch in the UK for summer 2026, built on Ericsson's dual-mode 5G core and using Network Slice Selection Function (NSSF) for dynamic, real-time slice assignment alongside NEF APIs for external exposure. Vodafone Business moved slightly earlier in 2026, positioning itself as the first UK operator to offer 5G slicing backed by a formal service-level agreement.

Where the paying use cases actually are: private enterprise and manufacturing networks, plus public-safety and large-event connectivity, not consumer mobile plans. The "one SIM, several guaranteed slices" vision for individual subscribers is still mostly a roadmap slide. Slicing is also where the autonomy theme from Section 1 shows up concretely: Nokia and AWS introduced what they describe as the first agentic AI-powered network-slicing capability running in commercial 5G-Advanced networks, with early pilots underway at du and Orange, letting a slice reconfigure itself against a service-level target rather than requiring a manual change request.

In 2024, cloud-native, microservices, Kubernetes, containerized OSS/BSS, was the forward-looking architecture worth calling out. In 2026, it's simply the baseline; the differentiation has moved up a layer.

TM Forum used its DTW Ignite event in Copenhagen in June 2026 to introduce AI-native extensions to its Open Digital Architecture (ODA) standard, adding components for dynamic 5G slicing with real-time, intent-driven autonomy (from order through provisioning, assurance, and self-healing) and a "sovereign AI inference" pattern that lets operators run AI models within defined jurisdictional boundaries, a direct answer to the same data-residency and GDPR pressures the 2024 article raised, now built into the architecture rather than handled case by case.

What hasn't changed is the hard part underneath it: legacy integration. TM Forum's own commentary for telecom CIOs and network architects keeps landing on the same point: a sophisticated model is only as useful as the data pipeline, interface standards, and operational visibility feeding it, and, as TheEdge AI 2026 says, most estates still stitch together RAN, fiber, cloud, edge, and whatever OSS/BSS layers were already there, none of which were originally built to share information with each other. A composable, AI-native architecture doesn't remove that integration work. It gives it a shared standard to integrate against, instead of a fresh custom adapter for every legacy system, which is a real improvement, but not the finish line some 2024-era roadmaps implied it would be.

The compliance backdrop has moved since 2024 as well. The EU's NIS2 Directive, which sets baseline cybersecurity and incident-reporting requirements for telecom operators and other essential-service providers, is now in force, with most member states having transposed it into national law through 2024 and 2025. Notably, EU lawmakers are already working through a 2026 legislative proposal to simplify NIS2 and align it with a forthcoming Cybersecurity Act 2, a reminder that this baseline is still actively moving, not settled.

More interesting is a governance question the 2024 article's RBAC-and-encryption checklist didn't anticipate: once agentic systems are making cross-domain remediation decisions or reconfiguring a network slice on their own (as described in Sections 1 and 4), the audit question changes shape. It's no longer just "who approved this change"; it's "which agent decided this, on what evidence, and can we replay exactly what happened." That's why TM Forum's own transformation agenda names responsible AI and governance as a standing pillar alongside autonomy itself, rather than an afterthought bolted on once the automation ships.

That's also the layer Waverley's AI Application Engineering work, built on the Skywood framework, is built to address directly: replayable execution traces, versioned agent components, evaluation gates, and runtime policy enforcement, treated as engineering requirements from the start rather than added after a pilot goes into production. OSS/BSS teams building agentic capability into network operations are now facing exactly that same requirement.

The future of OSS/BSS modernization will not be defined simply by which trends organizations choose to adopt, but by how prepared they are to answer the fundamental questions those trends raise. Understanding and governing the actions of autonomous network agents, reducing dependency risks in an increasingly consolidated vendor landscape, monetizing network capabilities through scalable APIs, and moving network slicing from roadmap ambitions to real production use cases are all indicators of how ready an organization is for the next stage of transformation. These are no longer distant considerations—they are practical challenges that can directly shape operational resilience, revenue opportunities, and long-term competitiveness.

Addressing them, however, requires more than selecting a new platform or implementing the latest technology. The underlying challenge remains the same: finding a way to connect decades of legacy infrastructure and investment with an entirely new operating model without disrupting the systems that already support critical production environments. Successful modernization depends on balancing innovation with stability, creating architectures that can evolve while maintaining reliability, visibility, and control.

This is where a focused engineering approach becomes essential. Through AI-Enabled Legacy Modernization and Platform Stabilization & Reliability Engineering, organizations can address the complexity of transforming existing environments while strengthening the foundations required for future innovation. As AI agents increasingly become part of network operations, AI Application Engineering, supported by the Skywood Framework, can also help organizations build the governance, integration, and reliability needed for this emerging agentic layer. Ultimately, the goal is not modernization for its own sake, but building OSS/BSS environments capable of adapting to what comes next without compromising what already works today.