Evaluating OSS Vendors for AI-Native Capabilities

OSS modernization spending is set to climb from $16.34 billion in 2025 to $18.66 billion in 2026, a 14.2% compound annual growth rate that tells you operators aren't debating whether to modernize anymore. They're writing checks. Agentic AI in telecom specifically is projected to jump from $92 million in 2025 to $6.2 billion by 2030, and that speed of arrival has outrun most buyers' ability to test what any given vendor is actually selling them. Every major OSS vendor now slaps "AI-native" on its marketing deck, which means the term itself has stopped telling you anything useful. What follows is a set of criteria built to test depth of integration, not the presence of a chatbot bolted onto a legacy screen.

What AI-native means in an OSS platform, and what it doesn't

Three generations of OSS exist, and mixing them up is the first mistake buyers make. OSS 1.0 and 2.0 were hardware-bound, reactive, siloed by domain. AI wasn't part of the design conversation at all. Then came the bolt-on generation: existing platforms with AI modules layered on top, while the underlying data model and workflow architecture stayed exactly as they were. AI-native, sometimes called OSS 4.0, is different in kind rather than degree. AI pipelines sit as first-class citizens inside the data model itself. The platform was built from the ground up to ingest, reason over, and act on real-time data, not retrofitted years later to fake that capability.

The shift being asked of OSS, per futurenetworld.net's analysis, is that it move from managing tasks to orchestrating intelligence. That's a real distinction, not a rebrand. Industry consensus around what counts as AI-native tends to cluster around a few traits: cloud-first architecture, modular microservices, real-time data pipelines, and systems built for continuous learning rather than periodic retraining cycles. A monolith with a dashboard bolted on top doesn't qualify no matter what's printed on the box.

Here's a diagnostic that cuts through most of the marketing noise fast: ask whether the AI agents in the platform share the same APIs, the same data model, and the same permission structures as the human operators using the system. Or do they live in a separate layer, with separate access, querying a separate copy of the data? If the AI operates outside the platform's governed data model, it's bolt-on, regardless of what the vendor calls it in the pitch. Telecoms Tech News stated it directly: a useful agent isn't a chat wrapper. It needs typed tasks, vocabulary aligned to a standard industry data model, real topology and inventory context, policy bounds, an audit trail, human-in-the-loop for high-stakes changes, and the ability to negotiate with other agents. Anything short of that is a demo, not a platform.

Criterion 1: How deeply AI is embedded in the platform's data model

A widely recognized core problem in OSS/BSS transformation is that OSS and BSS have stayed fragmented for decades, which blocks a unified view spanning the customer, the network, and the business. Fragmentation isn't an abstract architectural complaint, either. In a fragmented environment, confirming service activation means updating several systems independently, and their status disagrees with each other until someone sits down and manually reconciles it. Billing is blocked until activation confirmation propagates fully across systems, and fragmentation is exactly what causes that propagation to stall.

So what should a buyer actually look for? A single unified data model spanning qualification, design, provisioning, and activation, not four separate databases that sync on a nightly batch job and call it integration. AI agents need to train and operate against that same unified model rather than pulling from a walled-off AI-specific data store that only the AI layer can see. Real-time pipelines matter here too: stale data six hours old causes an AI system reasoning over it to produce decisions that are six hours stale, no matter how sophisticated the model driving that reasoning. Standards alignment (TM Forum's Open Digital Architecture, SID-aligned vocabulary) signals that the data model was built for interoperability rather than to lock a customer into one vendor's proprietary schema.

NTT DATA's OSS architectural framework points toward what this looks like when done well: a federated approach that supports a unified topological view rather than siloed, replicated data stores. That's the pattern to ask vendors to demonstrate. During a demo, push for specifics: can the platform show a single record for a service instance reflecting its current state across qualification, provisioning, and billing, all at once? And what's the actual latency between a field event happening and a billing-ready status update landing in the system?

Criterion 2: Whether AI governance is structural or cosmetic

Omdia's 2026 report names the gap: the key challenges operators face are integrating AI agents with legacy OSS and establishing governance control strong enough to matter. Providers generally aren't short on AI capability. They're short on a system to operate that capability responsibly across the telecom stack.

Structural governance means guardrails, approval gates, and decision logs get enforced at the platform level, automatically, every time. Cosmetic governance means those same things get written up in a policy PDF that nobody consults during an incident. The distinction is everything. Buyers should check whether AI agents operate under the same permission structures and role-based access controls as human operators, rather than running on elevated or separate credentials that skip the normal checks. Every autonomous action should produce an audit log that can be exported. If explainability only exists inside the vendor's own interface, the operator doesn't actually own its own accountability record, it's renting it. Human-in-the-loop needs to be configurable by action type and risk level, not a single on/off switch for the entire platform. And policy enforcement should be machine-readable and applied at runtime, not asserted after the fact in a report.

Blue Planet (Ciena) frames its AI Studio design principle this way: every agentic process should be transparent and auditable, so that increased autonomy doesn't come at the cost of oversight. That's a claim worth pressure-testing directly in a demo rather than taking at face value. ServiceNow describes its AI Control Tower as registering every agent, setting and enforcing policy, monitoring execution, and producing audit evidence, framed explicitly around EU AI Act compliance support. Amdocs' aOS is described as orchestrating agentic workflows with compliance and observability considerations built into its design for telecom operations. And a peer-reviewed Agent Governance Framework (doi.org/10.3390/ai7090347) proposes smart-contract-based governance to make autonomous decisions verifiably accountable and traceable, which gives buyers an actual reference architecture to measure vendor claims against instead of taking their word for it.

Watch for one specific red flag: governance described purely as a reporting feature rather than an enforcement mechanism. Logging what happened after the fact is not the same thing as constraining what's allowed to happen in the first place.

Criterion 3: Whether the agentic architecture supports multi-agent workflows or only single-agent tasks

Ericsson's analysis names multi-agent AI as the architecture pattern defining OSS/BSS transformation through 2025 and 2026, and calls it a structural overhaul of telecom operations rather than an incremental upgrade. That framing matters because single-agent automation, however capable, hits a hard ceiling fast in service delivery.

Think about what a single fiber service order actually touches: qualification, inventory, design, provisioning, activation. Those aren't steps one agent can own end to end, they're distinct domains with distinct systems of record. RAN, transport, core, and BSS all need to negotiate with each other across a single change, and a lone agent has no built-in mechanism for that kind of negotiation. Without agent-to-agent coordination, a workflow that looks automated on paper still needs a human standing at every handoff, clicking the button that moves work from one automated island to the next.

So the real test is whether agents can delegate subtasks to other agents and receive results back, rather than simply triggering a step and waiting for a person to notice it finished. Conflict resolution should happen inside the agent layer as a matter of course, not escalate to a human by default every time two systems disagree. Agent-to-agent interactions need to show up in the audit trail as visible events, not vanish as hidden internal calls nobody can inspect later. Mplify (formerly MEF Forum) has a framework covering Agent-to-Agent communication for real-time federation and orchestration across providers, an emerging standard worth asking any vendor to demonstrate compatibility with directly. Amdocs' aOS is described as orchestrating agentic workflows across business and network operations end to end, a claim best tested by asking for a live demo of a multi-domain service order moving through the system without a human touching it in the middle. One good diagnostic question here: what happens when two agents acting on the same service instance produce conflicting state? Ask the vendor to walk through resolution, and ask exactly where that resolution gets logged.

Criterion 4: How the platform handles service delivery workflows specific to FTTH, dedicated internet, and Carrier Ethernet

Generic network management software tends to fall apart here, because FTTH, dedicated internet, and Carrier Ethernet each carry their own qualification, provisioning, and assurance logic. A platform built around mobile core operations simply doesn't have that service-specific logic baked in, no matter how well it handles RAN.

Competitive pressure is driving this, and it is not theoretical. MSOs have faced growing competitive pressure from FTTH operators pushing symmetrical gigabit and multi-gigabit services into markets that used to belong to cable. MCTV's Excellerate Fiber service illustrates the operational scale involved: available to more than 80% of homes passed, more than 70% of subscribers already on fiber, and 250 HFC power supplies decommissioned since early 2025. That pace of cutover generates real-time provisioning volume that a manual OSS workflow simply cannot absorb without falling behind.

For FTTH specifically, look for zero-touch provisioning across PON, Active Ethernet, and Fixed Wireless, not just one access technology while the others need manual workarounds. Field execution data should flow directly into billing without a manual verification step sitting in between. AEX documents a workflow where job completion, captured in real time, triggers billing automatically, which is the benchmark worth measuring against. For Carrier Ethernet and dedicated internet, check for service design templates spanning L3VPN, EVPN, and L2 circuit provisioning: Juniper Paragon Automation supports these templates as a concrete capability worth asking vendors to match. Alignment with Mplify's Lifecycle Service Orchestration framework, including NaaS payloads via Model Context Protocol, is another marker to check. Post-provision health monitoring should tie back to the same service record rather than living in a separate assurance tool nobody cross-references. The sharpest diagnostic move available: ask the vendor to walk through the complete workflow for a new fiber order, from address qualification through ONT activation to first invoice. Any step that requires a manual system touch or a status check in a separate tool is a gap, full stop.

Criterion 5: Whether the platform's AI portability protects the operator from the next round of lock-in

The risk here is structural. Per Telecoms Tech News's analysis, operators standardizing on a proprietary agent bus in 2026 are set up to face the same unwind costs in the 2030s that proprietary OSS platforms created for an earlier generation of operators. History doesn't repeat exactly, but the mechanism (deep dependency on a single vendor's schema, built up slowly, unwound at enormous cost) rhymes closely enough to take seriously.

Real portability requires a few concrete things. Guardrails, approval gates, and decision logs need to be exportable in formats an operator's own team can read, not locked behind a proprietary viewer that only works inside the vendor's console. Agent definitions need to use a portable, standard-aligned vocabulary, SID-aligned and TM Forum Open Digital Architecture-oriented, rather than a proprietary schema that only makes sense inside one platform. APIs need to be open and documented well enough that a future platform could read the current platform's audit and configuration records without needing the outgoing vendor's help to do it.

Telecoms Tech News frames the stakes bluntly: multi-vendor agent interoperability is how an operator stops the next OSS monopoly from forming in plain sight. Buyers should ask vendors directly whether the full audit log of every agent action can be exported in a standard format without proprietary tooling. Whether agent definitions are expressed in an open schema portable to another orchestration layer. Which TM Forum Open APIs the platform exposes natively, and which ones require custom integration work to bolt on. Claims of being "open by design" need to get tested against actual API documentation, not the marketing copy sitting next to them, because openness is a property of the interfaces themselves, not a line in a pitch deck. An AI-native platform that ends up owning an operator's audit trail and policy definitions has effectively become infrastructure at that point. It's infrastructure, and it deserves the same scrutiny a buyer would apply to a core network hardware decision.

How to structure the vendor evaluation process using these criteria

Start with the data model, not the demo. Request the vendor's data model documentation before a single live demo gets scheduled. If qualification, design, provisioning, and activation don't share one model on paper, no demo is going to fix that gap later, it'll just distract from it.

Run a governance test next: ask the vendor to show a complete audit log from a prior customer's environment, anonymized if needed. A vendor with structural governance will have this ready almost immediately. A vendor with cosmetic governance will offer a screenshot instead of a real export, and that gap tells you most of what you need to know.

Then run a workflow test built around services the buyer actually delivers, not a generic use case from the vendor's own script. Pick a specific FTTH order, a Carrier Ethernet turn-up, a dedicated internet change, and walk it through the platform end to end. Count the human touchpoints as you go. Follow that with a multi-agent test: present a conflict scenario where two agents act on the same service instance at the same time, and ask the vendor to show exactly how the platform resolves it and where that resolution shows up in the audit log.

Finally, run a portability test. Ask for a data export of the agent policy configuration and the last 90 days of audit logs, in a format the buyer's own team can parse without needing the vendor's tooling to open it. Good answers to all of this look consistent: documentation that already exists, demos built on real workflows rather than staged ones, exports available on request without friction. Deflection tends to sound the same across vendors too: "we can customize that," "our roadmap includes that," or "let's set up a second call with our AI team." Any of those phrases, on their own, isn't disqualifying. All of them, stacked across five criteria, is an answer.