Where agentic AI actually fits in telecom OSS/BSS — and where it doesn't
I screen the engineers who build and defend OSS/BSS and network-core systems, and I built an agentic AI system to run TechNet's own outbound. Both vantage points give me an unglamorous view of where LLM agents earn their keep in telecom — and where they're a fast way to bill a customer twice.
Start with what agentic AI actually is here
Strip the marketing off it: an agentic system is a model that reads context, decides on an action, and calls a tool — repeatedly, without a human typing every step. In telecom that means it can read a ticket, query inventory, or flag a CDR pattern. It doesn't mean it should push a config change or approve an adjustment itself. The distinction that matters isn't "AI vs. no AI" — it's whether a wrong output costs a review cycle or costs a customer's bill.
Where it genuinely helps
The good fits share a shape: the output lands in a queue a human already checks, not in a system of record. A wrong answer gets caught before it does anything.
- Ticket triage and enrichment. Classifying incoming NOC and service-desk tickets, pulling related alarms and topology context, and drafting a first-pass root-cause hypothesis for the on-call engineer to confirm or discard. Summarization against noisy text — exactly what LLMs are built for, and the engineer still makes the call.
- Config and rule validation. Reviewing a proposed routing rule, charging rule, or network-slice policy against the existing rule set and flagging conflicts or drift — before it reaches a human approver and a change window. Catching a contradiction is cheap; letting one ship silently is not.
- Billing and charging anomaly detection. Scanning mediation output or rated usage for statistical outliers — usage spiking well outside a subscriber's normal pattern, a rating result outside a plan's expected range — and surfacing them for a billing analyst. Detection, not correction; the agent points, it doesn't touch the ledger.
- Test-case generation. Drafting regression and edge-case scenarios for a new charging rule, provisioning workflow, or 5G core network function, based on the spec and prior defect history. QA still runs and signs off on the suite.
- Documentation and knowledge retrieval. Answering "how does our mediation platform handle a duplicate CDR from this switch type" by retrieving from runbooks and past incident write-ups, instead of paging through a wiki. The highest-leverage, lowest-risk use case here — it touches nothing, it just makes tribal knowledge queryable.
Notice the shape: the output is a draft, a flag, or an answer — never a committed transaction, a pushed config, or a modified account.
Where it's genuinely risky — or just premature
The bad fits share the opposite shape: the output lands directly on a live system or a customer's bill, and by the time a human notices, it's already billed, provisioned, or shipped.
The live charging and rating path
Rating and charging convert usage into money, correctly, under audit obligations most systems don't carry. An LLM hallucinating a plausible rate adjustment, or "helpfully" reinterpreting an ambiguous tariff, isn't a UX glitch — it's an overcharge on a real invoice. There's no cheap-and-reviewable path here: the transaction has already happened by the time anyone reads the log. This is deterministic-engine territory. Use AI to detect anomalies in the output, never to compute the output.
Automated provisioning without a human gate
Letting an agent open a ticket is fine. Letting it close the loop — pushing an order into a live network element, or reconfiguring a 5G core network function, unattended — is a different risk category. A partially applied order can leave a subscriber record or network function in a state that's expensive to untangle, and "the model was confident" is not an incident postmortem anyone wants to write.
Order management and revenue-affecting decisions
Order management has to get sequencing and rollback right every time across dozens of downstream systems. An agent drafting the order for a human to release is useful. An agent approving a credit or auto-resolving a dispute above some threshold is making a revenue decision with no accountability attached — keep that with someone whose name is on the outcome.
The risky column isn't "harder technically." The failure mode is silent and expensive to reverse: a bad triage gets corrected next shift; a bad charging decision surfaces in a dispute months later, already reconciled against actuals.
A rule of thumb I actually use
Before I'd sign off on an AI use case touching an OSS/BSS or network-core workflow, I ask one question: if the model is wrong here, who catches it, and how long does that take? "The engineer reviewing the same screen, thirty seconds later" is a good fit. "An auditor, next quarter" means it doesn't go near production without a human approval gate — and in charging and rating specifically, it doesn't go near production at all as anything more than a detector.
This isn't caution for its own sake. The agentic system I built sources accounts and drafts outreach all day — with a human approving every send and guardrails around anything touching deliverability or compliance. Same rule: agents do the mechanical work, humans keep the parts where being wrong is expensive.
Hiring for the systems where this distinction matters
If you're staffing OSS/BSS, mediation, charging, or 5G core roles — or need someone who can draw this line on your stack, not just recite it — tell me the seat.
Tell us the seat