Guy Daniels, TelecomTV (00:24):
Hello, you're watching the Network APIs and Agents Summit and our programme on the evolution from APIs to AI agents. I'm Guy Daniels and our opening discussion seeks to establish the architectural and commercial foundation for the evolution of network services. Operators urgently need clarity on how AI agents interact with APIs, orchestration and network exposure platforms, and whether emerging frameworks like MCP complement or disrupt existing telecom API strategies. Well, I'm delighted to say that joining me on the programme to discuss these issues are Aaron Partouche, who is Innovation Director at Colt Technology Services, and Tapas Ranjan, who is Vice President, Applied AI, for Rakuten Symphony. Hello, both of you. Really good to see you. Thanks so much for taking part today. So first question then, picking up from what I was saying in the introduction there — how should telcos position MCP alongside initiatives such as Open Gateway from GSMA and CAMARA, rather than treating them as competing approaches?

(01:44):
Aaron, can we come to you first and get your thoughts on this?

Aaron Partouche, Colt Technology Services (01:48):
Yeah, for sure. So MCP is not a replacement — for sure. It's a consumption layer for AI, while CAMARA and Open Gateway remain the exposure layer for networks. So on one end, we have CAMARA and Open Gateway that standardise what network capabilities look like — quality on demand, device location, and possible northbound APIs for developers or enterprise systems — and ensure interoperability between carriers. MCP acts as a bridge between APIs and AI agents.

Guy Daniels, TelecomTV (02:39):
Great. Thanks very much, Aaron. And Tapas, what about you? What's your recommendation for telcos as to how they position MCP against these existing frameworks?

Tapas Ranjan, Rakuten Symphony (02:51):
Thanks. I think this is one of the most critical tension points which is currently happening in the telecom industry. And everyone has been moving away from the hype of agents to actually integrating agents into their ecosystem now. And when we talk about that, we already had these standardised CAMARA, GSMA, Open Gateway API standards already available. For example, for the networks to get started and understand how they are going to expose their network for a developer to build some products or applications on top of it. But when MCP came into the picture, the best thing that has actually happened is that it has given a semantic bridge to these developers in order to understand how these network capabilities can be exposed to them. If we say that these are competitors, I don't agree — because on one hand, like what Aaron was mentioning, we have been having these CAMARA APIs because they are exposing the network elements and exposing the network capabilities back to the developers.

(03:58):
And on the other side, these APIs are also enabling developers to move into the autonomous journey within their network as well. So it is more of, I would say, a capability offering which has now been made available to the telecom industry, or anyone who has been utilising these capabilities from telecom out of the box. To give another example — and I'll take the example of Rakuten here itself, because we have been investing a lot of energy in order to do network-based API implementation with a couple of our operators and teams — what we have seen is that these network APIs are collaborating and giving a capability back to these operators so that they can offer it back into data monetisation or API monetisation frameworks as well.

(05:00):
But additionally, what has also happened is that because of MCP, the whole process has become fast enough. They're able to understand better, they're able to interact better, and the journey which they've been trying to think about for autonomous level four — or reaching towards 4.5 or five — they're actually finding it to be the right way to move forward. So I feel that these are not in competition, but are complementing each other in the right way, which I think the industry was looking forward to as well.

Guy Daniels, TelecomTV (05:26):
Great. Thanks so much, Tapas. I like how both of you have said they're complementing APIs. And Aaron, if I could just come back to you — I'd like to build on something Tapas was saying there about APIs enabling developers to perhaps move towards autonomy. So do you at Colt, and does the industry in general, see APIs as a stepping stone towards more autonomous network operations, or are APIs an end goal in themselves? Is it an end goal, or is it part of an ongoing process?

Aaron Partouche, Colt Technology Services (06:00):
I think it's part of the ongoing process to move toward autonomous networks. We need to see how APIs will have a role with the different agents we will have — both on the network operations side, but also on the application side. And we have some challenges to solve here, but globally APIs will be the foundation of these autonomous networks. And particularly if we look at what we have showcased recently between several operators — we at Colt are trying to help on the API standardisation for Open Gateway, coordinating with GSMA and so on. And we showcased the key role of APIs in what we call closed-loop automation, which is a kind of foundation to allow the intelligent remediation that we could have today and in the future in the network, to really offer a kind of business intent objective to the network.

(07:22):
So to provide this autonomy. So yeah, APIs are the foundations. Are we completely there with APIs? I think not yet. We may have some challenges today to completely integrate with agents, but they are an important foundation.

Guy Daniels, TelecomTV (07:44):
Aaron, that's fantastic. Thanks so much for clarifying that for me. And I've got another point I'd like to clarify — Tapas, coming back to you. You talked about this semantic bridge that MCP offers to developers. Is there real evidence now that developers really want to converse in this way, and that they need this semantic layer in order to fully utilise APIs in their development process?

Tapas Ranjan, Rakuten Symphony (08:10):
I agree. And the reason I also say that is: first, these CAMARA APIs or the standard APIs have been available for quite some time now. But if you look at adoption, it's been quite slow across the industry. There have been certain use cases people have been pursuing around SIM swap, quality on demand, and many others. But I feel there was still a slowness in adoption of the overall approach. Now, with the changes which have happened quite recently because AI agents came into the picture — on how developers can now understand the whole layout of a particular API, what that API can actually do, without even considering the complexities of how the network has been triggering all of that — that becomes very, very important.

(09:13):
And it also becomes very important because of how these tools that you are exposing as part of your operator are being offered back as MCP. For example, we've been talking about these protocol-based tools, but there has to be a need for a canonical tool repository which has to be made available. Because as of today, we've been talking about MCP, we've been talking about A2A protocols, LangGraph, LangChain, and there are so many other AI frameworks coming out every day — and it becomes very, very difficult to keep pace with it. But if you continue to bind your system to a certain tool registry or a semantic algorithm, it may not work because it has been evolving so fast. So what I feel is that if this semantic layer can be built in a way that it acts like a registry — a registry that is not tied to a certain framework, but acts as a capability back into the network —

(10:26):
then rather than calling, say, "CAMARA quality of service V1," users should be asking: "For this user, I want to increase the video quality — how should it be done?" And that is where we are removing the semantic hard-coding that these APIs used to have, and moving it directly into the intent layer. And I feel that is the direction in which these network APIs have also been evolving — and so too the telecom industry and the AI frameworks as well.

Guy Daniels, TelecomTV (11:01):
Great. Thanks very much, Tapas. So Aaron, in your opinion, what does a protocol-agnostic tool definition layer actually look like in a real operational telecom environment?

Aaron Partouche, Colt Technology Services (11:14):
I think it's key to avoid locking with protocols, but think of it as an API of APIs that will simplify and offer a single, clean telco layer that could let AI access network capabilities without really worrying about the underlying protocol. So this will be the goal of this protocol-agnostic tool.

Guy Daniels, TelecomTV (11:42):
Great. Thanks very much, Aaron. Well, we've looked at the tools, we've looked at the semantic layering on top, we've looked at keeping it agnostic. Tapas, I'd like to move on and ask you about practical problems that we're starting to see from operators and their vendor partners. When they expose their network APIs to LLM-driven agents, what's changing? What are they seeing? What are the challenges they're facing?

Tapas Ranjan, Rakuten Symphony (12:16):
I think just to give you some context on that — and this is our experience and our learning that we have also been seeing while implementing our agentic capabilities, and from speaking to the industry and trying to gauge where they currently stand, how they've been utilising these network APIs and so on. A few of the challenges we see upfront: first, discoverability. With large language models, they certainly understand context — they certainly understand how the API structure looks. But there is still a big problem of them drifting and hallucinating. For example, if I have given a Swagger with a lot of APIs in it, there's a good chance it might discover them very differently — a parameter might change or be skipped when the actual implementation happens. That's one of the major issues.

(13:18):
The second is statefulness. Large language models are stateless — they do not manage any state. It's through the agents that state is brought into memory, tools and other capabilities. But by default, large language model statefulness is another challenge we have seen. Another one is authentication and the contract that they actually have. For example, all the APIs which the CAMARA or GSMA Open Gateway and other standards have been rolling out — I feel one of the key differences is that all those APIs were built for machines to ingest and humans to operate. But now when we are trying to use these same APIs for operation with AI agents, that's where the challenge comes. For example, you have created an API that handles 50 requests per minute, but the agents are not able to understand that — they continuously retry on failure, for example when a 429 "too many requests" or a 503 is coming back.

(14:36):
But the challenge is that the agents keep on trying, keep on retrying. So rather than waiting and understanding what the problem is, they are trying to fulfil that particular intent. And the challenge there is that rather than solving a problem, they might create another problem for operations as well. So I think these are some realistic problem statements which have been emerging. We at Rakuten have also been investing quite a lot in understanding how we can contribute back to the community while these solutions are growing, and how we can build a solution which is agnostic to these particular problem statements — and how the intent-driven capabilities we always talk about, the autonomy journey we always talk about in these standards, can actually be met. So these are the fundamental challenges we have been seeing, and this is the way we have been approaching them as part of our mitigation plan given the current state of the frameworks.

Guy Daniels, TelecomTV (15:39):
Great. Thanks very much, Tapas. I do recall we were talking about this last year — about the problems of the volume of agent traffic and their persistence in their actions and the consequences for networks and operators. It's interesting to hear that's still continuing. Aaron, let me put it to you then. What problems are you experiencing, or what are your peers and other telcos experiencing, with this growth of LLM-driven agent traffic?

Aaron Partouche, Colt Technology Services (16:16):
So it's still early stage — we are still learning. APIs are not really the problem for us. The problem, as Tapas mentioned, is more around trust, orchestration and commercial model. On trust: as I said, we have APIs that have been defined for users, for simple systems — and you could have ambiguous parameters or missing context when you interface with an agent. An agent acts on behalf of a user, but it's not a user — while telcos require explicit consent, may require strong authentication, may require compliance like GDPR. So there is a kind of gap. If we look at orchestration today — and this is also what Tapas mentioned before — an agent could be looking for an outcome, and in fact we may need to chain APIs, which could be a challenge for the agent, and we could have an issue orchestrating the different APIs that we need to activate.

(17:40):
And then if we look at the commercial model today — the main business model is pricing APIs per call, while an agent may dynamically call multiple APIs. So the pricing model today is not really thinking about an agent-friendly business model. So as I said, it's still early stage. We need to learn. APIs are great foundations, but today there is still a gap between APIs and how LLM agents are working.

Guy Daniels, TelecomTV (18:33):
Great. Thanks, Aaron. And that was an important addition — to think about the commercial consequences of this shift in traffic as well as the technical issues, and that's something we do need to explore further. Tapas, can I come back to you on this question? Because we've talked about being agent-ready. Is there such a thing as agent-ready infrastructure at the moment for telcos, or are we still in the process of adapting and creating more of a hybrid approach?

Tapas Ranjan, Rakuten Symphony (19:03):
I think it has gone back to the same level where we started all of this journey — from waterfall to iterative and incremental, to Agile. It's the same process which we have been following with the AI infrastructure as well. And the same for the frameworks — we've been seeing how it has been evolving from a single agent to multi-agent orchestration and now to intent-driven. So I think from a readiness point of view, it is evolving and it is going to keep on evolving for, I would say, the next couple of years — until the time we see that it has reached a point where the two A's we talk about — automation and agents — are finally handshaking and saying that they can complement each other, because automation has also driven a lot of workloads with priority, but now the agents can also understand that automation better, while also utilising the infrastructure at the backend. But it's going to keep on evolving.

(20:07):
It is not going to be an overnight shift. It is going to evolve because a lot of the network is, again, complex and heavy — and in order to make sure that these are open interfaces, open for anyone to consume, anyone to integrate, to make it operable, it becomes very, very important for them to understand the right way to move forward. So that's what I feel about how it is going to evolve over time, and that's how the industry is also going to move along.

Guy Daniels, TelecomTV (20:44):
Thanks very much, Tapas. And Aaron, you've said a couple of times there about APIs — "we're not quite there," "it's evolving," "there's still work to do." So are today's telecom API frameworks flexible enough for autonomous agent-to-agent workflows, or do we have to do a fundamental redesign to achieve this?

Aaron Partouche, Colt Technology Services (21:12):
No, I don't think we need to redesign. I mean, telcos are well positioned with APIs, but potentially we need to evolve from a role that is more of an API provider to an agent platform. Let me explain.

(21:31):
What works well today is standardisation, interoperability and exposure of valuable network assets. So this is what works well with APIs and we should definitely not start from scratch on that — we should leverage it. What do we need? What is missing today? It has been mentioned several times by Tapas. Today with an API, you can do a kind of low-level operation. Let me give an example: we are operating remote operations that require stringent SLAs. What you can do today — and this is what we demonstrated recently with Google Cloud and Range at Mobile World Congress — we are working on a closed-loop automation where we have an AI agent that can monitor the network, provide remediation, accept the remediation — so, "let's change the path because we have some congestion," and then improve the latency because we need to meet a specific SLA — and so on.

(22:55):
So a lot of low-level operations with closed-loop automation. An agent will not think like this — it will just say, "I need to get my SLA in the next four hours." So moving from low-level operation to high-level outcome objective will be one of the key goals. The other missing part is that APIs can miss context-rich metadata that could help in the reasoning phase with agents. And the last — and maybe not the last but one of the most important — is governance. Because if we talk about autonomous operations managed by agents without human intervention, it means we need to have safety controls — potentially a kill switch if we want to shut down a process that is not working because we missed one parameter, and we may need policy enforcement.

(24:14):
So the governance aspect will be key. We need tools to monitor and manage that governance, particularly if we now let AI agents take all the decisions on the systems.

Guy Daniels, TelecomTV (24:33):
Aaron, that is great. Thanks so much for explaining that and going through that example as well. And let me quickly go back to Tapas. So is it right that we don't need a fundamental redesign to accommodate agent-to-agent workflows? We can build on what we're doing at the moment?

Tapas Ranjan, Rakuten Symphony (24:52):
I think I agree. I would say there is no requirement to make a fundamental change to what has already been done, because this has been curated by spending a lot of time and energy in understanding every bit of the network. So I don't see a need for change there. But the way it has been defined may need to evolve a bit in terms of how agents are going to be utilising them. For example, the existing APIs are more request-and-response driven — and these request and responses are either human-led or machine-driven. But in order for agents to actually utilise them, they need to be more asynchronous, like state events, where an agent can quickly subscribe to a particular event and then the API is triggered at the backend — which is also what Aaron was mentioning.

(25:57):
And that becomes a very important point — understanding why there isn't a need for a fundamental change, because these are fundamentally correct representations of the network. It is just that they need to be shaped in a way that the agents we have been planning can access them in a way that is secure, fully authenticated, working in a closed-loop environment, and driving a particular business use case — because it is very important for them to operate the right way. It's well past the hype of agents and into the actual integration into the telecom industry, which is where we are at the current moment.

Guy Daniels, TelecomTV (26:47):
Tapas, thank you very much indeed for that. Now, we have been asking our TelecomTV viewers for their questions on this topic, and I know from your responses so far, you've covered off quite a few of the questions they wanted raised — which is terrific. We do have time, just about, for one more question that I don't think we've really covered so far. Aaron, let me try and put this to you first. It's about cloud native. Are there lessons that telecoms can learn from cloud native platforms as they move towards agent and AI-driven operations?

Aaron Partouche, Colt Technology Services (27:24):
So I mean, where is this transformation today? We have today in most telco networks a move to leverage much more cloud native platforms. So this is a fact, and it's a great way for us to expand capabilities. And indeed it also provides some support or capabilities for us to use more AI engines and agents. I was giving the example of an AI agent that continuously monitors the network and continuously provides remediation actions when we need to target a specific SLA. All of this is facilitated by cloud native platforms — because we can easily deploy capabilities in a specific location because it's cloud native, and then leverage the AI agent that will provide those capabilities. So indeed, moving to cloud native and embracing more of these cloud native platforms helps us to have more capabilities, particularly in our NetOps and in the AI agents that will interface with application LLM agents, for instance.

(29:20):
And yes, for me, this indeed works very well together.

Guy Daniels, TelecomTV (29:28):
Aaron, that is great. And Tapas, let me put that to you. Is cloud native a foundational benefit as we move towards agent and AI-driven operations?

Tapas Ranjan, Rakuten Symphony (29:39):
I completely agree, and I think that's the right way to move forward as well. And I think that's the edge which we got at Rakuten as well — because from day one when we started to build the Rakuten Mobile network, it was on Open RAN foundations and it was also on cloud native principles. And I feel that has given us both an edge and a foundational base from which we can actually think about and align our agentic behaviours for the future. The second is openness — it has helped us to see that, for example, the network API integrations or the use cases that we wanted to deploy at the edge or on a certain network node, which is already cloud native, become easy. Because at the end of the day, all of these network communications comes back as an endpoint which an agent can consume, and that agent can then be trained in a certain way — to do a specific use case, for example managing a slice, managing quality on demand, or helping the user on a certain use case.

(30:52):
So I certainly feel that being cloud native is definitely a big plus in this era where we've been seeing a great transition — across how telecoms have been evolving, how the industry has been evolving, how enterprise has been evolving. But I think one fundamental element I would like to mention is that it is going to be a winning situation for those who are actually building a platform, and a losing situation for those who are still reluctant to touch this new capability which is already out in the market. So it is definitely the right approach to understand how the network needs these AI and cloud native capabilities to be deployed fast — rather than later — because the way AI has been changing every day, it is going to be a really exciting journey for all of us.

Guy Daniels, TelecomTV (31:56):
Yeah, it certainly is. And thank you both for answering that viewer question — that is terrific. Well, we must leave it there for now because that's all the time we have. Thank you both so much for taking part in our programme today. And if you're watching this live as part of our Network APIs and Agents Summit, please do stay with us — don't go away, because there's 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, you'll find links to all of the programmes on the summit homepage on TelecomTV. For now though, thank you for watching and goodbye.