Will Agentic AI solve the telco OSS integration challenge?

Agentic AI supported by open source MCP holds great promise for simplifying integration and facilitating information transfer necessary for advanced automation.

But while there’s early promise, it’s unrealistic to expect that telco networks, including the OSS, BSS and other domains, will convert overnight into a plug-and-play framework. The truth is diversity will remain, and we’ll gradually adopt Agentic approaches while maintaining existing methods of interaction.

Agentic interaction is coming, backed by innovations in MCP

Among the many conversations regarding AI and how its use can support new ways of operating and running telecoms networks concerns the role of Agentic AI in enabling interaction and integration between different systems and entities. The TMF, for example, has a vision of using AI in just this way as part of its Open Digital Architecture.

Here, the ultimate goal is to use MCP (Model Context Protocol) to enable Agentic interactions between different processes – essentially enabling information to be retrieved when required so that requisite actions can be taken.

MCP is a relatively new approach to integration. While it’s already gained significant attention, it was actually only recently launched: in 2024 as an open-source initiative. The primary purpose is to enable AI-based applications to interconnect with other platforms.

This means that, a process with Agentic AI can use this to request information from a database – or from another AI-enabled platform. In essence, they are having a conversation. However, the real innovation is not just in the fact that these dialogues can be autonomous and self-supporting, but they can be enabled securely under a strict governance framework.

This means that, if information is restricted, access can only be given to authorised systems. Of course, this matters greatly in telecoms, because telco networks form part of critical national infrastructure and are covered by legislation such as NIS-2, DORA, the TSA and much more – which also means that actions are subject to strict controls and audits, as well as compliance with the telco’s own operational processes.

Promising signs – but wait a moment!

The new approach holds great promise and is being explored in depth. There are already examples of this through the TMF’s Catalyst programme. And, potential use cases abound – if, for example, we need to check resource availability before processing a sales order, as in the example, we need to be able to make an enquiry to a network inventory system, so that we necessary information can be obtained.

Similarly, a service monitoring solution might detect a drop in quality, which could trigger a check to a policy system to determine the SLA levels that should be enforced, while then triggering remedial actions necessary to restore services to the appropriate level.

While you don’t need Agentic AI to do this (it can and has been done with We Are CORTEX), it’s easy to see how this would help drive enriched automation and facilitate network and system integration with an approach that starts to look a lot like plug and play.

So, in this context, Agentic interactions will supplement — and, to some extent — replace classical API-driven interactions to simplify processes and move towards plug-and-play service enablement and orchestration.

In the end, systems from different vendors will be able to interact via Agentic AI, so they can exchange information that is required to support end-to-end processes, customer journey maps and workflows.

This is a perfect vision, in which operators can simply connect different solutions via their new Agentic interfaces and MCP services – and replace them when they retire systems or swap out solutions from one vendor for those from another.

But let’s be realistic. This vision is some way off, despite the current excitement and positive results from PoCs.

Diversity is the norm

It would be wonderful if every vendor’s solution came with Agentic AI capabilities, plus MCP servers to enable this level of freedom and integration. But the truth is that not all will – and many platforms that are already deployed will never support such capabilities.

This means that, while we can — and will — invest in these capabilities, we cannot pin our hopes on a universal mode of integration. Instead, we must continue to embrace diversity – just as we do today.

Of course, we need to embrace standardised APIs — like those in the ODA — as well as others that may be proprietary or based on REST, SOAP or other methods. But we also need to remember that there are other kinds of interfaces, such as Performance Management feeds, SNMP, telemetry, signalling protocols (that SS7 interface for CAMEL isn’t going to disappear for another few years), and so many more.

If we want to integrate different systems, we must acknowledge the fact that there will be a diversity of interfaces that must be supported to enable the necessary information exchanges and the automations that can result.

AI helps, but diversity remains

And that requires automation and orchestration solutions that can support this diversity, even while we are building and adapting for future harmony.

We know operators that still maintain ISDN connections, use SS7 for inter-operator exchanges, run Diameter alongside legacy interfaces – and have MQTT alongside other telemetry interfaces. There’s also a host of reporting mechanisms, as well as different kinds of APIs.

So, while it’s nice to aim towards a less complex future — and the TMF has clearly set out how that might be achieved — enabling automation demands that these interfaces continue to be supported. Existing customers depend on them – and, in many cases, these legacy platforms support customers with critical service requirements that simply cannot be disrupted or migrated to new platforms.

Our networks are complex and include multiple generations of solutions and technologies, and not all of these will be upgraded to support the latest models for interfacing and exchanging information. Some will, but operators will have to contend with this heterogeneous network for many years to come.

AI is an answer, but it’s not the only one

And, if you think about it, this is why we haven’t just shut down other generations while embracing the latest. We have 5G, but you couldn’t just close down 4G that when that became available. That’s also why we have SD-WAN and super-fast Ethernet together with DSL.

Yes, Agentic AI interactions offer huge promise but on its own, it cannot simply solve the telco OSS (or any other) integration challenge. That requires solution providers that can support the future as well as the past. It will complement other approaches, as systems are modernised – and have to live alongside legacy integrations for those that have no pathway to this model.

You can read more about how innovations in AI are shaping novel approaches to automation and operational transformation in our new paper – but you can also explore how we provide a solution that adapts to the reality of your networks and enables you to accelerate automation, today, by opening a conversation with our team.