Agents Reason, rApps Act: 6 Principles for Governed AI in Open RAN

In our first blog, The Governance Gap Holding Operators Back from Level 4 Autonomy, explained why the move beyond Level 3 is as much a governance challenge as a technical one, and why autonomy has to be earned in stages. In the second blog, RAN Autonomy FAQ: The Five-Tier Path to Governed Autonomy, set out what those stages look like in practice: five tiers of RAN use cases, from observe and explain to evolving the automation itself, each with a matching step up in controls.

Both pieces arrived at the same rule: no agent ever gets a write path of its own. This article explains the architecture that makes that rule real, through six principles for governed autonomy in the RAN and five questions to ask any supplier who says their agents are ready to run your network.

The One Sentence that Matters

If you only take one thing from this piece, take this – Agents Reason, rApps Act.

Large language model-based agents are some of the best tool we have ever had for reasoning over messy operational data: alarms, tickets, KPIs, topology, SLA context, the engineer’s own runbooks. They are also non-deterministic, hard to certify, and impossible to hold accountable in the way a regulator or a board expects.

Certified rApps are the opposite. They are deterministic, testable, badged against the O-RAN R1 interface, and they already sit on the approved control path into the network.

So, the architecture writes itself. Agents supply the reasoning. Certified rApps perform the closed-loop network control. The certified O-RAN control path, R1 to the SMO to O1, is kept out of and there are no second, ungoverned write paths for an agent to discover.

Why the Regulator Will Ask the Same Question

This is not only an engineering preference. Under the EU AI Act, AI used as a safety component in the management and operation of critical digital infrastructure is classed as high-risk, with obligations around risk management, logging, human oversight, accuracy and robustness. The Commission’s draft guidance keeps routine network optimisation and load prediction out of that category for now. But every rung up the autonomy ladder moves a system from optimising the network towards operating it, and the burden of showing which side of that line you are on sits with the operator. An operator that lets an agent write directly to the RAN will, sooner or later, have to explain to someone why it did.

The architecture below is designed so that the explanation is easy.

Six Principles

1. One audited control-plane boundary. Every action that can change the network passes through a single boundary. The boundary is policed deny by default: nothing is allowed unless policy explicitly allows it. Human gates sit at that boundary where policy requires them, and nowhere else.
2. Agents never access a direct path to the network. Agents reason over the RAN data lake, propose, and act only through rApps and through the Studio. They do not have credentials to the SMO, to the O1 interface, or to any element manager. If an agent is compromised, hijacked or simply wrong, the blast radius is bounded by what the rApp it called is certified to do.
3. Intent-traced, immutable audit. Every action is written to an immutable audit trail and linked back to the intent that caused it. Not just “cell X was put to sleep at 02:14”, but which objective, which reasoning step, which policy check and which rApp produced that change. The audit record is evidence for the board and for the regulator, and it is what makes replay possible.
4. Every loop replays end to end. An engineer can take any closed loop that ran last night and replay it: what the system observed, what it concluded, what it was allowed to do, what it did, and what the network did next. Trust is built by replay, not by assurance slides.
5. Autonomy is a dial, set by policy. The same system runs supervised at Level 3 and Level 4 and unattended within guardrails at Level 4+. The difference is the approval policy, nothing else. Operators turn the dial up as evidence accumulates, per use case, per region, per time of day, and can turn it straight back down.
6. Your models, your data, your rules. Operator-defined small language models can run inside the operator’s own trust boundary, grounded on the operator’s own data and runbooks. Reasoning about a national network is sovereign work.

What this Looks Like in Practice

In our rApp Studio, the six principles are not a policy document. They are the product.

rApp Studio is a no-code, SMO-portable environment where operator engineers design, train, validate and package rApps in days instead of three to six months of specialist handoffs. rApp Studio allows operators to preserve their intelligence and automation across SMOs and across vendors.

That same Studio is the governed route to evolve the automation. The rApp Studio Agent Edition adds an intent-led agent layer on top. Agents continuously reason over the RAN data lake and act only through rApps and the Studio, under the operator’s defined policies. Intent in, action out, with no parameter engineering.

Five Questions to Ask Any Supplier

If a supplier tells you their agents are ready to run your network, ask these five questions. The answers will tell you whether the architecture above is real or a diagram.

1. Through which interface does your agent change the network, and is there any path that bypasses the certified rApp and R1 route?
2. For any single action, can you trace the audit record back to the intent that caused it?
3. If I asked you to replay last night’s loop end to end, could you?
4. How do I move one use case from supervised to unattended, and back? Is it a policy change or a software release?
5. Whose model is reasoning about my network, where does it run, and what was it trained on?

In the final piece of this series, James McNamara will bring the principles together: three live closed loops on one architecture, built with our research and industry partners, running on our stand at FYUZ 2026.

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 to book a demo.