Skip to content
29 Oct, 2026

RAN Autonomy FAQ: The Five-Tier Path to Governed Autonomy

Industry Telecoms

In our last article, The Governance Gap Holding Operators Back from Level 4 Autonomy, Michael Behan explained why moving beyond Level 3 is as much a governance challenge as a technical one, and why autonomy has to be earned in stages. This piece sets out what those stages look like in practice: five tiers of RAN use cases, and the controls each one needs.

Where this Ends Up

Let us be clear about our network automation journey. Within the next few years, we expect most RAN operations will run autonomously: intent in, action out, closed loops that monitor, diagnose, change, measure and repeat without a person constantly pressing buttons for routine work. That is TM Forum Level 5, and nearly every operator we work with has it somewhere on their roadmap.

We also want to be clear about what that does not mean. It does not mean “closed loop, remove the humans”. It means autonomy built properly, with guardrails engineered into the system and with the operator always holding the final say. It means that human approval is reserved for the genuine edge cases rather than the ninety percent of decisions that are business as usual. Nobody should wake up to find that six sites were switched off overnight because an agent decided it would save energy. Equally, nobody should have to press a button to approve a decision that your policy already covers.

That balance is what we mean by governed autonomy, and it is the thread that runs through everything below.

Five Tiers, One Principle

The principle is simple: every step up in your autonomy journey should bring a matching step up in intelligence, security and policy controls. Applied to RAN operations, that gives a hierarchy of five tiers.

Tier 1. Observe and Explain. The system watches the network and tells you what is happening and why. Anomaly detection, root cause explanation, KPI narratives in plain language. No write access to the network. Control required: data access policy and explainability.

Tier 2. Recommend. The system proposes a change and a person executes it. Energy-saving recommendations, parameter proposals, ticket enrichment. Control required: a recommendation record, so that every proposal can be reviewed and scored for accuracy before anyone trusts it further.

Tier 3. Act within Fixed Policy (supervised). The system executes a defined, deterministic rApp inside pre-approved bounds, with a human gate where policy requires one. Control required: an audited control-plane boundary, deny by default, with every action traced back to the intent that triggered it.

Tier 4. Act on Prediction and Intent (supervised to unattended). The system acts before degradation happens, on a predictive model, and increasingly on an operator-set intent rather than a hand-coded rule. Control required: the same boundary plus replay. Every loop must replay end to end so an engineer can see exactly what the system saw, decided and did.

Tier 5. Evolve the Automation. The system improves its own rApps: it proposes a better model, validates it against the simulator, and promotes it through the same governed path a human would use. Control required: everything above, plus the rule that no agent ever gets a write path of its own. Agents reason; certified rApps act.

Three things stay fixed across all five tiers:

  • The control path never changes. Whatever actor performs a decision, the action reaches the network through the same certified path, e.g. R1 to the SMO to O1. Nothing bypasses it.
  • Autonomy is a policy, not a product version. Moving from supervised to unattended is a change to the approval policy, not a change to the software. The dial turns up as trust is earned, and it turns back down just as easily.
  • Each tier is measurable. Accuracy of recommendations, mean time to remediation, share of actions that needed a human gate, replay success. If you cannot measure it, you cannot earn the next rung.

Multiple Entry Points, One Path

The reason we built the hierarchy this way is practical. Operators are at different levels of maturity, and a credible path has to meet each of them where they are.

An operator starting out can begin with a deterministic rApp built in our rApp Studio: automation you control, live in days, working across a multi-vendor radio estate so that you are not locked to any single equipment supplier. One engineer, one or two use cases, measurable results. And built by that engineer, not generated for them: the logic is theirs to inspect, version, test against the SMO simulator and own.

An operator that is further along uses rApp Studio to manage a portfolio of rApps, and to take the pain out of the whole lifecycle: not only building the rApp but integrating, testing, packaging and operationalising it across several SMO targets without rip and replace.

An operator ready for the top of the ladder moves to the rApp Studio Agent Edition, where an operations owner sets the objective and governed agents work the loop: monitoring, root cause, change management, implementation, measurement, repeat.

The point is that these are modules on one platform, not three separate purchases. What you build at Tier 3 is what the agents act through at Tier 5. The money an operator spends on automation today is an investment that carries forward, not a project that gets replaced.

Built for the Scale of a Group

One last design choice is worth stating. We built rApp Studio for the complexity of large operators and operator groups: many countries, many vendors, many SMO targets, hundreds of rApps to supervise at once. That is the environment our engineers have delivered AI at scale in, with Tier 1 operators in the UK, Spain and across Europe, and it is the environment the hierarchy above has to survive.

In the next piece, Michael Behan sets out the six architecture principles that make this possible and the five questions to ask any supplier who tells you their agents are ready to run your network.

Attending FYUZ 2026 in Seattle, 3 to 5 November? Meet us at stand #14 to see how rApp Studio takes a use case from idea to live automation in days, and how governed agents act only through certified rApps or book a demo.

Author
James McNamara
VP of Product

FAQs

01 How do operators close the governance gap between Level 3 and Level 4 autonomy?

Operators close the governance gap by earning autonomy in stages, with every increase in what the system may decide matched by stronger controls. In The Governance Gap Holding Operators Back from Level 4 Autonomy, Michael Behan explains why moving beyond Level 3 is a governance challenge as much as a technical one. Zinkworks’ five-tier hierarchy sets out the practical path from there, from observe and explain at Tier 1 through to TM Forum Level 5, where the system evolves its own automation within operator-defined policy.

02 How does Zinkworks put governed autonomy into practice?
03 Does full RAN autonomy mean removing humans from the loop?
04 What are the five tiers of RAN autonomy?
05 Can AI agents make changes to the network directly?
06 Where should an operator start on the path to RAN autonomy?
07 Does Zinkworks support multi-vendor RAN environments?
08 Will investment in automation today need to be replaced later?