Turning autonomy into margin: Agentic AI and the autonomous RAN
Discover a practical framework for prioritizing RAN automation based on measurable margin impact, and gain a clear perspective on how agentic AI fits into a realistic, results-oriented roadmap.
Hi. Welcome to our webinar on turning autonomy into margin, which is gonna focus on, autonomous RAN and creating value from network autonomy within the RAN. I'm Phil Laidlap. I will be taking you through the session today. So welcome. First up, I guess, just to take you through the agenda, what we've got planned for you today. We're gonna do some brief introductions, take you through those of who are not familiar with our webinar platform, take you through that. And then my colleague, Kirsten, is gonna share presentation based on the research we've undertaken. And then our sponsor, Amdocs, is gonna share their thoughts and what they're seeing in terms of adoption pathways related to RAN autonomy. Then we've got a great panel. They're gonna take questions hopefully from yourselves, the audience, and then wrap that up at the end of the hour. So very briefly, the next slide, if I could just take you through the the audience for two of the speakers today. I've introduced them already. That's myself, it's Kirsten. Neil from Amdocs is going to have a short presentation, and then we'll be joined by Darwin and Perjay. I'm grateful for them to take part in the panel. Now in terms of your using of this platform, you're all on listen only mode. And we do want you, if you've got questions or comments, to use, the dashboard that you've got up here. You will be muted, but we'd like, the audience to submit questions to the panelists, and there's a little question section for you to do that. I will try and get through your questions. If we're not able to get through your questions during the session, we'll get back to you after the sessions, and we'll share both the questions and our responses to all those who are joining. You don't need to take screenshots because this will be recorded and you'll have access to this recording. So so no need to do that. And we will send you copies of the slides after the session as well as the link for the recording. So that's everything for the setup today. And I will now hand over to our first speaker, Kirsten, who's going to share with you some of the highlights of our research on this subject. So welcome, Kirsten. Thanks, Phil. And thanks, everyone, for joining us. So in this opening presentation, we will discuss the current issues facing operators when it comes to automating the RAN, and then we'll introduce our new framework that helps operators drive towards a commercially successful and automated RAN. So without further ado, let's start our discussion with the current context and challenge. Operators face the challenge of working in an environment of prolonged revenue stagnation, increasing commoditization of connectivity, increased competition from other MNOs and eSIM players, and rising network cost and complexity. That tension is especially visible in the RAN. It remains the largest and most expensive network asset, so it is a central lever for both efficiency and differentiation. These pressures are pushing operators to find a strategic response. Operators have moved autonomy to the top of their agenda, setting explicit autonomy targets and aligning around the TM Forum autonomous networks framework. There has been the creation of a shared language, common maturity levels, and a clearer operational agenda for network teams. But there is also a clear execution gap for operators. Progress against technical autonomy targets has not consistently translated into material business impact. Autonomy initiatives often struggle to scale, remain concentrated in isolated operational domains, and are difficult to connect to commercial outcomes. Failing to consider both its commercial and technological opportunities from automating the RAN is a common trap for operators to fall into. Think of traditional horse transportation. When improving upon it, there are two potential paths. The first is to create the mechanical horse. It is more efficient, more reliable, and more automated, but it remains stuck in the past, a better commodity. For the RAN, this is a smarter, cheaper network, but one that will not be able to differentiate commercially. The second path when improving upon the traditional horse is to redefine the problem, creating the car. It is not just a better horse like before, but it has fundamentally changed the problem being solved. For operators, this means using autonomy to move towards an automated RAN that changes customer outcomes, offers differentiated services, and new revenue logics. After operators have decided to pursue autonomy, progress still often fragments. The issue is not whether they start with technology or with commercial ambition. It is whether they can keep the two aligned as autonomy extends across the RAN life cycle from planning and design through deployment, operations, and decommissioning. And as the role of the RAN shifts from cost center to differentiator and, ultimately, value creator. On the technology led path, capability runs ahead of demand. Operators build tooling, closed loops, architecture, but often in isolated parts of the life cycle. The result is stronger technical maturity, but weak monetization logic, abstract ROI, and a RAN that is still mainly treated as a cost base. On the commercial led path, on the other hand, ambition runs ahead of readiness. Differentiated offers and value creation goals are defined, but the life cycle foundations are not in place to support them at scale. So manual workarounds fill the gap. Delivery becomes fragile and expensive, and these offers become hard to industrialize. So the key takeaway here is that neither path is enough on its own. The real technical chat the real challenge is to move technical autonomy and commercial value creation forward together, so operators build life cycle wide capability while changing the commercial role of the RAN. This is why we created our new framework, which combines the two dimensions of commercial ambition and technical progress. The first axis measures technical autonomy maturity across the full RAN life cycle. The second axis measures value creation maturity, which captures how the economic role of the RAN evolves. Together, they create nine realistic states that operators can occupy now and as they progress with automation. When these two state dimensions are considered together, they explain why operators with similar technology stacks can have very different outcomes. The difference is often not the technology itself, but how well technical capability and commercial ambition are aligned. The framework is intended both as a diagnostic tool and to provide guidance for operators on how to achieve progress. The framework provides guidance on how to move towards the North Star RAN value creator estate. The most effective route is therefore a diagonal path where technical autonomy and commercial value creation advance in step over time. Operators will make the fastest progress towards this North Star when they keep commercial and technical aims in sync, recognizing the need to pivot when either aspect falls out of step. We'll explore each axis in more depth, starting with the technical. On the technical axis, we align closely to the TM Forum, where we extend the analysis across the full RAN lifecycle, planning and design, deployment, operations, and decommissioning. At the low level, automation is still fragmented and usually siloed. Humans remain firmly in control with some automation assisting repeatable tasks, but data does not travel cleanly across life cycle stages. In the middle stage, with limited technical autonomy, you start to see closed loops and defined tasks and more repeatable workflows, but autonomy is still narrow and bounded. Human oversight is critical to functionality and approval at this stage. In effect, there is a human in the loop automation. At the advanced stage, systems are increasingly driven by intent, policy, and shared data models across the life cycle, with humans intervening only as an exception. This is where agentic AI, simulation and digital twins become critical to operations because they help operators coordinate decisions across domains rather than automating one silo at a time. The second axis evaluates the commercial value of autonomy to the operator. At the first stage, the RAN is managed defensively as a cost center. Success is defined by coverage, uptime, and budget adherence, and network decisions remain largely disconnected from commercial outcomes. At the second stage, the RAN starts to become a differentiator, playing a more active role in shaping customer experience and retention. Operators use performance improvements to support premium positioning, differentiated service tiers, or experience based SLAs, even though monetization remains indirect and often constrained by silos between network and commercial functions. At the third stage, the model changes fundamentally, and the RAN is treated as a strategic asset and, crucially, a value creator. Network capabilities are exposed, packaged, and priced through outcome based services, APIs, marketplaces, or emerging RAN as a service models. At that point, the RAN becomes a platform for innovation, enabling faster experimentation, closer customer and partner co creation, and more responsive innovation cycles. Turning autonomy into margin means moving the RAN from an unavoidable infrastructure cost into a programmable platform that can support both efficiency and new value creation. Once the RAN is conceived of not just as a cost base, but as a programmable and trusted platform, operators unlock new abilities and choices to drive revenue growth. It is no longer only about efficiency, and autonomous RAN makes it faster and cheaper to develop and launch new services from Redcap and 5G LAN to offers that will emerge over time, and it makes it easier to cocreate with partners and customers. That is how autonomy starts to turn into margin by shortening innovation cycles as well as improving how the network runs. But what does that look like in practice? One example is revenue first network planning, where planning decisions and capacity planning are shaped by customer and revenue data, not just traditional coverage logic. Another is outcome based contracts, where operators are paid against delivered performance rather than just provisioned capacity. That starts to shift the commercial model, linking value more directly to measurable results and outcomes of the RAN. You can also see new wholesale models such as RAN as a service, which open up additional monetization routes beyond the traditional network business for new types of enterprises or services. For edge applications running on RAN infrastructure, creating opportunities to support new services closer to the user and strengthen differentiation. The fifth potential option is shared AI RAN infrastructure, supporting third party workloads, which starts to change the economics of delivery by allowing the platform to support a broader set of use cases. And even network as a sensor models, where the RAM becomes an intelligence layer as well as a connectivity layer. The RAM could sense, for example, hyper localized weather data, which could be monetized in combination with partners. Not every operator will pursue every path, and not all of these models are equally near term. But the point is that autonomy starts to matter very differently once it is tied to value creation rather than maturity scores alone. At that stage, it is no longer just about efficiency gains. It starts to influence top line growth, service differentiation, and delivery of economics. So with all of this now being said, we'd like to run a couple of polls to assess how operators are performing today. All results of our polls are anonymous, so please do answer honestly. You should now get an option to answer the poll on your screen. And so our first poll is describing the operator that you work for or know best in terms of its aspiration for run autonomy. So not what it's currently at, but what it's hoping to achieve. So option one is that run autonomy is pursued mainly to reduce operating costs, improve reliability and meet technical performance metrics. So very much just a cost saving measure rather than looking at improving revenue in the future. Option two is that run autonomy is pursued to both reduce operating costs and to optimize customer experience. So there is a goal of improving the customer experience, but there is an indirect monetization. Option three is that through RAN automation, we will transform our RAN ROI by reducing TCO across the RAN lifecycle and growing core revenues. So starting to get that value from the RAN there. And then option four is that the RAN automation will enable us to achieve core and new revenue growth. So really using the RAN to drive commercial success in the future. I'll just give everyone a few more seconds to answer that. Okay. And if we close that poll. Great. And then we have a second poll, which is then looking at what the operator you know best is has achieved or is currently achieving today. This is very much based on current performance, not aspiration. It's the same options there, one through four, with one being much more around that cost saving and four around really driving revenue growth. Very much today's actions rather than the goals. Let's give everyone a chance to answer that one too. Okay. So we will come back to these polls at the start of our panel discussion, both to see how operators are currently managing their RAN and what those goals are, and if there is a gap, what that gap is. So, yeah, we'll come back to those imminently. And so that's just to say our key message today here from STL is simple. RAN autonomy only delivers meaningful impact when technical progress and value creation advance together. That is how autonomy starts to move from an engineering project to creating business value. And with all of this framing in place, the next question is how Agentic AI can help operators make that shift in practice. For anyone who wants to go deeper into this topic after our session, we have a full written report on this topic that you can access by scanning the QR code currently on screen or by getting in touch with us after the session. We will now hear from Neil, a product manager at Amdocs, on how they have been finding this in their work. And so I will hand over to you now, Neil. Thank you, Kristen. Can you see my camera and hear me clearly? Yep. We've got you. Okay. Yes, thanks everyone. I think the things raised by sale partners in their paper have been really resonated with Amdocs and the customers that we've shared with it in advance. We've been very pleased to be able to work with SCL Partners on this briefing. I think what we see is it comes at a really opportune time in where the industry is and the crossroads that it sits on. So I'm going to run through a few slides. I won't take too much time but I'll talk a little bit about what the STL Partners framework and executive briefing means and how it's resonated with ourselves and our customers. I'll talk about the experiences that Amdocs has of what automation looks like today and how and where we see operators and what kind of areas they get stuck in. And then I'll go on to talk about how operators are looking to close some of those gaps and And I'll introduce some kind of high level case studies. And then I'll give a brief overview of what we're doing with Amdoc's aOS, our agentic operating system that is powering a lot of the work that we're doing in autonomous networks. If you go to the next slide. Okay. So just as kind of some background, I mean, Amdocs works with many a very large kind of collection of customers across BSS and OSS. And within in the network domain itself, we work with about over one hundred CSPs in a mixture of kind of services software to kind of take them on this journey of network automation. And like I said, I think from our vantage point of working with these customers and working across many other domains in the telco, I think the assertion that autonomy alone won't deliver the strategic and financial impact I think is correct. I think it feels that the industry is trying to in a way kind of bootstrap the business cases for automation. So we've seen over the last kind of twelve to eighteen months that autonomous networks has kind of bubbled further and further up the customer's priority list. It really does feel that now we're at that time where there's that appetite within operators to kind of systematically address automation. And as mentioned in the briefing, TMForum's autonomous network levels and the framework around that has really come at the right time to allow operators to kind of speak a common language. Certainly every engineering team that we work with and our internal engineering teams that are delivering services now use this as a benchmark. And I guess one of the benefits of the framework itself is it's kind of stripped away some of the domain details out of assessing automation levels. But I think one of the things that the challenges we've seen is that operators kind of need to break away from effectively building business tools around point automation. So be it Son, be it planning tools, and be it be it analytics and creating kind of small business cases. So it becomes less about business cases for kind of points of automation, but more kind of business approaches that necessitate automation to deliver some form of commercial value. So this has been a really powerful kind of paper for us. I think every customer that we've kind of shared it with, it resonates with. And it certainly provides a framework for how we're judging the kind of assessing and evaluating the maturity of automation approaches both for our customers but also also internally. So on to the next on to the next slide. That's great. So so what what does automation see today? So what are we seeing at at at customers? I I think to start with, I think people are starting to see what the end goal is. I think there's been alignment around what the end picture looks like in terms of run automation. And this is kind of I think I of like to call it apps and agents. So it's a combination of highly AI led, highly automated apps that automate aspects of the network coordinated by agents linking them together workflows. I think the emergence of the kind of non real time RIC and SMO architecture has provided that app framework that kind of enables these type of apps and agents approaches to work. But I think whereas the end goal is kind of known, I think operators are trying to work out how to get from where they are today to a place where the bulk of their automation is delivered on these platforms as well. From our customers, we see a lot of customers living with mature but kind of limited some platforms. Some of them actually delivered by us that maybe support a dozen use cases. And then they have hundreds of automations spread across tools across the lifecycle from kind of planning through to operation. And we also see a lot of unmet demand. Think in a lot of the conversations about network autonomy, see a lot of what's often missed out is the engineering teams in the field who have lots of little automations or bigger automations that they need to deliver, but they're under serviced and really want looking for self-service models. So I think the picture here is that there's a kind of growing realization at the endpoint and there's pockets of maturity but they're looking at paths of how to get them to that final stage. So if you go on to the next slide. Thank you. So I mean, we're helping customers take this kind of journey to this kind of apps and agents kind of approach. I'll give you some three very high level case studies. And the case studies, one talks about kind of tool consolidation, the other one is focused on more about the ability for these new architectures to support cross lifecycle automation. And finally, the final one is really about business intents. So some of the work that we're doing in the first example with the North American operator is helping them to consolidate automation down onto fewer and fewer platforms. And this has been a significant eye opener for us and the operator themselves because it ultimately shifts what were engineering processes into something that looks a lot more like software development. And all of this is assisted by agents that help take their existing automation and automation code and transform it into these new app based approaches. And I think this is starting to get to the point where you've got the scale and the capability to move into this engineering self-service model that I talked about earlier. Second, we're working with an APAC operator. And this is where we've taken these modern architectures and said, what if it's not just about operational and optimization use cases? What if we can kind of create new workflows in planning? And what we're doing here is using some of NVIDIA's powerful ray tracing capabilities and embedding that into apps and then ultimately into agents that can help in things like new site planning or economic site alternative or cell outage analysis. And this shows the example of these new architectures to bring in kind of new automation capabilities that further increase the number of apps that can be built. And then finally with the European operator, think this is really where we're getting into this kind of value based question even if it is only in the kind of more technical aspects of that value thing if that makes sense. And this is how do you capture intent and operational intents through agents and use those to drive automation in the radio access network. And I think all of these are kind of pointing towards this apps and agent led world and I think one of the kind of underpinning requirements to make this work is effectively a modular open and vendor independent approach to automation. So next slide. And so I guess this takes us on to the kind of Andox aOS, our agentic operating system for telco and very specifically in this case for autonomous networks. And really what we're looking to do here is to take all of this fantastic infrastructure that you may really have for automation and to harness in a way and to enable these powerful agentic workflows that sit on the top. So, yeah, aOS operates on existing BSS and OSS stacks it's effectively capable of sitting on both transformation work that we're doing within operators but also existing platforms that they may already have. I guess our cognitive core contains a lot of generative AI technology and some pre built specific telco agents that make it easier to build kind of the workflow agents that sit over the top of that. And I think on this kind of one of the things that aOS offers is this kind of cross domain coordination. Because we have visibility across the telco, it allows us to kind of span that kind of customer experience monetization and autonomous networks and starts to make those connections to help operators close that value gap. But I think one the key opportunities and challenges that telcos will face over the next two to three years is this process of agentification. So as the automation and the AI gets better at closing the loop on individual activities, I think the focus would definitely shift towards the agentification, so the creation of agents that embody workflows in the radio domain and across other domains. I think this is something that we're think we're really it's a really exciting journey to be on because I think almost for the first time, telcos are starting to embody kind of their intents and their processes into platforms and effectively out of the kind of implicit world where it currently sits. And we think it's a great opportunity for everyone. Okay. Thanks, Kristin. That's my final slide. Thank you, Neil. Thank you very much, Kirsten. Thank you, Kirsten, for sharing the insights and setting out, I guess, the challenge and Neil for sharing Amdocs' sort of set of proposed solutions to that problem. What I would like to do now is invite our panelists back, Arwit, Ajay. And just to kick things off, we're gonna show back because we didn't get to see the results of the poll. So we're gonna we're gonna have a look at the results of the poll. But meanwhile, please, audience, if you've got any questions to any of us here, please do submit them, using your control panel. We will try and get through the questions, but please do submit any questions you've got for our panelists. And and, in the meantime, let's have a look at those poll results. So we have two polls. One was which best describes your operator or an operation you know well, their aspirations. And here, the center of gravity somewhat focused more around reducing costs and optimizing customer experience. This is the aspiration with a few respondents saying, no. No. It's about new revenues and some pretty good split across the board. I wouldn't say it's quite even. Center of gravity is around that second. And then what's the what's the reality? In other words, how does that match up with the actual reality, which is the second poll? Let's see how different it is. Yeah. The reality is as expected, I think, that the focus in reality is a lot more on core costs and reliability KPIs, and less. So this isn't exactly a surprise, is it? If I could just get back and get the feedback from the panel on this, I guess it's not a surprise. Although, any anything in here that does surprise you, aside from yourself, Terje, anything in those results that you found surprising? Or is that pretty much what you'd expect? I would say thanks, Phil. I would say that it's not really surprising. So at least a lot of the operators we have in our group and also with other operating groups you're talking to are the RAN is there to be most efficient. And they are typically planned, and I mentioned a follow-up with the technical KPIs. Then we'll come back to, I guess, a bit later on that. There we see also that there are more creative discussions now on the on the RAN. We are using RAN also as a differentiator in many cases. So so we probably come back to that field, I guess, in the in later in the session. Yeah. So I'd be happy to see that, you know, for aspirations. There are a bit of shift, but I was expecting a bit higher shift towards the cost of experience, maybe even into revenue. So either maybe respondents aren't always as honest as we hope they'd be, or maybe the truth is that there is more alignment than we expected. So just get the input from from Darwin and and Neil. So Darwin, yourself, was that a surprise, or were you expecting a bigger shift like Perjee with a bigger difference between the aspiration and the actual? Yeah. I agree as well. No surprise on the current state. Recognize where we're at today and the challenges of moving forward. I expected to see higher aspirations, but when I saw that, it just rang with the realization of understanding of the actual use use cases that drive that monetization. You know, they're talked about, but from our perspective, we don't see the reality of them. And we're careful that we don't have a technical solution looking for problems to solve. Know, we really need to see those use cases and and enterprise customer needs. Right. And finally, Neil, you speak to a lot of operators, obviously. Was anything surprising that you'd call out on those two poll results? No. No. Not really. I think I think on the I think I think everyone else think the the aspiration side. Anonymous aspiration should be more aspirational, I think. You've got to be dead to do. But I think it does definitely line up. I think there's this kind of perpetual hump in the industry where it is make the network more efficient than make it slightly more customer friendly. And I think until we kind of break that hump, the discussions on this kind of value based and commercialization are going to be more are going to be difficult. So it's kind of making these baby step movements so you can effectively use automation to drive better customer experiences feels like a good starting point. Okay. Well, thanks for that. Some questions have started coming in. But ahead of those questions, I've got a couple of questions, which I'm gonna put to you. We we talked a little bit about the the the way that RAN automation or autonomy is is being pursued across the life cycle, you know, planning and deployment optimization or even in retirement. And and we didn't talk too much about retirement, but there's obvious opportunities to introduce greater automation to extract value and reuse of equipment. Where do you think the biggest gaps are today? And I'll start with yourself, Darwin. So where do you think across the piece there are there are the the biggest gaps in execution from where we are to this this North Star autonomy. When I consider the types of operations that are in front of us for RAN, you know, the whole landscape of planning, deploying, maintaining, supporting, operating, upgrading, cutting over, decommissioning, right, there's a whole life cycle here. We see that there's really great things occurring in segments by our teams in those operations. But the biggest challenge that we see is having cohesion and integration across that end to end life cycle with automation. So we need to think of this as kind of a holistic approach and not just dwell on a single operation. That's probably the largest gap. Great. Thank you. And, Neil, I mean, what do you see? And you did mention, for example, a big gap in field support, but but which, I guess, would be potentially around both deployment and optimization. But where do you see the biggest potential gaps? So that's directed at myself. Yeah. Yeah. I think it's it's interesting because I think I think optimization is a long way and the operation is still a long way away from being it could have been being highly automated. But, you know, we do see kind of planning and and and deployment kind of lagging in the automation levels. And I think this kind of the comment from Darwin on the kind of the holistic approach is kind of key because I think it's very tempting to buy to look for point levels of automation in planning and deployment and optimization and retirement but then you end up you've kind of back up where you've got fragmented tools for each of them. And I think the very act of trying to bring these capabilities together, you know, maybe rationalizing the platforms or putting agent layers on the top, you know, the act the very act of bringing those together, I think, will open up new types of automations and new workflows within operators rather than swiveling from one activity to another. But we certainly do see kind of the planning and deployment side being slightly less cooked probably because they're one off processes and often. Okay. And I guess maybe a greenfield operator, that's a bigger deal because obviously they're having to get out of there whereas for existing operators, it's there's less focus on that. And if we look at the overall landscape of this challenge, this North Star, you know, level four, 5 automation and also commercial realization of value, how how should operators prioritize or sort of start to draw up a road map of where and how they automate first? What are the is there any guidance that you can offer? I'll start with yourself, Terje. And then guidance you can offer on on how do you go about just putting a plan together for this? I think just to challenge a bit, Neil, I guess. So we are typically looking into the what is the value or benefit versus what is the effort and risk. Risk. And that today tends to be into bit of a task driven automation. And, of course, the risk is the the that you end up with different tools and a bit of fragmented approach. And then, of course, it's gradually extending that that scope, I think. So so so so we are then, of course, doing the automation according to the needs of what we see as, call it, pain points or or value or or benefit in any any respect. We also and just a couple of examples maybe there. So so and just to challenge a bit maybe the poll result as well. You see, one of the one of the key benefit area is to automate the the customer care and trouble ticketing and that customer interactions, meaning that we are automated more than ninety five percent of the the old closed loop tasks there. So meaning more than 95% is automatically handled from the customer makes a contact until a feedback or the cases is sold and the feedback given to the customer. And then, of course, that's not only a cost efficiency, it's just as well as a customer experience. Not maybe on the network performance. Of course, it will also improve the network performance, but it's the whole customer experience engaging with us as a as a provider. So so not forget about you know, it's not only about about the speed and the or latency and and speed, but it's also the engagement with with the customer in totality. So customer care is definitely one of the areas we have seen it's it's also have been a pain point in in the in many of the operations. Then it was network network operations, root cause, and resolving those as the as the RAM in particular gets more complex with the two g, four g, 5G, lot of parameters to be tuned, automatically tuned, and so forth. And if there are any any incidents there, for example, power outages or or whatever. So that needs to also be to be to be automated. And, again, the the there is an speed and the all the resolving issue, but it's also a customer experience in totality, which is which is driving this. So so both the operational efficiency or operational quality, if you want, the customer customer facing interactions are typically part of the automation area what we are looking into. So and yeah. And yeah. Maybe I should just mention that maybe also challenging a few of the others. We have automated quite a lot on the on the planning side. And we are I would claim we are quite far into, I think, what Christian referred to as revenue driven, you know, planning, meaning that we are earlier in earlier days, we called it smart CapEx. But these days, yeah, we are a bit more general. So we say that, okay. You could consider, you know, the the the potential revenue and also the customer experience when you decide changes, improvements in the round area. So that's kind of the the it's it's has given quite a big, you know, return on on on being that because that's not only a one off. It's also a continuous planning. Yeah. And because you need to track the progress. You need track the changes in the in the revenue so on and so forth. And you need to run through the a number of scenarios because you are planning for the future, meaning that you don't have data, and you just have to speculate on some of these these trends. So there there's need to automate quite a few of the of the planning tasks. But again, Phil, back to the question, we are we are prioritizing, you know, according to the value benefit versus the effort and risk. And that's the simple formula without giving you an absolute answer, what does it mean in practice. Yes. Although you have given us specific examples of when and how, and that comes back to this. And, I mean and and then just coming on to next question, which I'm gonna pose to Darwin, which is we we listed sorry. Kirsten listed some kind of revenue opportunities that could be we believe could be derived through greater automation directly or directly. But that included things like revenue first planning that Jay has mentioned, outcome based contracts, brand as a service, network as a sensor, AI ran infrastructure. Which of these do you think are potentially more viable and and another that we may not have listed? And and which do you see as probably a little more speculative? So I'll start with that question kind of by spanning from the previous question of where do you start. And this moves on to the area of value is, I'd say we really need to assess and have a good understanding of our challenges, problems, needs, opportunities so that we have a clear understanding of where we're headed and why. And so that defines the value. And by targeting that value, we can demonstrate our success. We can show our return on investment, and it should allow us to gain momentum to further this progression. In thinking about these areas of, you know, possible monetization from autonomous RAN. And we see things today, RAN as a service with Molchan arrangements between service providers, like multiple core operator networks. So today, we're engaged with partners to deliver wireless services across multiple carriers in our territory, opportunities with private wireless networks, and even using RAN as an infrastructure. Go ahead, Phil. No. No. No. It's great that you're talking about private because that's actually one of the questions we have from the audience. So I I encourage you to keep means that we've addressed that question indefinitely, which is great. Yeah. So maybe I'll just add on a private is, again, with that, we've seen lots of in the industry, but in our local territory, it's a little bit more challenging with the customers. The customers are very much on driving their own business and how to meet those challenge. And there's unique industries like mining, for example, that are more interested in the private network opportunities. But even with them, we're we're finding that traction to get momentum to fulfill those needs is is challenging. When I look at the concept of revenue first planning, That's a little bit more tricky because already we're driven by subscribers to have connectivity, service everywhere, performance, strong data feeds. And within our organization, South Tel in the province of Saskatchewan, we're driven to provide that coverage capacity and performance and because of our ownership is the provincial government, we don't see opportunities of selling tiers. We need to serve everybody more homogeneously. Network as a sensor. We see that as kind of speculative, but we see that there's interest there with with capabilities that are directly tied to the RAN and the edge resources. So even though that may be further out, I think there's future opportunities. So keep a watch on that one. Third party AI RAN applications. Again, speculative. Sounds like there's significant opportunities. I guess we'll wait and see. It's really gonna be predicated on market need. You know, the problems and opportunities trying are gonna evolve. So, again, careful with the build it, and they will come. So we'll we'll pay attention to that. Technologies don't always solve all our problems, and so we don't need to treat it that way. We really need to be attuned to what are what's the market and customer needs, where's the real value, chase that real value. Okay. Thank you. I'm gonna try and get some of these questions from the audience and post them to you. Neil, there's a question here. I think it's kind of interesting, and I know it's a topic that's front of mind. It's and it's our operators that are exploring our apps and AI. Are they building on traditional RAN solutions, something that's RIC like, or on top of O RAN architecture? So I guess the question is That's good. Yeah. Yeah. That's a that's a really good question. I I I think I think one thing we've said very specifically in that kind of our app side of the house, think a lot of operators are seeing the more legacy platforms as just being a little bit as kind of effectively being legacy, so not quite providing them the flexibility. I mean, some of the operators we work with have built quite extensive automations on top of these older older platforms. But I I think there seems to be an appetite in the industry for effectively a modernization and a refresh of that whole automation of that whole automation architecture. And because I think, you know, with the advances in the kind of AI and ML frameworks, you know, with some of the work that we're doing with NVIDIA, it just opens up so much more opportunity in terms of the type of automation that we can we can offer. And I think this ability to do the extend automation because Sony is very much traditionally focused around optimization and operation. But to extend the automation and extend and start building apps that target all the areas of the life cycle I think quite appealing is quite appealing too. And so we have several questions. They're all going down the same theme similar to the one that this one just posed, which is is, yeah, well, there's one question here, Syed, which is building a level four, level five on top of legacy OSS's mission possible. It's not really a question. I think it's more perceived a point of view, unified and and the argument being made here, unified operations and business has to be built AI native from the ground up as conditions. That's not really a question, but it sets out a point of view, which is you've got to start from scratch, which is not necessarily realistic. And then there's a second question, which is is Agentic based AI automation the only viable option for autonomous RAN where RAN vendors bring their isolated autonomous solutions are these valuable for deployment. I'm gonna turn these to Terje. They're both kind of asking the same thing. Right? They're asking, do we have to start from zero? And if we don't, is agentic the only way? But I was maybe a bit provoked by the question because at least that's how we see it, automation is not really a target by itself. It's a tool to achieve something. So then I was thinking that, you know, building on layer four, layer five, you know, is not really the the target. It's just a tool to, you know, save energy, become more efficient, or whatever. And if you approach it in that way, there are, call it, cases even in legacy systems. So we, for example, have have achieved quite a good savings on energy, building that on on, call it, the legacy systems. So so there are and we have done, you know, what we call the smart planning, for example. We have done quite a few of those things in the in the legacy way. So if you look for those, there will be, you know, opportunities to do that. Then, of course, back to what Darwin started on the, if you really want to take the full revamp, you know, then then it's a different thing. Then then you really need to to look it upon it differently. And that's almost similar to if I may provoke the rest of the panelists, it's almost similar to a greenfield approach to it. When you do that and then you do the, you know, the cost estimates on what that really takes, it might not look that good. So you're probably then going back to, okay, should we do a bit more. But I think what Darwin also mentioned which mentioned, which is very, very important, I forgot, is that when we look into private networks, it's almost like a greenfield in some of the cases. And that's very important to remember. And if you do that in the right way, you should start automating it from the very beginning. And that you can do, as I said, almost like a if you have in greenfield, you know, views and perspective. And that will be a great savings to to do it. And then then, of course, you will not replace or you will not, you know you can use, you know, all these old if you have very old OSS and BSS systems, for example, you probably need to use it to some extent, and you need to complement or you make some umbrella, so make some some, you know, systems on the site to be fully if you want to really be fully, you know, real time delivery, self-service, all these kind of things. So that's depends a bit on on the what you want to achieve. And, again, automation is a tool, as I said. It's not really the the end targets. Yeah. I know. It's interesting because it always has become a goal. Right? And great success. But I had it at TMF, TMF forum. They've created this this clear target. Everyone says, yes. We must achieve that. It's religion. And it's become a goal. So right. Which is good in some ways, but in other ways, it's it's leading to this aspiration that no one quite knows why they're fulfilling it anymore. Yeah. Neil, I wanna give you the opportunity to respond to some of these, well, certainly provocative comments from the Yeah. I think that legacy question, that building L4L on top of legacy. So I think it's a really interesting point, I think. Think ultimately it's about the kind of pragmatism that sits there. And I think none of these legacy a lot of the legacy systems aren't partially legacy in the sense that they're continually being updated and expanded a little bit. I think if I'm being slightly critical of the industry as a whole and I think what happens is that every two or three years, there's a new technology comes through and everyone goes, let's completely transform our organization based on a new technology. And then the funding runs out and then three years later you've got another legacy platform that you need to maintain. So I think the private networks example with the greenfield is great because it does allow you to give a blank slate and I presume some of the learnings that you come from private networks can feed back to what's really truly required in the kind of main networks. But I think it's really interesting challenge because I think like I said in my part, everyone can see the end goal. They're just trying to work out how to get there. So there's a very long question here about Agentic from MRD which sorry. No. From no. Actually, there's no from Nadim here. And that really is I'm trying to summarize it because it's too long, Nadim. I'm gonna pose it to you, Darwin. I don't know if you got a view on this, but this is more about to what extent can AI agents be granted access to platforms, to control, to and and also, you know, how do organizations feel about about that? And what would that to what extent can we we pursue an agentic route enabling enabling agents to perform end to end optimization across all sorts of locations across all that. I don't if you've a view on on specifically on agentic. I I thought I'd pass that over to you. Not very good job summarizing it. But Well, certainly, I have a view on that because as a service provider, that question's in front of us, and we're trying to understand and do the best we can at enabling these capabilities. So first off, I don't think you can have a conversation anywhere with anyone with the vendors of the industry that don't bring up this topic of Agentic AI. Everything now is going to be solved and fueled by this thing called agentic. And if you're not using that language, you're not in a conversation. But then there's reality. We need to understand how are we making these mechanisms function and how are we breaking this apart so that, one, we can deliver it. Two, we can enable it. Three, we can trust it and then operate with it. And so my perspective looking at this is understand the model, understand the architecture, start building that model, and then put in pieces of intelligent applications. Think of them as tools with discrete roles and functions and enable those to work to gain the confidence and trust with them to build out your model. So don't lose sight of the overall model with the tool, the agentic agent of doing something, but understand how and why that fits into place and make sure that it works good for you. Right. I do want to get to you in a second, Neil. I've got time, but I wanted to first get Tejas views on this. To what extent and how and any reservations or comments on use of Agentic and giving Agentic systems access to all of the the existing OSS and VSS platforms? I think the the of course, we can argue what is the agent in this context. But but if an agent is just a representative of a person, you know, there are you know, that's the the way you can look upon it maybe. Meaning that the agent take care of certain tasks. And then, of course, you can run an agent, like, fully autonomous, or you can run-in, like, in assisting the human. So there are a lot of ways to to do that. So, typically, that's the way we are moving from early experimenting, you know, and then giving gaining confidence maybe for correcting something in order to take the full step into auto automation. So so I would say that we are today running fully autonomous agents within its call it safeguards or the the what do you call the the yeah, the safe frame in a way. So so it it moves within that, and that's it. And so so that's also back to where we started. We are a bit opportunity opportunistic in the way we are approaching this. So that means that you can you can end up with a couple of few agents, you know, neighboring agents, you know, doing different things very targeted in within the what they are doing. So but, again, the you have to be you have to be fully aware what data is that agent working on. Is it working on confidential data? To what extent is it working? And to what extent is it, you know, leaning on some large language model? Is it is it sharing information and all these kinds of there are a lot of kind of checkpoints you have to read through or or go through in order to see is it safe or or do you need to change something before you you scale it to fully auto autonomous agent. Thank you. And quickly, Neil, obviously, you've shared some of Amdocs' aOS vision and to some extent Amdocs has embraced the agentic architecture and backed it big time. Yeah. There were some questions out there. Wanted to give you a a sense to also respond to that about, you know, how how how valid or how can we, you know, trust agentic solutions to engage with them. Yeah. I think I think I mean, I think the agentic generally feels like something genuinely new in telco and in all the other domains. I think as a whole, all the industries, telco included, are trying to find how to embrace this technology. Think I said it in my presentation, call it the kind of apps and agents kind of approach where I think the key thing that you need to do is to enable is basically to take a lot of the thinking that agents shouldn't be doing away from the agents and embedding it into apps. So for example, if you're making a decision about a very trivial example about energy savings, you can have the agent understanding all the energy saving parameters for an Ericsson network, working out how to schedule a policy, writing SQL to pull customer you know, because that's asking the agent to do to do too much. But instead, if you build an energy saving app that provides really nice simple ways of managing energy on the network, then all the agent has to do is to manage policy. And then it becomes a much more self contained activity and it gives the act it gives the agent a chance to be an agent rather than to be a kind of universal fix all in network. So we think this wrapping of existing systems, building of apps, creating a tooling layer that could be used by humans as well as agents is probably the best way the maximum amount of these agent approaches. Thank you, Neil. And we are at the top of the hour. So we could go on, I'm sure, but it leaves me to thank the panelists the really great conversation we've just had. Thank Amdocs for sponsoring both the research and this webinar. Thank my team who have been working in the background and Kirsten for the presentation and Jonathan who who's been supporting us in the background. And apologies. We've not been able to answer all your questions. We will try and get around to them. Those of you who submitted and had a lot of questions submitted, and we'll try and get back to you with some responses in the next couple of weeks. Thanks, everyone. Thanks for taking part. Thank you. Thanks.