Process ontology: The missing layer for agentic AI in telecom

Insights

• Telecom operators have invested heavily in AI, but structural gaps in how systems share context and take action are holding back enterprise-wide returns.
• A process ontology, a live model of how the business actually operates, is the missing layer that connects AI insights to authorized action across domain boundaries.
• Building this layer requires deliberate design on open industry standards, starting narrow with one or two high-value processes before scaling across the enterprise.
• Operators that move in the next 18 months build a compounding advantage in data, capability, and competitive position that later entrants cannot easily replicate.

Telecom operators have spent the last decade building the infrastructure for artificial intelligence (AI)-led transformation. Data lakes are full. Models are in production. Cloud-native stacks are live. Yet the returns tell a different story. While 75% of telecom executives believe AI delivers competitive advantage, 65% admit their initiatives haven’t delivered expected value. An Infosys study that surveyed over 3,000 companies worldwide confirms the finding: only 19% of AI use cases achieved all business objectives, pointing to a wide belief-to-realization gap for operators aiming to scale AI enterprisewide.

The visible wins are real, but modest: tickets close a little faster, calls route a little better, and task-level agents handle routine work with reasonable reliability. But customers expect fast, self-serve resolution, senior leadership wants autonomous operations, and boards demand clear return on investment. Modest efficiency gains do not meet those expectations. The transformational returns that justified these programs remain out of reach. Something structural is missing, and more data cleansing or a larger model will not fix it.

Why AI returns fall short of potential

Four interlocking problems explain the gap.

AI systems are blind to each other

As per research, only 41% of operators have a true end-to-end data architecture across domains and departments. So, most AI models cannot read signals from adjacent domains. The network alarm system and the customer management system run in parallel, with no shared view. A fault that triggers a service-level agreement (SLA) breach on a priority enterprise account may never reach the system that tracks whether that customer is at risk of leaving — the two signals sit in separate domains, and nothing connects them. The visible symptom is alert fatigue. The real cost is missed revenue protection and broken customer journeys.

Process knowledge is locked in documents

Almost every operator has process documentation, but it sits in diagrams and shared drives, not in runtime systems. Most AI models in production act on point-in-time data with no view of what caused the current condition or what happens downstream.

Insights are not acted upon

Even when AI generates the right cross-domain insight, a predicted SLA breach or a customer at churn risk, recommendations go unactioned. The insight is right, but no one owns the intervention across domain boundaries, and AI lacks the cross-domain authority to act on its own.

Regulatory risk is mounting

The same fragmentation that breaks cross-domain AI action also breaks compliance. The European Union AI Act requires explainability and audit trails for high-risk AI decisions. Europe's General Data Protection Regulation (GDPR) demands the right to explain automated outcomes, while Europe’s Network and Information Security Directive (NIS2) mandates process-level resilience for essential entities. Yet with decision logic scattered across siloed systems and locked in static documents, no single point of accountability exists. Operators cannot easily explain what their AI decided, why it made that decision, or which process state it was acting on.

Across all four problems, the diagnosis is consistent: telecom systems today understand data, but not the process. The Infosys AI Business Value Radar identifies a direct link between AI success and transformation of data architecture and operating models. Most operators are at a natural stage in their AI journey, building capability domain by domain and delivering real but partial returns.

Closing the gap between partial and full value requires a shared, live model of how the end-to-end business operates — one that connects an event in one domain to a customer impact in another, and to the intervention that should close the loop. That missing layer is a process ontology.

What is a process ontology

A process ontology is a shared, real-time view of how the business runs end to end. It connects events across network, operations, and customer domains to the processes they belong to, the decisions in progress, and the outcomes at risk. With this layer in place, AI stops working in silos. It understands where the business is in a given process, what is at stake, and what action is required to stay within SLA, protect revenue, or maintain customer experience.

The question then becomes how to embed this capability into the operating environment in a scalable and sustainable way. The answer lies in establishing a structured architecture that brings together data, context, and process execution into a unified model (Figure 1).

Figure 1. Three-layered architecture of a process-intelligent telco

Source: Infosys

How the layers work

Layer 1: Unified data model
The first layer answers a basic question: “what exists.” It standardizes the core entities a telecom business depends on, such as customers, orders, and services, into a single source of truth. Most operators already have this layer in some form. Operations platforms provide the live operational state that feeds the ontology with what is happening across the network, orders, and customer accounts. Event streaming and integration tools keep that state current in real time, ensuring the ontology reflects business as it operates. The limitation is that these platforms are built to execute processes, not to understand or reason about them.

Layer 2: Domain ontology
The second layer answers a deeper question: “what does this data mean.” It adds semantic relationships linking a customer record to the service it is subscribed to, or a fault event to the network element that generated it. Ontology modeling tools give structure to this second layer — a telecom-aligned schema that AI can navigate. This gives AI models context they would otherwise lack. What this layer still cannot tell an AI agent is where that data is housed in an active business process, how long the process has been in progress, or what the next authorized action should be.

Layer 3: Process ontology
The third layer is where the architecture becomes powerful. It captures how the business operates — end-to-end process flows, state transitions, SLA timelines, decision logic, and handoffs across systems. This layer connects processes into a structured model that AI can navigate in real time. Knowledge graph engines are the tools used in this layer. They help connect the nodes and relationships across processes, enabling reasoning that crosses domain boundaries. In a telecom context, each node represents a process such as order-to-activate or trouble-to-resolve, while the links between them capture dependencies, sequence rules, and SLA constraints. Industry frameworks such as TM Forum’s business process domains, including fulfillment, assurance, and billing, provide the underlying structure. In practice, building this layer requires deliberate design and alignment to open standards. TM Forum’s eTOM provides a globally recognized taxonomy of telecom business processes. The information framework, formerly known as shared information and data model (SID), provides a common data language for telecom entities. Together, they serve as the connective fabric that keeps the architecture consistent and interoperable across platforms.

Execution tier

Sitting above these layers is the execution tier. Here, autonomous agents use live process context to coordinate actions across domains within defined policies and SLA boundaries. This is where business outcomes are realized through improved customer experience, stronger revenue protection, lower cost-to-serve, better SLA adherence, and faster time-to-market.

Process ontology in practice

Together, the three layers, alongside the execution tier, fundamentally change what AI can do. Without a process ontology, AI answers what happened: alarms trigger, dashboards update, and models generate predictions. With process ontology, AI understands why it happened: events are linked to process state and connected across domains. With execution capabilities in place, AI goes one step further: it determines what should happen next and acts preemptively to make a difference.

Two use cases show the step-change that process ontology delivers.

• Closed-loop order fulfillment: A business-to-business order carries a five-day SLA. On day four it stalls at provisioning. A process-aware agent queries the ontology, identifies the blocked handoff, computes remaining SLA exposure, and reroutes via an alternate path — without human escalation. The breach is averted. This pattern reduces order fallout from between 8% to 12% to less than 3% and compresses cycle time from 5.2 days to 2.8 days.
• Proactive trouble resolution: When network telemetry shows degrading performance on a core node, an agent traverses the ontology to identify every affected service and customer, prioritizes by SLA tier, dispatches automated remediation, and applies proactive credit before customers notice any impact. Mean time to repair falls by more than 50%. SLA breach rates drop from around 6% to under 1.5%.

Both use cases are from Infosys deployments across the EU, UK, and Asia-Pacific regions. Operators that have embedded process ontologies report higher returns on their overall AI investments.

Decision logic and authorized actions encoded directly in the ontology make every agent decision auditable, helping organizations meet EU AI Act, GDPR, and NIS2 obligations as a byproduct of good architecture rather than through retrofitted controls. This points toward an enterprise where AI executes autonomously across operations, teams own customer outcomes end to end, and leadership governs with AI-assisted insight. Process ontology serves as the architectural foundation that makes it possible.

How process ontology differs from existing process disciplines

Three disciplines are already present in most operator architectures, and each contributes something distinct to how a process ontology is built and operated (Figure 2).

Figure 2. Comparative analysis of process ontology with adjacent process disciplines

Source: Infosys

Process ontology connects these three disciplines by giving them a shared, live, cross-domain runtime to reason and act across end-to-end business processes in real time.

Start narrow, prove fast

Most operators that have successfully built a process ontology started with two of the most business-critical processes: order-to-activate and trouble-to-resolve (Figure 3). The business pain is measurable, the process documentation already exists, and key performance indicator (KPI) gains are visible within 12 months. That proof funds the next stage. The destination is enterprisewide rollout, reached one proven process at a time.

Figure 3. Four-stage roadmap for process ontology implementation

Source: Infosys

Four actions for telecom leaders

Four actions will determine whether the investment compounds or stalls:

Reframe the AI investment thesis

Each dollar invested in the process semantic layer yields more than the same dollar spent on additional data cleansing or model training. The models are already good enough. The substrate they operate on, however, needs improvement.

Build on open standards

Use TM Forum's process framework, open digital architecture — a blueprint for how telecom technology components should be built and connected, and the information framework (SID) as the foundation. Together, they provide a common approach to telecom processes, technology architecture, and data — minimizing vendor lock-in, accelerating integration with existing systems, and positioning the organization for ecosystem interoperability as agent standards mature across the industry.

Embed compliance at the substrate level

Use the ontology as the single source of truth for EU AI Act, GDPR, and NIS2 obligations. Compliance becomes a design property encoded once, not an audit response recreated every time.

Govern the ontology as a permanent product

Appoint a dedicated ontology product owner at the CTO or CDO level. Establish a backlog, KPIs, and a continuous evolution cycle. Operators that treat this as a project deliverable find it drifts within two years. Operators that treat it as a product are still running it three years later.

Why act now: The window is narrowing

The case for moving in the next 18 months is structural and compounding. Every process trace captured becomes training data for future agents, creating a growing advantage that cannot be easily replicated. Operators that act now build a proprietary process-execution capability; those that delay fall behind.

The external environment is tightening too. GSMA, the global mobile industry body, is enabling operators to offer network capabilities as on-demand digital services to enterprises and developers. Each of those requests triggers internal fulfillment, assurance, and billing processes that need to execute automatically in the background. Operators with a process ontology will back those requests with automated, SLA-aware execution. Those without one will rely on manual queues. The difference will be visible to enterprise customers within two to three years and reflected in contract renewals before that.

Looking ahead, next-generation network architectures, including 6G, will treat process-aware autonomous operations as a baseline expectation. Operators that build now inherit a structural head start. Those that wait will spend the following decade trying to retrofit a semantic layer their competitors built while they were still debating whether to start.

This shift marks a fundamental change in how telecom businesses compete. The advantage will come from systems that understand, decide, and act across end-to-end processes in real time — and from building those systems before the window closes.