A telco CDO has spent the last five years modernizing the data architecture. The data lake unified access to CRM, billing, charging, OSS, and network telemetry that used to live in fifteen separate systems. On top of the lake, her team built a semantic layer that standardizes how core metrics are calculated, plus a knowledge graph that maps the relationships between customers, services, contracts, and resources. The API gateway exposes the new platform to applications across the business. The board approved an AI initiative on top. Both the CDO and the CTIO expected this would be the year AI moved from pilot to production.
The first agent demoed beautifully. It fielded inbound care questions, summarized customer history, surfaced the right next product. Production was different. A few weeks in, the agent recommended a mid-term plan upgrade to a customer whose contract forbade it without a penalty. The reference table for plan eligibility was in place. The customer’s contract sat in the knowledge graph. The semantic layer correctly defined “active subscription” and “plan.” The agent still confidently produced the recommendation, because no part of the platform actually evaluated the constraint chain before the recommendation went out. The data was correct. The vocabulary was consistent. The decision logic was missing.
The substrate is wrong for the job. The model is fine. The data is clean. The semantic layer correctly defines what “plan” and “subscription” mean. What none of these layers do is encode the actions an agent is allowed to take, the constraints that govern those actions, and the decision logic that evaluates whether an action is legitimate right now. A data lake, even a modernized one with a semantic layer and a knowledge graph on top, is built to ground analytics and lookup. It is built to do that well. Grounding execution is a different problem.
What CDOs actually built, and why
CDOs invest in data lakes for real reasons. The lake unifies access to data that used to be fragmented across operational systems, and it gives any model, agent, or reporting tool a single place to read from. Most modern lake architectures don’t stop at raw storage. They add a semantic layer that defines what “revenue” means, what “active subscription” means, how customer identifiers reconcile across CRM and billing. Some telcos have even added a knowledge graph that captures the relationships between customers, services, network resources, and contracts. These are real advances. They solve real problems.
But most of these architectures were designed to improve analytics, integration, and reporting consistency, not to create a single operational model of how the telco actually works across systems.
The semantic layer usually standardizes definitions inside the data platform. It does not establish enterprise-wide operational meaning across CRM, OSS, charging, CPQ, provisioning, billing, and network domains in a way AI can reliably execute against.
Gartner’s 2026 Data & Analytics predictions name advances in semantics among the leading trends and identify the semantic layer as required infrastructure for D&A leaders supporting AI. Telcos with mature data programs increasingly run all of it: lakehouse for storage, fabric for integration, mesh for governance, semantic layer for definitions, knowledge graph for relationships. The combination is more capable than a lake alone. The expectation that CDOs and CTIOs carry into the AI initiative on top of this stack is reasonable: if the platform now defines metrics consistently and maps the relationships between business entities, surely AI agents will inherit the same consistency. They will, for analytics. They will not, for action.
What an API gateway is for
The third piece of the modern data architecture is the API gateway. The gateway mediates traffic between systems, manages authentication, applies rate limits, and exposes a developer-friendly surface to whatever lives behind it. A gateway is real infrastructure and most telcos already run one. It anchors the integration story for any platform initiative, and it is the most common place an AI team plugs an agent in.
Like the lake and the semantic layer, the gateway does its job correctly. It transports requests. What it does not do is encode whether a request is allowed to happen right now given this customer’s contract terms, billing-cycle position, network-capacity availability, and active service reservations. The gateway gets the request to the right service. The decision about whether the request should be made in the first place lives somewhere else, or in most stacks, in nobody’s hands.
An ontology is a different category of architecture
If you have already built a semantic layer or a knowledge graph, you have not built a partial ontology. You have built a different thing well. A semantic layer governs how analytics-side definitions stay consistent. A knowledge graph captures how entities relate. An ontology grounds AI agents on the actions they are allowed to take and the constraints those actions must obey. The first two operate on data shape. The third operates on operational behavior. Treating the ontology as the next layer above the semantic layer misses what an ontology is for.
An ontology is a formal framework that defines the concepts, properties, and relationships within a specific domain of knowledge. To ground operational AI, the ontology must operate across three dimensions:
The semantic dimension defines what exists. Customers, accounts, subscriptions, services, resources, policies, and the relationships among them. Reference models like TM Forum SID and the Open API specifications live here. Semantic layers and knowledge graphs operationalize this dimension well. They give AI agents a consistent vocabulary and a navigable map of how entities relate.
The kinetic dimension encodes what can and should happen under specific operational conditions. The set of actions valid in the business: order, amend, validate, reserve, charge, notify, route. The sequences those actions must follow. The constraints that govern when each action is allowed and when it is not. Semantic layers do not encode this. A knowledge graph might describe that a customer has a subscription, but it does not tell an agent that initiating an amendment on that subscription requires the contract terms to permit a mid-term change, the billing cycle to be open, and the network to have the capacity. Those are kinetic constraints, and they live in code scattered across CPQ, order management, charging, and provisioning.
The dynamic dimension is where decisions and learning live. The constraint-evaluation logic that answers the question “can this agent take this action right now, and if not, why not?” The feedback loops that record what worked and what did not, so the model improves with use. Without this dimension, the ontology can describe rules but cannot apply them. The agent still needs a separate decision system for every situation, which puts the substrate problem right back where it started.
Back to the agent receiving the request to upgrade a customer to a faster plan. The lake has the customer’s history. The semantic layer correctly defines what “plan” and “subscription” mean. The knowledge graph maps the customer to their accounts, services, and contracts. The executable ontology adds the layer none of them encode: that mid-term upgrades on this contract require a penalty, that the faster plan needs a network-capacity reservation unavailable in this geography, and that the billing system’s month-end cutoff is in two hours. The agent stops improvising. It either proposes a valid action or explains why none of the obvious actions are valid right now.
Why a sophisticated lake still does not ground action
In most CDO conversations we have in 2026, the default architecture pattern is some combination of: lake, semantic layer, knowledge graph, LLM with retrieval-augmented generation, agents. The pattern works for read-side use cases: summaries, lookups, anything that boils down to retrieving the right historical record or computing a metric. It breaks for write-side use cases, which is anything that requires the agent to take an action across more than one system.
The failure mode is structural. RAG retrieves the contract; the semantic layer confirms what kind of contract it is; the knowledge graph shows the customer’s other active services. None of those layers tell the agent that the contract’s terms forbid the action it is about to propose, because that interpretation is not encoded as evaluable constraints. The interpretation lives in operations people’s heads, in code across CPQ and order management, in policies embedded in the charging engine. The agent has context. It does not have constraint evaluation. So it improvises.
This is why so many telco AI initiatives clear the demo bar and stall on the way to production. The pilot agent answers questions; the production agent has to act, and the substrate underneath it was never built for action. The lake plus a semantic layer plus an LLM is not a wrong architecture. It is an incomplete one. A full ontology, covering not only the semantic dimension but also the kinetic and dynamic dimensions, is the missing piece.
The compounding ceiling
There is a second reason the lake-plus-semantic-layer-plus-LLM pattern hits a ceiling. Every new AI initiative on top has to re-derive the operational semantics from scratch. The care agent’s team builds a constraint validation routine for upgrades. The quote optimizer team builds another constraint validation routine for new sales. The provisioning orchestrator team builds yet another one for service activation. Six months later, three teams have built three overlapping, slightly different, individually fragile interpretations of how the telco actually executes operations.
The lake stayed the same. The semantic layer stayed the same. The AI overhead compounded. This is the architectural ceiling that breaks AI roadmaps in year two, not the data-quality problem that breaks them in year one.
An executable ontology breaks the ceiling because the operational semantics are encoded once, above the lake (or above whatever data sources you have), and made available to every agent. The care agent inherits the same constraint logic that the quote optimizer inherits that the provisioning orchestrator inherits. New agents start with context, not with another integration project.
Where existing investments fit
The executable ontology is data-source-agnostic. If you have a lake with a semantic layer and a knowledge graph, the ontology sits above them and grounds AI agents on the executable dimensions they were missing. If you don’t yet have a lake, you don’t need to build one as a prerequisite for AI. The ontology connects to whatever data sources you operate, the systems of record themselves or the analytics architecture you’ve built on top of them or both. A lake is not the layer that grounds operational AI, regardless of whether you happen to have one.
Evolving the lake stack further, with deeper semantic layers and richer knowledge graphs, does not produce operational AI either. Those investments improve analytics and reporting. The executable substrate AI agents need is a different kind of layer, not a deeper version of the one underneath it.
For the CTIO planning a multi-year AI transformation, this changes what an AI initiative looks like. The investment shifts from another bespoke retrieval pipeline to a reusable semantic and execution layer. The risk profile changes too. Agents that previously had to be hand-coded against each new system can now generate against a shared ontology. The second agent ships in weeks, not quarters. The third agent’s marginal cost approaches the cost of writing the agent’s logic itself, because the substrate is already there.
The realistic outcome
Telcos that have built sophisticated data platforms, with lakes, semantic layers, knowledge graphs, and API gateways, have built genuinely valuable infrastructure. None of that work goes away. What does go away is the assumption that this stack is sufficient for operational AI. AI does not fail because telcos lack data. It fails because the operational decisions that govern the business were never made machine-readable across the estate. The lake handles analytics. The semantic layer handles definitions. The knowledge graph handles relationships. The API gateway handles transport. The executable ontology handles action, and that is the layer most telcos are still missing.
Make AI scale by building the substrate it can act on. The next investment is a different category of layer altogether: an executable ontology that grounds AI agents on the operational decisions your business actually has to make.
About Totogi: Totogi Ontology is a governed, machine-readable layer that sits above your BSS, OSS, and core systems. It enables AI agents to reason safely and act correctly across your entire operational domain. Learn more at totogi.com.
