Only 16% of GenAI deployments in telecom have reached network operations. The rest sits in customer service, billing, and administrative workflows (GSMA Intelligence, Telco AI: State of the Market, Q4 2025). The AI investment is real. It just isn't touching the network. The AI investment is real. It just isn't touching the network.
Two things explain the gap. The first is a trust deficit: operators who have been burned by automation with no audit trail are, understandably, in no hurry to hand over a second chance. The second is an autonomy ambition that has outrun deployment reality: 79% of operators remain at TM Forum Level 0-1 autonomy today, despite widespread industry talk of Level 4 and 5 (Accenture / Fierce Network, Autonomous Networks Level Report, March 2026).
The open question in telecom AI was never whether artificial intelligence belongs in the network. It already does, in monitoring, in analysis, in recommendation. The open question is whether it can be trusted to act there, on its own, on a live network, with consequences that can't be undone by a support ticket. Determinism is the mechanism that answers that question: the foundation that lets operators extend autonomy safely, one validated action at a time, rather than a constraint holding autonomy back.
Level 3 already means heavy execution automation: dynamic, policy-driven responses to real-time network changes, with AI-assisted decisions across domains. Level 4 keeps a human confirmation step before an agent's proposal goes live. Level 5 removes that checkpoint and lets the system act on its own. The 79% of operators still at Level 0-1 (Accenture / Fierce Network, Autonomous Networks Level Report, March 2026) haven't even reached that Level 3 threshold yet. Some are held back by the investment case, others already have the tools and are held back by trust.
The Cost of Guessing on a Live Network
In most enterprise software, a wrong automated decision is an inconvenience. A chatbot gives a bad answer, a form auto-fills incorrectly, someone corrects it and moves on. A telecom network doesn't offer that grace period.
When automation is applied to the operation of a live Radio Access Network (RAN), core, or transport network and gets it wrong, the failure modes are a Service Level Agreement (SLA) breach, a degraded cell affecting thousands of subscribers, or, in the worst case, a change that touches infrastructure emergency services depend on. There is no "undo" button on a network configuration change that has already propagated. The action has already happened, in real time, to real traffic.. The action has already happened, in real time, to real traffic.
This is the difference that gets lost when telecom AI is discussed in the same breath as consumer AI products. A misfiring automation rule doesn't produce an awkward chat transcript. It produces a 3 a.m. escalation call, an engineer pulled out of bed to manually reverse a decision the system made on its own, and a fresh reason for the next automation proposal to get a harder look than the last one.
The Trust Deficit
The GSMA and Accenture / Fierce Networks numbers describe the same underlying pattern from different angles: an industry that has adopted AI widely everywhere except the place with the highest operational stakes. GenAI usage across telecom is broad. Deployment into network operations, where the risk profile changes entirely, has stalled.
Three reasons show up consistently when operators explain the hesitation.
General-purpose models lack precision on network-specific tasks
An LLM trained on general text doesn't know an operator's KPI definitions, its topology hierarchy, or the difference between a hardware failure signature and an interference pattern on that specific network. Every network is configured, counter-named, and integrated differently, and a model without deep domain grounding produces plausible-sounding answers that don't hold up against production data.
There is no audit trail when automation acts incorrectly
More pilots won't fix that, because the shortfall is a governance failure, not a maturity gap. An operator can tolerate a system that is occasionally wrong if it can see why the system decided what it decided and reverse the decision cleanly. What operators can't tolerate is a black box that acted, can't explain itself, and left no record for the post-incident review.
Vendors answer the trust question with confidence instead of proof
"Enterprise-grade" and "99% accurate" are marketing claims, not evidence. Sutherland Global's 2025 research on telecom automation found that 45% of operators hesitate to fully trust AI-driven automation specifically because of this kind of opaque, unverifiable decision-making and closing that gap takes a verifiable audit trail, not confident marketing language.
Where the Industry Blurs the Line
A meaningful share of the trust deficit is self-inflicted, not by operators, but by how the industry talks about AI in the network. GenAI, predictive AI, and agentic AI get collapsed into a single undifferentiated idea, usually summarized as "the LLM handles it." That collapse is where trust breaks down, because the three do fundamentally different jobs and carry fundamentally different risk profiles.
GenAI is suited to exploration and interface: querying network data conversationally, summarizing a root-cause investigation, making data accessible to someone who isn't a data scientist. Predictive AI, typically ML models trained on an operator's own historical data, is what optimizes decisions: classifying a degradation type, scoring a probable cause, forecasting where a KPI is headed. Agentic AI executes, but only inside deterministic guardrails that were established before the agent ever touched the system.
Consistency is the sticking point underneath all of this. Operators don't ask for 80% or 90% reliable, they ask for it to always work on the pattern it has learned, and "always" is not a property generative AI has on its own, because it is probabilistic by design. The industry's usual fix is stacking rules and constraints into the prompt itself, in effect writing code inside a chat window and calling it an agent. That gets closer to consistency, but it gives up the flexibility that made GenAI useful in the first place, and it still is not verifiable the way a deterministic rule is. Consistency only becomes real once a pattern has been identified and captured outside the model, so the same input produces the same output every time it recurs.
Treating these as interchangeable, as if a single large language model can responsibly discover a pattern, decide on the fix, and execute it against live infrastructure, is the single biggest credibility risk in telecom AI messaging today. It's also, not coincidentally, the exact claim that a technically literate buyer will stress-test first.
The BSS/OSS Risk Asymmetry
Part of what makes this collapse so costly is that BSS and OSS automation don't carry the same risk, and vendors that treat them the same are getting the architecture wrong before they've written a line of code.
A failure in BSS, billing, CRM, order management, has a smaller blast radius and is recoverable after the fact. Reissue the bill. Retry the transaction. Apologize and credit the account. That makes it more admissible than a network failure, but not acceptable. A customer moved to the wrong plan, or billed for a service they never used, still loses real money and loses trust in the operator, even when the fix on Tupl's side is a known one.
An automated action that touches the network, or a customer's service, directly is a different category of problem, whatever system triggered it. A bad automated change to network configuration can cascade through interdependent network elements and degrade or drop service for an entire cell, market, or region, in real time, with no undo. There is no retry button for a dropped call during an emergency, and no credit that restores a subscriber's trust in coverage that failed when they needed it, or in a plan change that quietly started costing them more.
The lesson is architectural: any automation that can reach the network or a customer's live service directly needs a different trust architecture than automation confined to back office systems, with tighter guardrails, more conservative default behavior, and a much higher bar for what gets to execute without a human checkpoint. The dividing line is what the action touches, not which system label it carries. Operators should push back hard on any vendor applying one governance model across both.
Tupl's Architecture: The Hybrid Principle
Tupl's answer to the OSS risk problem is architectural separation. Raw network data, the PM counters, alarms, and traces generated at massive scale, feeds Tupl's AI-native automation system, which handles deterministic execution: rules, KPI computation, ML models, and closed-loop remediation services. AI agents sit on top of that system. They reason over the insights it produces and never touch raw network data or execute a change directly.
The core line is deliberately simple: agents discover, deterministic engines execute.
Having a language model process raw or near-raw network data at production scale is cost-prohibitive and produces inconsistent results, because LLM inference at that volume doesn't hold up economically or technically against millions of daily KPI data points. The workable division of labor is the deterministic engine processing data at scale, and the agent consuming the resulting insight to reason, investigate, and propose what should change next.
Put a number on it. A network with 30,000 to 40,000 sites generates a fresh round of counters every 15 minutes. Feeding that continuously into an agent's context window means paying token costs for volume, not for reasoning, and the context fills up before the agent gets to the decision. The usual workaround is to split the problem into many narrow, purpose-built agents, one per issue type, so each context stays small. That does not control the token bill, it multiplies it, and it quietly turns prompt engineering into a second, less disciplined coding language, since each narrow agent is really a hand-tuned rule wearing an agent's name. Deterministic execution is not only a governance argument. It is a cost and consistency argument too.
Just as important as where the line sits is when governance happens. Review, validation, and guardrail checks happen before deployment, when a new automation pattern is proposed, not after it's live on the network, when a live decision is already in flight. By the time an agent's proposal is anywhere near the network, it has already been through a human and governance review. Nothing is improvised against production traffic.
The Trust Progression: A Staged Path, Not a Leap
No operator hands a vendor Level 5 autonomy on day one, and no vendor that understands OSS risk should ask for it. The credible path runs through three stages, and it maps closely to what Tupl has seen play out across live deployments.
Open-loop, trust building
The system recommends. The engineer validates and acts. This stage is often described as low-value by vendors in a hurry to sell autonomy, but it's where the real work of trust starts, and knowledge is already being codified here too, just on the analysis side rather than the action side, since the action still belongs to the engineer. In one deployment, this stage delivered the equivalent of 40 man-days of expert RF analysis in minutes per 500-site cluster, at 90% accuracy validated by the operator's own engineers.
Closed-loop, knowledge codified
Automated remediation now happens within defined guardrails, for the incident types where accuracy has been proven over a sustained period. In a deployment where an operator was insourcing network optimization from a managed-services contract, and the expert knowledge behind it was at risk of walking out the door with departing vendor engineers, this stage codified 24 distinct root causes into ML models at better than 97% accuracy, an effect equivalent to doubling the engineering team without adding headcount.
Full autonomy, knowledge autonomous
Automation now runs at national, multi-vendor scale, still governed, still auditable, still reversible. One Tier-1 operator running this stage across a national multi-vendor footprint saw a 67% reduction in analysis time across hundreds of KPIs, with 60% of reported issues auto-closed.
Credibility here comes down to how a vendor gets to autonomy, not just whether they eventually reach it. Vendors tend to fall into one of two failure modes: promising full autonomy up front, which is a credibility red flag to any operator who has been burned before, or staying stuck at advisory forever because there's no architecture for safely extending trust. A staged path with evidence at each transition is the only version of this that a skeptical technical buyer should accept.
The Hive: Turning Engineer Corrections into Governed Assets
The mechanism that makes the staged path get faster instead of staying flat is what Tupl calls the Hive, a governed institutional memory layer. It isn't a chatbot log or a vector store of past conversations. It holds rules, features, pipelines, and models, along with the institutional knowledge of how a given network actually behaves, the kind that normally lives only in the heads of the engineers who have worked it for years, absorbed automatically through every correction made along the way. That is different from how most agentic deployments handle context today. A single agent can be tuned carefully to one engineer's workflow, but that tuning stays local. It does not reach the next agent, the next team, or the next engineer who runs into the same problem after the first one has moved on. The Hive turns what one agent or one engineer learns into shared enterprise context that every agent draws on, so the system's best decision does not depend on which agent happened to see the problem first.
That happens through a loop that runs in five steps. An issue surfaces and gets a first hypothesis, sometimes flagged by an agent, sometimes caught another way with an agent joining once something looks suspicious. An engineer corrects that hypothesis, often adding the reasoning behind the real fix, and that correction, along with the context behind it, is the actual value being created. Agents then draft the fix based on the correction, or move forward on the engineer's approval when the original hypothesis already held up. Governance reviews and approves before anything reaches production. That fix carries forward automatically, so the next engineer who hits the same pattern doesn't have to repeat the diagnosis from scratch.
None of this replaces the engineer. It's built around them. Their correction, or their sign-off, is the asset the Hive is actually made of. And this is the mechanism by which the deterministic core's coverage keeps expanding without ever loosening governance. Every correction becomes a permanent capability, reviewed once and then available to the entire team indefinitely, including the engineers who join after the one who made the original fix has moved on.
Proposed Approach: Tupl's Playbook for Deterministic Autonomy
Tupl has spent over a decade deploying pragmatic AI solutions inside large enterprises and telecom operators. That experience surfaces a consistent pattern in what separates operators who progress through the trust journey from those stuck in deployment stagnation.
- Governance before scale. Guardrails get built before deployment. Adding them after an incident is already too late.
- Structural separation, not policy separation. Agentic reasoning and deterministic execution sit in physically separate systems, so the boundary is enforced by the architecture itself, independent of whether anyone remembers to follow a policy.
- Engineer correction as the growth engine. The system's intelligence compounds through the time engineers spend correcting it. Every correction is an investment in what the system knows next time.
- Staged trust, proven at each step. No operator is asked to accept full autonomy before the deterministic core has earned it, stage by stage, with evidence at every transition.
- Cross-domain compounding. Institutional knowledge captured in one deployment, whether that's network performance automation, customer care, or NOC operations, benefits every other deployment, without customer data crossing tenant boundaries.
- Cost and scale designed in, not bolted on. Token consumption, compute cost, and system scale get engineered from day one, before growth turns them into a problem.
In the near future, saying "We don't know which agent did this, who authorized it, or why it had those credentials" may sound as unacceptable as saying today "We don't know which user accessed the database."
— Pablo Tapia, Chief Product Officer, Tupl
Conclusion
Operators aren't behind on AI. They are, in most cases, right to be cautious about where they let it act on infrastructure that can't be rolled back with an apology and a credit. What moves them forward isn't another round of confidence claims from vendors, but a staged, governed, auditable path, proven one validated action at a time.
Determinism sets the floor that autonomy stands on, the groundwork that has to be in place before an operator can safely extend how far network autonomy is allowed to go.
