Telco executives talk about specific ambitions for operational AI. Consolidating two stacks after a merger in months rather than years. Catching network revenue leakage before it reaches an invoice. Closing out a network incident end to end, through to what every affected customer is owed, without a person opening a ticket.
For an agent to carry work like that, it has to know what an operator’s data means, which actions it may take, in what order, and under what conditions. That is a harder requirement than access to data, and no amount of model quality supplies it.
The industry has converged on a name for the missing piece. Over the past year or two, ontology has gone from a niche word to the thing standards bodies, carriers and vendors all now point at as the precondition for AI in telecom. TM Forum has shipped an intent ontology. Carriers have built their own. Vendors increasingly acknowledge they need one.
So an operator that wants AI to act needs a telco ontology. This point has been established already. The open question is whether it builds one or buys one.
Telstra had to build its own
Telstra got there before most. Its engineers were automating service delivery across network domains and needed network knowledge in a form software could reason over, so they went looking for a telco ontology to start from. In the words of the TM Forum case study, “Since none existed, the company created an ontology using the TM Forum Information Framework.” The build began around early 2023 in the fixed-access network and extended from there to enterprise connectivity services, which demand orchestration across several network domains.
What Telstra had to create is what building one means anywhere. A telco ontology holds the nouns, the verbs and the logic: the entities the business runs on, customer, account, subscription, balance, cell site; the actions that can be taken on them, provision, amend, charge, suspend; and the rules, sequences and constraints that decide which action is valid, when, and against what. All of it in a form a machine can read and act on.
Telstra drew that model around the network, and inside the network it did the job. O2 Telefónica Germany built one too, for its transport network. NetOptimizer is a digital twin of its network that maps the status of its mobile sites and transport routes in real time.
Two operators, two builds, one shape. Both models describe the network, and inside the network both of them work.
Your telco product is a cross-system process
Now look at what the operator sells. A 5G network slice, sold to an enterprise customer with a latency commitment and service credits behind it, is never one record in one system. It is a chain of coordinated actions across many. The commercial service sits in the product catalog, the customer and the terms of the service-level agreement in CRM, the price and the configuration in CPQ, and the order in order management. The slice itself lives in the network management system under its own identifier, the Single Network Slice Selection Assistance Information (S-NSSAI), while the rating and the credits sit downstream in charging. Each system holds its own model of the world, and each line between them carries the translation that makes the process work. Integrations carry institutional memory. They encode how the telco actually works, including the messy parts that were never documented properly.
That is the shape an AI agent walks into. Every vendor in that chain is adding AI to its own box, which helps inside that box. The boxes get smarter. The lines stay messy. And in telco, the lines are where the work happens.
Inside one domain, the nouns, the verbs and the logic are clear enough for AI to reason and act safely. That is why Telstra’s model works on the network and Telefónica’s works on transport. Across the estate, the same three stop holding.
Start with the nouns. That one slice is an S-NSSAI in the network management system, a service code in the catalog, and a subscription ID in charging, and nothing forces the three to point at the same underlying thing. Those systems typically come from different suppliers, none of which was built for the other two. TM Forum’s Open APIs exist to close exactly that gap, and operator demand for the standard still runs ahead of what vendors natively support, which is why so many telcos end up wrapping their vendors’ legacy APIs in an Open API layer of their own.
Then the verbs. Raising that slice’s quality-of-service priority is, to the network management system, a routine and reversible change. To charging it is a billable event. To CRM it is a change in what the customer is owed under the agreement. One action, three meanings, and no system that holds all three.
Then the logic. The rules deciding whether the action is allowed at all were mostly never written where a machine can read them: whether this incident has already been credited, whether the contract caps credits inside a billing period, whether raising one customer’s priority on a shared transport path pushes another customer’s slice below its own commitment. Those rules live in integration code, in configuration, in spreadsheets and in the people who have kept the stack alive for a decade.
So take an incident. A slice runs below its committed latency for three hours. An AI agent can’t tell which enterprise customers are affected and what the operator owes them. Every fact it needs is sitting in a system it can already reach. What it has no way to establish is that the S-NSSAI in the network management system, the service code in the catalog and the subscription ID in charging describe one thing, whether this incident has already been credited, and whether raising a credit is a valid action here at all. It can read the estate. It cannot act on it.
What build means
The build path is a viable one, as both the Telstra and Telefónica examples demonstrate. But building an ontology that spans across the estate comes at a cost, and it has four currencies.
Time to market is the first. Part of the timeline is the same on either path: the program needs a business case, and someone has to find out how systems whose documentation stopped being accurate years ago actually behave. Building then adds two stages before any system goes in. The ontology has to be architected and designed, and the platform that runs it has to be engineered. Only then does the operator’s own team start mapping each system into it, one at a time, each with the exceptions that make it a special case. The same team tests the whole thing against real workloads and keeps it true as the estate changes underneath. On top of all of that, four organizations have to agree on one definition of customer, service and charge, because no single team can sign that off.
Talent is the second. The people who do this work are AI and data engineers, and every industry on earth is hiring them at the same time. An operator is bidding for them against the technology sector, against finance, and against every other company standing up an AI program, and telecom is rarely the offer those candidates are holding out for. The colleagues who know why the retired offer is still sitting in the catalog are a different and equally scarce group, senior and already fully booked keeping the estate running.
Experience is the third, and Telstra’s chief architect named it in the 2024 case study: “We had to unlearn behaviors and approach designing networks differently. We had to approach building products differently. We had to think of how we engage our customers differently.” None of that is modeling work. It is an organization changing how it designs, builds and sells, and no schedule survives that intact.
Budget is the fourth, and it is the sum of the other three. A multi-year program, staffed by the most contested engineers in the market, running alongside the roadmap the business is already waiting on rather than instead of it.
That calculation is visible in what Vodafone Germany did. In June 2025 it licensed a knowledge-graph-based semantic modeling solution in order to create a detailed digital twin of its network and services. The solution is aimed at automating assurance and fulfillment tasks, assessing service impact, root cause analysis, smart network planning, security, and optimization. It was bought with agents already in view: the model was aimed at letting large language models “interact meaningfully with structured network data” to support the evolution toward autonomous network operations.
What that license bought is a single domain, the network, the same boundary Telstra and Telefónica drew by hand. Buying it outright at that scope, with a network organization of that size in the building, is a fair measure of what the four currencies come to.
What is there to buy
Buying is real, and what is on sale comes in four shapes.
The first is a semantic layer sold as an ontology. A vendor takes a data model, a set of data structures or the integration mappings it has refined over many years, and repositions the whole thing under the newer label. These are genuinely useful. They improve consistency, they cut integration friction, and they give AI a cleaner picture of what exists. What they do not carry is what may happen: the actions, the sequences and the constraints that decide whether a change is permitted. A model that defines meaning without governing behavior lets software read the estate and stops there. We wrote up how to tell the difference, and what to ask a vendor, in our guide to evaluating ontology claims.
The second is a vendor’s ontology of its own product. These are real and they are executable: the objects, the lifecycle states, the actions and the conditions of that vendor’s own stack, accurate and well maintained, because its maker controls everything the model describes. That is also where it stops. It cannot govern the systems around it that its maker does not own, did not build and cannot be held to. An operator with a multi-vendor estate that buys one has bought a well-described island.
The third is a domain ontology that spans vendors inside a single domain. The network digital twins are this shape, whether built like Telstra’s and Telefónica’s or licensed like Vodafone Germany’s. Of those three, this is the most valuable to an operator, and it is also where the ceiling sits, because the slice question crosses out of the domain on its way to an answer.
The fourth is the Totogi Ontology.
The Totogi Ontology
An ontology worth buying has to pass three tests. It spans domains rather than a single system. It encodes actions and constraints as well as entities. And it stays independent of the vendor systems underneath it.
The Totogi Ontology is built for the case the other three leave open: one model across the whole estate, independent of any single vendor inside it. It goes in as an overlay. The point is not to rip out CRM, billing, charging, CPQ, order management or the network systems, but to make the estate they add up to intelligible enough that AI can operate across it safely.
It works in three layers.
The data layer connects to the systems the operator already runs, across CRM, billing, charging, catalog, ordering, care, data lakes and network systems. It does not try to standardize them. It reads how each one actually represents the things it holds, so the model is built from what the estate does rather than from what its documentation claims.
The ontology layer is the model itself, and it is where the work happens. The nouns, defined once with their relationships: customer, account, subscription, service, balance, cell site, slice. The verbs that can be applied to them, provision, amend, charge, suspend, credit, each with the sequence it has to follow and the constraints that govern it. And the logic that decides which action is valid, when, and against what. It is grounded in TM Forum SID, ODA, eTOM and 3GPP, then extended with each operator’s own specifics, because the standards describe the industry while the extensions describe this telco.
The AI layer uses that model as ground truth. Agents, copilots and automation flows stop integrating with fifty systems each and talk to the ontology instead, which already knows how to read from and write to those systems and which actions they will accept. Any agent, any LLM and any vendor’s AI tooling can plug into the same substrate, and they stay interchangeable, because the operator’s knowledge sits in the model rather than inside somebody’s agent runtime.
That changes the shape of the integration problem. Instead of every system connecting to every other, each one maps to the ontology once, so complexity grows in a line rather than a square, and the tenth use case does not start from zero.
The model has to work across three operating dimensions for any of that to hold. Semantic covers what exists and how it relates, which is the nouns. Kinetic covers what can happen, in what sequence and under what constraints, which is the verbs and the logic. Dynamic is where options are weighed against those constraints, actions are taken, and outcomes come back and improve the next decision.
Run the slice incident through it and the agent has what it was missing. One definition of that slice, so the S-NSSAI, the service code and the subscription ID resolve to the same thing. One record of what has already been credited. One statement of whether a credit is a valid action here, and at what point it stops being one.
Delivery is hands-on. Totogi implements it with the operator, because the model has to match the estate in front of it, and an architect weighing this against a multi-year internal build should know who does that work.
Where to start
The boundary an operator draws around its model becomes the boundary of what its AI can do.
None of which argues for modeling everything at once. Dr. Lester Thomas, Vodafone Group’s head of new technologies and innovation, put the case for small scope directly in June 2025: “Using those small, structured ontologies, and almost forcing a standard way of speaking, might be necessary in order to use Gen AI on things which are mission critical.” On the prescription he is right.
Start with one hard problem, and pick one that already runs between systems. Count the systems standing between the question and its answer, and draw the model around all of them.
About Totogi: the Totogi Ontology is a governed, machine-readable layer that sits above your CRM, product catalog, CPQ, charging, billing, core and network systems. It gives AI agents one executable model of how your telco works, so they can reason across the whole estate and act on it safely. Learn more at totogi.com.
