Sebastian Barros Newsletter

Sebastian Barros Newsletter

Your Telco Has an AI Strategy. Does It Have an Ontology?

Why ontology is becoming the missing architecture between telecom data, AI reasoning and autonomous action

Sebastian Barros's avatar
Sebastian Barros
Aug 31, 2026
∙ Paid
Story pin image

Every telco wants AI agents. Marketing wants one to reduce churn. Care wants one to resolve complaints. Finance wants one to optimize investment. The NOC wants one to find root causes. RAN wants one to optimize performance. There is only one problem. None of them necessarily agree on what a customer, service, network problem, or even revenue actually means.

Giving them more data will not solve it. An LLM can read millions of records and an agent can call thousands of APIs, but neither inherently knows that Customer A owns Product B, which contains Service C, which depends on Resource D, which is currently affected by Alarm E, while Policy F prevents the obvious corrective action. Data contains the values. Ontology gives those values meaning, relationships, and constraints.

This is no longer semantic web bullcrap. In June 2026, TM Forum published TR326, proposing a layered semantic architecture for AI-native autonomous networks to enable runtime contextual reasoning, semantic interoperability, and explainable operations. Telstra has already built a Knowledge Plane around a telco ontology derived from TM Forum SID, while TM Forum’s 2026 A2A T work combines agents with knowledge graphs because agents from different vendors still struggle to share operational meaning.

This points to a much larger architectural shift driven by AI. The model is not the brain; the agent is not the brain; APIs are not the brain. The brain starts with the semantic representation of the Telco itself.

If your AI strategy includes models, agents, RAG, APIs, and data lakes, but no one can show you your ontology layer, you may not have an AI architecture yet. You may simply have a collection of AI projects.


Data Is Not Context

Telcos have spent years centralizing data, building lakes, exposing APIs, and creating increasingly sophisticated analytics platforms. None of that creates a shared understanding of the business.

A data platform can tell an AI system that CUST_98211, SRV_4482 and CELL_319 exist. An ontology indicates that one is an enterprise customer, another is a service contracted by that customer, and a third is a network resource supporting that service. It can also specify that the service has an SLA, that certain faults constitute degradation, that specific policies restrict the actions that can be taken, and that an outage affecting this resource has commercial consequences.

That difference becomes critical when AI moves from prediction to decision-making.

This post is for paid subscribers

Already a paid subscriber? Sign in
© 2026 Sebastian Barros · Privacy ∙ Terms ∙ Collection notice
Start your SubstackGet the app
Substack is the home for great culture