Agentic SMO: Why Your Next rApp Should Build Itself

I recently joined the Telecom Infra Project for an episode of their Signal Boost podcast, talking about how rApps are moving from promising prototypes to production assets on live networks. One line from that conversation has stayed with me, because it summarises almost everything we have learned at Zinkworks: building an rApp is about 20% of the problem. The other 80% is everything that comes after. Before delving into that larger piece of the effort, I want you to consider a future scenario.

Imagine a network that no longer waits for an engineer to write the rApp. The network itself sets the intent, for example, “protect my user’s QoE while cutting energy in this cluster overnight,” and an agent builds, tests, and deploys the rApp that delivers it. No ticket. No sprint. No six-week integration cycle.

That is not where the market is today. But it is closer than most operators think, and the decision you make about your SMO tooling will determine whether you are ready for it. We call the destination Agentic SMO. As far as we can tell, almost nobody in the industry is using that term yet. That is exactly why operators should be thinking about it now.

The problem with how rApps get built today: 3 hurdles to navigate

Most operators running a RAN have the same experience with rApps. Building one is hard, and what exists in the market typically only helps them with the first challenge – creating a prototype rApp application. A vendor hands you a fast way to generate an rApp, you get something working in a lab, but then the real work has to start: testing it against production conditions, integrating it with your SMO, deploying it without breaking anything else, and governing it once it is live.

That last stretch is where most rApp initiatives stall. The build was never the bottleneck. The bottleneck is everything that turns a working prototype into production assets you can trust on a live network serving millions of subscribers. The tooling that only optimises for rapid build alone is leaving the operators to solve the hard 80% on their own.

There is a second blocker, and it is organisational. Your engineers already know what should be automated. They live with the congestion, the energy waste, the coverage gaps. But knowing the problem and being able to ship the rApp are two different things. Today the path from idea to deployed rApp runs through vendors, systems integrators, and procurement cycles. By the time the rApp arrives, the network has moved on. The people closest to the problem are the furthest from the means to solve it.

Finally, there is a third obstacle, and it is architectural. Once you attach an rApp capability that’s tied to a single SMO stack, you have made a procurement decision that constrains every decision after that point. But your network is continuously evolving, and the SMO landscape is moving with it. Your rApps must be able to dynamically adapt to the changes everywhere: equipment updates, user behaviour, economic conditions – these and many other factors all have an influence on your automation strategy.

A different approach: the full rApp lifecycle

Zinkworks built rApp Studio to address the whole problem, not just the build step. The Studio takes an operator through five pillars: Build, Train, Validate, Deploy, and Govern.

• Build is where domain knowledge becomes software. The engineers who live with congestion, energy waste and coverage gaps design the rApp directly, rather than passing requirements through vendors and integration cycles. The build environment does the heavy lifting so that engineers can focus on the network intelligence itself.
• Train grounds the model in reality. An rApp learns from real network data and operational patterns, not laboratory conditions alone, so that its algorithms reflect how the network actually behaves — across vendors, regions and traffic profiles. Managing that training data with the same rigour as the code is what keeps models honest over time.
• Validate is where trust is earned. Before an rApp touches a live cell, it is exercised against realistic scenarios and non-vendor-specific benchmarks, including frameworks of the kind TIP’s RAN Intelligence and Automation group is developing. Validation catches the handover cascade before it happens, not afterwards.
• Deploy keeps the operator in control of their architecture. Our tooling is SMO-agnostic by design: an rApp built, trained and validated with Zinkworks can ship into any compliant SMO without a bespoke integration project. As the SMO layer evolves over the next few years, the operator’s investment will survive that evolution.
• Governance closes the loop on outcomes. Every deployed rApp remains observable, versioned and auditable, with rollback mechanisms ready for the moment the network surprises you. Governance is what turns a clever automation into an accountable one.

These five pillars are what makes our offering enterprise-grade rather than just proof-of-concept. It is engineered for deployment at scale and for ongoing governance, which is precisely the part competitors tend to skip. Many vendors in this space, including the rapid-AI-app style players, focus on quick-build-wins with little governance framework around it. Our scope is broader and our governance posture is more mature.

The point of putting the whole lifecycle in one place is who gets to use it. Your domain experts build directly. No vendor, no systems integrator, no procurement cycle standing between the idea and the deployed rApp. The engineer who understands the congestion problem is the same person who builds, trains, and ships the rApp that fixes it.

Proof, not theory: The rApp Lifecycle in the real world

This is not simply a slideware story. rApp Studio has been validated in Vodafone’s RAN innovation programme. Vodafone’s Network Innovation team used the Studio in their Rapid RIC to define workflows, train models, and package deployable rApps, compressing what normally took multiple specialists and handovers into a single repeatable process. The headline outcome: 10 times faster time-to-value, with the path from idea to deployed rApp measured in under a week rather than months. Just as important, Vodafone needed to retain their own in-house rApp development capability, not to have dependencies on outside teams.

Vodafone’s ambition has been achieved precisely because of our five lifecycle pillars. When the training environment is pre-integrated, the validation framework already in place and deployment and governance designed in rather than bolted on, an enormous amount of repetitive engineering disappears.

The automation products coming through the programme target the problems operators care most about — and they show how automation complexity is being handled at scale:

• RAN Energy Saving. Switching off capacity layers in quiet periods is an old idea from the SON era. The intelligence to do it well is not: predicting traffic demand reliably, managing the handover implications of shutting down cells, and balancing energy gains against QoS commitments. The rApp is trained on real traffic patterns, validated against representative scenarios and governed with proper rollback, it becomes the ideal first step on the autonomy ladder.
• Congestion Management. Identify congestion on a cell, examine its neighbours, and intelligently steer traffic to the best target. Neighbour relations and handover optimisation are a different class of problem from energy saving — they are about the mobility experience — yet the same lifecycle applies.
• QoS Slice Automation. Maintaining quality-of-service targets across network slices while respecting competing objectives, such as energy consumption, is where individual optimisations begin to interact — a preview of the intent-driven world to be discussed below.
• Anomaly Detection and Root Cause Analysis. Spotting abnormal behaviour and tracing it to its origin, key use cases TIP’s operator community has also shortlisted for commercial deployment.

Each new use case stresses the lifecycle differently, and that is the point: the pillars are the constant, the problems are the variables, the answer is delivered through the rApp Studio.

Where this is heading: Agentic SMO

Here is the part that matters for your strategy over the next 12 to 18 months.

rApp Studio today is a build-and-lifecycle environment, and it is aligned to deliver intent-driven, closed-loop, self-healing automation in the RAN domain. The human engineer sets the direction, and the Studio handles design, code generation, packaging, simulation, and live assurance as a governed flow. It’s a high bar, and it’s where the product sits now.

But remember the scenario I introduced at the start. Take the next logical step and remove that operator or engineer from the inner loop entirely. Agents create rApps directly from network intent, static or dynamic, build them, validate them, and deploy them under governance. That is full autonomy. The operator no longer commissions rApps one at a time. The operator expresses intent, and the network produces the rApps to satisfy it.

Notice what the agents are reasoning over: rApps. This is perhaps where there’s confusion today in the agentic conversation. AI agents do not replace rApps, any more than a conductor replaces an orchestra. The rApps remain the governed, validated units of automation; the agents supplement the lifecycle around them, by selecting, sequencing and tuning them against the intent.

That is our vision for Agentic SMO. It is the merging of today’s SMO with an agent-driven layer that closes the loop from intent to deployed rApp. The industry has not coined this term, and the convergence it describes is a real gap in the market conversation. Traditional SMO and agentic approaches are usually framed as a choice or either one or the other. They are not; they converge.

This is why the SMO decision in front of you right now is not a small one. Many CSPs are unsure whether to invest in SMO at all, now that agentic approaches are emerging on the horizon. That is why the five pillars Zinkworks has created matter even more in an agentic future. If an agent is to create, adapt or deploy automation autonomously, it needs a secure and stable platform for rApp design and build underneath it. It needs a governed lifecycle to operate within, the freedom to deploy to any SMO rather than one vendor’s, and a validation layer that catches its mistakes before they ever reach a live network. Advanced AI reasoning is only as safe as the structure it stands on.

The operators who start thinking about Agentic SMO now will not be the ones scrambling to retrofit it later. They will be the ones who quietly built on the right foundation while others still debate whether to invest in SMO at all.

What this means for you

The operators investing now in a disciplined automation lifecycle are the ones who will be ready when the agentic layer matures. They will have the validation evidence, the governance models and the operational confidence to start letting agents take the wheel, while everyone else is still trying to resolve their trust challenges.

If you run a RAN, the value proposition is straightforward. rApp Studio gives you the full rApp lifecycle: Build, Train, Validate, Deploy, and Govern. It is SMO agnostic, so you avoid lock-in and keep your architecture open. And it is the foundation for Agentic SMO, the converged future where agents build rApps directly from network intent and you move toward autonomous operations without a forced discontinuity.

Those are the three things that separate this from a build-only tool: lifecycle completeness, SMO independence, and a credible path to agentic operations.

If you want to understand what Agentic SMO means for your network, and what to put in place now so you are ready for it, get in touch with the Zinkworks team. We would welcome the conversation.

You can hear this story firsthand. Come and find Zinkworks at DTW Ignite 2026 in Copenhagen, and listen to the full discussion on the TIP podcast on YouTube or Spotify.