Guy Daniels, TelecomTV (00:23):
Hello, you're watching the Network APIs and Agents Summit. I'm Guy Daniels and we are turning our attention now to the impact of AI and how telcos can handle the growth in agentic traffic. As AI-driven agents become a central fixture of modern networks, is the current infrastructure ready to handle this surge in automated traffic, or do telcos need a fundamental shift in how they approach API management and automation? Well, I'm delighted to say that joining me on the programme to discuss these issues are Ashan Senevirathne, who is product owner at Telstra, and Joel Studler, who is DevOps engineer at Swisscom. Hello, it's been a while since we last spoke, so it's really good to see you both again. I think last time we spoke, we were talking about cloud-native development. So this is a natural extension of the conversation as the industry moves forward.

(01:25):
Ashan, let me put my first question to you. Are APIs the end goal here or are they simply a stepping stone towards more autonomous network operations?

Ashan Senevirathne, Telstra (01:41):
Yeah, that's a very good question. So I think APIs are a critical step but probably not the end goal. At Telstra, we are working on a strategy called network as a product. It's a key part of our connected future strategy. The idea is to treat the network capabilities as products that can be discovered, consumed and composed in a much more flexible and programmable way. The heart of it is how you treat the network as a product. So traditionally networks have largely been consumed as connectivity services. Increasingly we are looking at how capabilities such as performance, security, identity, location, and quality on demand, et cetera, — and all this CAMARA stuff — can be exposed and consumed in a dynamic way. Importantly, this is not about trading off reliability or the security aspect for this flexibility. Reliability, resilience and security remain our first priority.

(02:38):
So the challenge is how do we make these network capabilities more consumable while maintaining the levels of trust that our consumers expect. APIs are a key enabler for that. And if you look at what happened in the cloud over the past ten years or so, APIs were really the beginning of the journey, not the destination. To explain that: we started by making infrastructure programmable — we began that journey around ten years ago. We built platforms on top of those APIs. We moved towards declarative operations. We introduced GitOps automations and now we are also looking at autonomous systems. So telcos are following a very similar path. APIs expose capabilities, but over time consumers want higher-level intents or abstractions. They want to express outcomes rather than orchestrate every individual step. That is where intent models, platform engineering and eventually AI agents become very relevant.

So I view APIs as a foundation that enables the next generation of operational models rather than the final destination.

Guy Daniels, TelecomTV (03:49):
Okay, Ashan, that's great. So it's more foundational to what's coming next and what we're dealing with today. And you said there about how we started with programmable interfaces and then we laid platforms on top. So I'd like to ask you, what do you think agent-ready infrastructure looks like now for telecom operators?

Ashan Senevirathne, Telstra (04:10):
So for me, agent-ready infrastructure looks very similar to what we are building through these cloud-native transformations. We are still on that journey. I think we are maturing, both as an operator and also together with vendors and industry partners. So the first thing is observability. An agent cannot make good decisions if it doesn't understand the current state of the environment. The second is context. Networks are highly interconnected systems. They are very distributed and technically a valid action isn't always the right action. So an agent needs to understand things like service dependencies, customer impact, maintenance windows, and also some of the operational policies that we have already set in the network.

(05:01):
Importantly, the third is governance. There need to be clear boundaries around what actions are allowed under what conditions and also what level of oversight is required. The fourth is a well-defined control plane. I think Joel agrees here as well. One thing we've learned from Kubernetes is that the control plane becomes the contract between the consumers and the underlying infrastructure. I think AI agents should interact with the control planes rather than directly with the infrastructure, at least at the start, as we mature on the operational side of the networks. And finally, we need strong auditability and traceability. If an agent takes an action, we need to understand what it did, why it did it, and how to reverse it if necessary. One of the things we learned through GitOps is that automation only becomes safe when there is a clear source of truth — or the path towards a source of truth is clearly defined — a clearly defined desired state, and also mechanisms for reconciliation.

(06:08):
Those are operational concerns rather than AI concerns, and they are exactly the foundation that makes AI-driven operations possible in the end.

Guy Daniels, TelecomTV (06:20):
Great, Ashan. And that's really interesting. Let's bring you into the conversation now, Joel, because I'd like to extend this software engineering perspective. Are our existing GitOps workflows and telco products ready for this, or do we need to adapt our approach?

Joel Studler, Swisscom (06:39):
Yeah, I think that's a very great question because the things Ashan mentioned in terms of operational stability have nothing to do with AI. We really need to invest more in gaining trust in our GitOps pipelines and the products we are building. At Swisscom, we have invested a lot in making these pipelines robust and really making them work with the full GitOps KRM-based workflow. And we really need to continue doing that in order to gain trust and in order to reduce lifecycle time spans. Traditional telcos used to lifecycle very seldom compared to what we would aim to do today. So that is really a mindset shift that we need to go through as a telco. To achieve this trust in GitOps and in the products, we need to really invest in testing and have more deterministic tests that tell us the quality of our service — not only the mobile networks, but each individual component.

(07:56):
What really helps us there, and where KRM is also very strong, is that we can have schemas and schema validation, which helps us a lot in integrating into AI workflows in the future because it is a machine interface and it helps the machine to validate its own output, which can really help us. But in terms of trust in the system, we still need to continue doing our work, and it would be an illusion to think that the current state of our networks is sufficient to bring in agents and have them solve the problems for us. I think we still need to enhance quality so we can enhance our trust in the system.

Guy Daniels, TelecomTV (08:39):
Joel, thanks very much there. And I know this issue of trust is something we've been hearing a lot about at this year's summit and I'm sure we will continue to as well. Ashan, let me move across to you again. What role do declarative and intent-driven models play in the future of telecom platforms?

Ashan Senevirathne, Telstra (08:58):
Yeah. So if I answer the question from the platform perspective, we see in this cloud-native transformation that a lot of workloads are moving to Kubernetes. For me, this is probably one of the most important topics in the discussion. One of the biggest lessons we learned from Kubernetes — other than moving workloads into containerisation and all the orchestration — is to bring in declarative operations. So instead of telling the infrastructure exactly what to do, we describe the outcomes we want and allow the platform to continuously work towards those outcomes. Exactly as Joel's point illustrates, once we have that foundation, it tends to be a very powerful model because it scales much better than imperative operations. So telcos are moving in that direction. Telstra has invested quite heavily in that. Swisscom and also many other projects like Project Sylva and Nephio are all going in this direction. Intent-driven models help move interactions to a higher level of abstraction.

(10:06):
So instead of manually managing individual configurations, we focus on desired outcomes. That is also where MCP becomes very interesting. Once these capabilities are exposed in a consistent way, MCP can provide a mechanism for AI agents to discover and interact with those capabilities. In many ways, MCP becomes the consumption layer while the platform remains responsible for translating intent into operational actions safely.

Guy Daniels, TelecomTV (10:37):
Great. Thanks, Ashan. So just to clarify: MCP is like a consumption layer and then we're talking about describing outcomes. I've got a question here from one of our viewers who sent in a question just before the summit. I think this is relevant. The question is: what is event-driven architecture? How does intent and declarative fit with event-driven? Are we talking about the same thing or is this something different?

Ashan Senevirathne, Telstra (11:06):
It is somewhat connected. In Kubernetes, everything is based on events. So for example, if something fails, we can take actions on the events that Kubernetes provides. This is more from the platform side that I'm talking about. One of the things we do in Kubernetes is declare what we want and then the system figures out how to achieve it. One example I can give is that we deploy an application using one of the mechanisms — in this case it would be using Helm — and then Kubernetes will emit an event saying, "This is successful." We can then take action on that, saying, "Okay, go and run the end-to-end test based on that." Rather than going outside to our orchestration, we handle all the events and the mechanisms within the Kubernetes layer.

(12:08):
So they are somewhat interconnected and quite relevant to these topics.

Guy Daniels, TelecomTV (12:13):
Ashan, thank you very much for answering that question from one of our viewers, because I was looking at it earlier and it was confusing me as well. Joel, I'd like to come across to you and ask: as we move towards autonomous networks, what blockers and obstacles do telcos and their engineering teams face when extending this work?

Joel Studler, Swisscom (12:37):
Yeah. So I think there are two main things we need to fix or really take care of. One is what Ashan already mentioned — the API contract between our systems. I think we need to invest more in having clear interaction layers and clear abstraction layers so we can really make systems loosely coupled, or create an entire ecosystem of loosely coupled components. The other thing — at the risk of sounding repetitive — is that we need to invest in testing at all layers. We can have unit tests in our codebase, we can have integration tests that test against mocked systems, and we should really have end-to-end tests as much as possible to gain trust. And of course on the other side, monitoring — where the line between monitoring and testing is not always very clear — but I think if we achieve that, we will gain the trust needed to expose these things to MCP, to LLMs and so on.

Guy Daniels, TelecomTV (13:38):
Thanks very much, Joel. And Ashan, do you want to add something here?

Ashan Senevirathne, Telstra (13:43):
Yeah. One of the things I want to extend from what Joel mentioned: with GitOps and its declarative automation, we are moving to the source of intent. You define your intent, but then the system collects all the information from various sources, assembles the config and then actuates it. One of the challenges is the fragmented source of truth — the inventory lives somewhere, the topology information lives somewhere else. So it's more about how we connect all these pieces together. And before we allow AI systems to make operational decisions, we need to be confident that those decisions are explainable, auditable, and aligned with policy. That is one of the challenges I think we need to look at from an architecture point of view. For those who are invested in the GitOps and declarative journey, it is one of the challenges that I see we need to tackle.

Guy Daniels, TelecomTV (14:46):
Okay. Thanks for that, Ashan. And Joel, we said at the beginning that the last time we spoke it was all about cloud-native developments. Are there any best practices from the work you've been doing on cloud-native and from IT that telcos should embrace here?

Joel Studler, Swisscom (15:04):
Yeah, I think Ashan has already mentioned it many times — the declarative way of automation. I think that is really something we should continue to adopt and to leverage for telco, because I think it is applicable to telco as well. On the other side, I think the monitoring stack from IT can help us a lot because we can have very granular insights into our systems. It of course depends on how we can really look into systems that are often proprietary in a telco environment. So opening up these systems is always a good thing, and that is what cloud-native taught us, because it is a huge framework of toolsets that are open and can just be used. I would really like to see broader adoption in telco of these open cloud-native tools that are used in IT — not the proprietary bundled version of them, but really the open upstream versions. That would really help us in moving forward on this journey.

Guy Daniels, TelecomTV (16:16):
Absolutely. And such a critical foundation as well. Well, let me put a final question to both of you. Ashan, I'll come to you first. What do you think are the most critical challenges that telcos face today when moving from, shall we say, traditional API calls to AI-instigated calls?

Ashan Senevirathne, Telstra (16:37):
Yeah. I think the biggest shift is that we are moving from deterministic interactions to goal-oriented interactions. That is the journey we are going through with this declarative and intent-driven automation. Traditionally an API call is usually the result of a developer explicitly coding a particular workflow. With AI agents, we are increasingly talking about systems that are reasoning about objectives and deciding which capabilities to use in order to achieve those objectives. That introduces a different set of operational questions. How do we validate the intent? How do we enforce the policy? How do we provide enough context for good decisions and explain those outcomes? And also, as I mentioned earlier, how do we revert a change, and when do we revert those changes? From my perspective, the hardest challenge isn't the API call itself.

(17:35):
It's making sure that the agent has the right operational context and governance to make the right decision. That is why having this foundation — as Joel mentioned, the testing and the right automation — is very key for any telco. And as the autonomy increases, the system needs to understand not just what it can do, but also what it should do. We should also be very confident in our understanding of auditability, traceability, and how we would revert changes.

Guy Daniels, TelecomTV (18:09):
Fantastic. So we've got that move from deterministic to goal-oriented as you explained there. And Joel, your thoughts on the challenges that telcos face when moving from one approach to an AI-driven approach?

Joel Studler, Swisscom (18:24):
I think we have already mentioned it — the declarative API contracts, the automation, the trust in the automation, monitoring. Ashan mentioned a lot of it as well. But it would be interesting to turn the question around. What challenges could we solve today? What are the low-hanging fruits? And there I think there are a lot of things we can do today in the troubleshooting area and in the operations area, where we can use LLMs and agents as assistants to our troubleshooting, because LLMs are much better at analysing logs and pinning down root causes, or at least helping you pin down root causes. Analytics and all of these use cases exist and we should start leveraging them. On a positive note, I think we can use them today, we can make use of them and we can really gain value out of them.

(19:24):
What challenge will come up in the near or far future will be the cost. We currently don't know what the cost of using all these LLMs will be, and we already feel today that the cost is increasing and we need to manage it in our companies. That is definitely a challenge that will be upcoming.

Guy Daniels, TelecomTV (19:39):
Great. Thanks very much. As you say, there are some challenges, but there are some positives that we can take from this today. Well, we must leave it there for now because that is all the time we have. Thank you both so much for taking part in our programme today. Good to see you both again. And if you're watching this live as part of our Network APIs and Agents Summit, then please stay with us — don't go away because there is still plenty more to come, and you can find the full schedule and speaker details on the TelecomTV website. If you're watching this on demand, then you'll find links to the other programmes on the summit homepage on TelecomTV. For now though, thank you and goodbye.