Key takeaway
- Agentic AI in telecom: where AI agents fit in network operations, care and fraud, what TM Forum, 3GPP and GSMA say, and how operators govern autonomy.
Agentic AI in telecom is the use of AI agents that read network, service and customer data, decide what to do, and act inside limits the operator sets: triaging alarms, proposing or applying configuration changes, resolving customer requests and flagging fraud. Unlike scripted automation, an agent works towards a goal, calls tools across OSS, BSS and CRM systems, and hands the decision to a person when it falls outside its authority.
For operators, the practical question is not whether agents can act, but which decisions they may take alone. The industry already has a yardstick for that: TM Forum's autonomous network levels run from Level 0 (manual) to Level 5 (fully autonomous), and many operators have set Level 4 as their goal. This guide covers the use cases, the reference architecture, what the standards bodies say, and how to govern autonomy as it grows.
If you are new to the underlying concepts, start with our guides to agentic AI frameworks and use cases and AI agents. For process-level automation such as onboarding, billing and provisioning, see agentic process automation in telecom. This post focuses on the decisions agents make across network operations, customer care and revenue assurance.
What is agentic AI in telecom, and how is it different from automation?
Telecom has automated for decades with rule engines, scripts and forecasting models, but each does one task and none pursues an outcome across systems. An agent perceives (alarms, KPIs, tickets, customer history), reasons (likely cause and plan), acts (calls inventory, ticketing or configuration APIs) and checks the result before closing the loop.
| Approach | What it does | When it fits | Limit |
| Rule-based automation and scripts | Runs fixed steps when a known condition occurs | Stable, well-understood procedures with few exceptions | Breaks on new fault patterns and unstructured inputs |
| Predictive analytics and ML models | Forecasts traffic, failures or churn and raises a score or alert | Capacity planning, predictive maintenance, churn risk | Tells people what may happen; someone else must act |
| Agentic AI | Plans and carries out multi-step work across systems towards a goal, within set limits | Cross-domain work such as fault triage, service assurance and dispute resolution | Needs governed data, clear decision rights, audit trails and human approval for risky actions |
The difference matters most where work crosses silos. A dropped-call spike is a network, customer-care and possibly billing event at once; an agentic design lets a coordinating agent join those views, propose one action and record why.
Where does agentic AI fit in telecom operations?
Good first use cases share three traits: the data exists, the outcome is measurable, and a wrong action can be caught or reversed.
| Use case | What the agent does | When it fits | Autonomy to start with |
| Alarm correlation and fault triage (NOC) | Groups related alarms, traces them to a likely cause such as a recent change, and drafts the incident | Alarm floods across multi-vendor RAN, transport and core | Recommend; engineer confirms |
| Network optimisation and self-healing | Adjusts parameters, reroutes traffic or restarts a failed function after checking impact | Repeatable fixes with a tested rollback | Act within limits for low-risk, reversible changes; approval for the rest |
| Predictive maintenance and field dispatch | Reads equipment telemetry, predicts failure, books the right technician and parts | Towers, power systems and remote sites with good telemetry | Act on scheduling; approval for site visits with high cost |
| Customer care and service requests | Resolves plan changes, outage questions and simple faults end to end; passes complex cases to people with full context | High-volume journeys with clear policies | Act for routine requests; human handover for complaints and vulnerable customers |
| Fraud detection | Spots abnormal usage or access behaviour, such as SIM swap patterns, and opens a case or blocks a transaction | Fraud types with known signals and a fast review loop | Block within agreed thresholds; analyst reviews |
| Billing assurance and disputes | Checks usage, rating and plan configuration, finds the cause of a disputed charge and proposes a correction | Revenue leakage and repeat billing complaints | Recommend credits; approval above a set value |
In our own conversations with operators and telecom vendors, the requests that come up most are an agentic network operations centre, remote tower and radio management, and agents that run in a private cloud so network data does not leave the operator's estate. All three start from the same place: alarm and telemetry data that is already collected but not yet connected to a decision. Where agents take over incident handling, the work overlaps with AIOps for IT operations, and AgentSRE applies agentic AI to incident management and observability.
The short film below shows the alarm-triage pattern: thousands of alarms traced back to one change, with the evidence an engineer needs to approve the fix.
AI root cause analysis: an agent traces an alarm flood to a single change and hands the evidence to an approver.
What do TM Forum, 3GPP and GSMA say about autonomous networks and AI?
Three industry bodies give operators a shared scale for autonomy, a standard way to express goals to the network, and open models and benchmarks for telecom work.
| Body | What it provides | Why it matters for agents |
| TM Forum | Autonomous network (AN) levels "from Level 0 to Level 5, from manual management to fully Autonomous Networks", with an evaluation method in IG1252. TM Forum notes that many operators have set a strategic goal of Level 4, "which requires intelligent automation using AI". | Gives a common scale for how much an agent may decide alone, domain by domain |
| 3GPP SA5 | Intent driven management (TS 28.312), where an intent states expectations to the network "without specifying how to achieve them", across Releases 17, 18 and 19 | Lets an agent express goals to network management systems in a standard form instead of vendor-specific scripts |
| 3GPP SA5 | AI/ML management (TS 28.105) with a workflow of training, optional emulation, deployment and inference | Sets out how models used by agents are trained, tested and put into service in a managed way |
| GSMA | Open Telco AI, launched on 2 March 2026: open telecom models, datasets, compute access, a leaderboard of seven telecom benchmarks, and community challenges including an Agentic Challenge | Gives operators a way to test whether a model is good enough for telecom tasks before an agent relies on it |
Two points from these sources are worth noting for planning. GSMA states that frontier models "continue to underperform on telecom specific tasks", and, citing GSMA Intelligence, that only 16% of telecom generative AI deployments have been applied to network operations. Most current work sits in customer care and back office, so network agents need telecom-tuned models and evaluation before they are trusted with changes. Autonomy claims are also now assessed: TM Forum's AN levels evaluation tool (GB1059 ANLET) reached version 1.10 in January 2026, though TM Forum notes that validation does not certify a network performs at the claimed level.
What does a reference architecture for telecom agents look like?
A workable design separates five layers so each can be governed on its own; agents should never reach network elements without the context, policy and approval layers in between.
- Data sources: network performance KPIs and alarms, topology and inventory, change records, call detail records, CRM and support tickets, billing and rating data.
- Context layer: joins those sources into one governed view of network, service and customer, with lineage, so every agent works from the same facts.
- Orchestrator agent: receives a goal or an event, breaks it into tasks, assigns them to specialised agents, and resolves conflicts between them, for example when a network fix would breach a customer SLA.
- Specialised agents: network optimisation, fault triage, customer experience, fraud detection, billing assurance and reporting agents, each with its own tools and permissions.
- Policy, approval and observability: decision boundaries, human approval for risky actions, a trace of every decision, and rollback.
The orchestrator is where intent-based management fits naturally: a goal such as "restore service in this cluster without breaching enterprise SLAs" can be passed down as an intent, while specialised agents work out how. Tying agent actions to service level agreements keeps the trade-offs visible. For the context layer, ElixirData Context OS keeps governed context, versioned policy and decision traces in one decision layer above AI agents.
How should operators govern security, risk and cost?
An agent that can change a live network or a customer's bill needs stronger controls than an assistant that only answers questions.
| Risk | Control |
| An agent applies a change that causes an outage | Decision boundaries by action type and network domain; dry run or impact check first; tested rollback; human approval above a risk threshold |
| Agents act on stale or conflicting data | One governed context layer with lineage; agents refuse to act when inputs are missing or out of date |
| No one can explain why an action was taken | A decision trace for every action: inputs, policy applied, options considered, approver and outcome |
| Over-privileged agent credentials | Least-privilege tool access per agent; separate read and write permissions; short-lived credentials |
| Customer data exposure and privacy breaches | Data minimisation, masking and residency controls; private-cloud or on-premises deployment where regulation requires it |
| Model costs outgrow value | Use small or telecom-tuned models for routine steps, cache context, and track cost per resolved case against the manual baseline |
Deployment location is often decided by data and latency rather than preference. Agents that act on radio and edge sites may need to run close to the network; NexaStack is an agentic operating platform for physical AI that runs across on-premises, cloud and hybrid environments. For background on edge placement, see our guide to edge computing with 5G.
Which operators are already using AI agents?
Public detail is still thin, and many figures quoted online cannot be traced to the operators. These examples use only what the operators or GSMA publish.
- Vodafone Australia, TOBi: Vodafone describes TOBi as its My Vodafone chat bot, available around the clock in the app. It answers common questions, processes simple requests and connects customers with a team member for complex queries, the hand-over pattern any customer-care agent needs.
- Reliance Jio, Jio Brain: Jio presents Jio Brain as a distributed machine learning platform that can train and apply ML at the network edge and in the service provider cloud, the kind of foundation network agents depend on.
- AT&T and other GSMA members: AT&T contributed a family of open-weight telecom models to GSMA's Open Telco AI, alongside contributions from vendors and universities, so that operators can test telecom-grade models before building agents on them.
XenonStack's autonomous operations for telecom page sets out the network, customer service and maintenance workflows we support.
How should a telecom operator adopt agentic AI?
- Pick one decision, not one technology. Choose a workflow with clear data and a measurable outcome, such as alarm triage in one domain or a single billing dispute type.
- Map the decision. Record who decides today, on what data and policy, and what a wrong decision costs.
- Connect and govern the data. Bring the needed OSS, BSS and CRM data into one context layer with lineage before any agent acts.
- Start at "recommend". Let the agent propose actions while engineers approve, and measure how often its proposals are accepted.
- Raise autonomy by action type. Allow the agent to act alone only for low-risk, reversible actions with a proven acceptance rate, and use TM Forum's AN levels to describe the target for each domain. Add further agents under one orchestration and policy layer, not separate bots per team.
To build and run those agents, ElixirClaw is an agentic OS platform to build, orchestrate and govern AI agents and automation workflows while keeping humans in control.
When is agentic AI the wrong choice?
- The procedure never varies. If a fixed script handles every case, an agent adds cost and risk without benefit.
- The data is not there. Without reliable inventory, topology and change records, an agent will reason confidently from wrong facts. Fix the data first.
- Actions cannot be reversed or checked. Keep a person in the loop for changes with wide blast radius until rollback and impact checks exist.
How does XenonStack support agentic AI in telecom?
Telecom agents need a governed view of network, service and customer, and clear limits on what they may change. ElixirData Context OS provides the first, ElixirClaw the second, and NexaStack covers agents that must run on-premises or at the edge.
To map one network or customer decision your agents should make, and the data and policy it depends on, book a Context Workshop. See what happens in the workshop.
Related on XenonStack
- Agentic AI for telecom: network and service operations with agents.
- ElixirClaw: run governed AI agents with decision boundaries and human approvals.
- NexaStack: agent runtime and inference for private cloud, on-prem and edge.
Frequently asked questions
What is agentic AI in telecom?
It is the use of AI agents that read network, service and customer data, decide what to do, and act inside limits the operator sets, such as triaging alarms, applying approved fixes, resolving customer requests and flagging fraud.
How is agentic AI different from traditional telecom automation?
Traditional automation runs fixed steps for known conditions. An agent works towards a goal, plans multi-step work across OSS, BSS and CRM systems, checks the result, and hands decisions outside its authority to a person.
What are TM Forum autonomous network levels?
TM Forum classifies autonomous networks from Level 0 to Level 5, from manual management to fully autonomous networks. Many operators have set Level 4 as a strategic goal, which TM Forum says requires intelligent automation using AI.
What are the best first use cases for AI agents in telecom?
Good first use cases have existing data, a measurable outcome and reversible actions: alarm correlation and fault triage, routine customer service requests, fraud case handling and billing dispute analysis.
Does agentic AI replace network operations teams?
No. Agents take on routine monitoring, diagnosis and low-risk fixes, while engineers set the limits, approve higher-risk changes and handle exceptions.
How should an operator govern AI agents?
Set decision boundaries by action type and domain, give each agent least-privilege access, keep a decision trace for every action, require human approval above a risk threshold, and make sure every change can be rolled back.
Follow XenonStack on LinkedIn: XenonStack on LinkedIn for new guides on agentic AI, data and platform engineering.
Explore the XenonStack platform family: ElixirData · ElixirClaw · ElixirHub · NexaStack · MetaSecure · Neural AI · AgentGRC · AgentSRE · AgentAnalyst · AgentInstruct · AgentRAI · AgentScrum · AgentSearch · AgentForce · AI Aviator · SAIF Aviator · CohortIQ · XenonStack AI · XenonStack UAE
