Author
James McNamaraVP of Product
"*" indicates required fields
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.
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.
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.
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.
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.
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.