The execution gap

The mechanism: why agents specifically fail

The scale of the problem and the stakes explain why this is an expensive problem, but they do not explain why AI agents fail in production. Consider a mid-contract plan change for an enterprise customer. The request touches CRM for the account, CPQ for the commercial terms, the product catalog for the new plan definition, the charging engine for rating, billing for the invoice cycle, provisioning for activation, and the network layer for capacity. Six to ten systems support one action that the customer experiences as a single click. Each of those systems holds its own version of what is true and what is allowed, and the coordination between them lives in integration code and runbooks, not in a shared model.

This is semantic fragmentation: the same word carries different meaning in different systems. An “active subscription” in the CRM is a different state from “active” in the charging engine. A customer identity in billing reconciles imperfectly to the identity in care. A catalog product becomes a billable rate plan through a translation that exists only as integration code and tribal knowledge. For two decades this was a cost-and-speed problem, slowing launches and turning every modernization into a translation exercise. Agentic AI changes the severity. A dashboard built on a fragmented estate is wrong in ways a human analyst can catch. An autonomous agent acting on that same estate is wrong in ways that reach the customer, the invoice, and the network before anyone notices. The tolerance for fragmentation falls to near zero the moment a machine is allowed to act on its own conclusions.

The specific failure is constraint blindness. The agent has all the data needed: it can see the customer history, the contract document, the catalog of plans, the current network state. What it lacks is constraint evaluation, a way to determine whether a specific action is legitimate right now, given all of those facts at once. So it improvises, producing a confident, well-formed recommendation that happens to violate a contract clause, a billing-cycle rule, or a capacity reservation, because nothing in its substrate evaluated the constraint chain before the recommendation left the building. The model is doing exactly what it was built to do. The substrate beneath it was built for analytics and lookup, and it is being asked to ground action.

The operators reading this have already built sophisticated platforms and adopted modern patterns. The relevant question is whether those investments ground confidence in execution. For three serious approaches, the honest answer is no.

The mature data lake stack

The default architecture in serious operators today is a layered platform: a lakehouse for storage, a data fabric for integration, a data mesh for governance, a semantic layer that standardizes how core metrics and entities are defined, and a knowledge graph that maps the relationships among customers, services, contracts, and resources. A large language model with retrieval-augmented generation sits on top, and agents sit on top of that. This is real, capable infrastructure, and the architect who built it has done serious work. Gartner reinforces its value, treating a universal semantic layer as a “non-negotiable foundation” for data and analytics leaders supporting AI and predicting it will be treated as critical infrastructure by 2030; 44 percent of such leaders have already implemented semantic layers and another 48 percent plan to by 2027.15

The stack excels at read-side work: summaries, lookups, metric computation, anything that resolves to retrieving the right historical record or calculating a number from clean definitions. The semantic layer keeps the numbers consistent, the knowledge graph keeps the relationships navigable, and RAG retrieves the relevant document. For analytics, it delivers.

Write-side work is a different job, and this is where the category of the stack shows. A semantic layer governs data shape; operational behavior is a separate concern it was never built to hold. RAG retrieves the contract, the semantic layer confirms what kind of contract it is, and the knowledge graph shows the customer’s other services. The interpretation that the contract’s terms forbid the action the agent is about to propose was never captured as evaluable constraints, so none of those layers can apply it. The agent has context and still lacks constraint evaluation. Gartner’s own field evidence underlines the limit: retrieval-augmented assistants and agents “often underperform when scaled across diverse enterprise information,” primarily because of data-source quality and retrieval relevancy.16 Retrieval brings back documents. Deciding whether an action is allowed is a different operation.

More middleware, more APIs, more orchestration

The instinct of a standard telco is to close the gap with more integration: add an API gateway, expose more services, stand up an orchestration layer that calls them in sequence. The gateway is real infrastructure that most operators already run, and it is the most common place a team plugs an agent in. It mediates traffic, manages authentication, applies rate limits, and exposes a clean surface to whatever sits behind it.

The gateway transports a request; whether that request is allowed to happen right now, given this customer’s contract terms, billing-cycle position, and network-capacity availability, is decided elsewhere, and in most stacks nowhere at all. The deeper problem is arithmetic. Point-to-point integration scales quadratically: connecting a new system to an estate of n systems can require on the order of n new integrations, and each one re-encodes a slice of operational logic that nothing else can reuse. Integration becomes a quarterly cost that compounds, while the capability velocity the business actually wants, new agents and new automations, is measured in months. Adding integration to close an execution gap tends to widen it.

Reference-only ontologies that stop at the semantic dimension

A third response is to buy the label. “Ontology” has become a marketing term in telecom, and interest in it has climbed sharply over the past two years. The risk is ontology theater: adopting the word faster than the capability behind it. Many vendor offerings described as ontologies turn out, on inspection, to be a reference layer that defines entities and relationships, a richer map of what exists in the estate. Gartner’s warning about “agent washing,” the rebranding of existing automation as agentic, describes the same dynamic one layer up.17 The label moves faster than the substance.

Acting on the environment safely is a separate capability that a definitions-only model leaves out. Here the legal analogy earns its keep, used once. A statute opens with a definitions section that fixes vocabulary, what “person,” “property,” and “tenant” mean. That section is necessary, and it is the glossary, not the law. The law lives in the articles and clauses that govern behavior and enforce constraints, what a party may and may not do and under what conditions. An ontology that stops at definitions has written the glossary and skipped the statute. It tells an agent what a subscription is. It leaves out that amending this subscription requires the contract to permit a mid-term change, the billing cycle to be open, and the network to have capacity. That gap is the difference between a model that describes and a model that can be trusted to act.

The independent evidence that retrieval and protocol alone are insufficient is worth holding together at this point, because it forms a consistent picture. Gartner expects 60 percent of MCP-only agentic analytics projects to fail without a consistent semantic layer.18 Gartner finds RAG underperforming at enterprise scale.19 Both point the same way: plumbing and retrieval move data and documents, and grounding action takes a model of meaning and behavior that sits above them.

If you have built a semantic layer and a knowledge graph, you have built a different thing, not a partial ontology. An executable ontology is a different category of architecture from a data platform.

It sits in the estate to do a different job: a semantic layer governs data shape, and an ontology grounds operational behavior. An operator needs both, because they answer different questions. Evolving the lake stack further produces better analytics; operational AI comes from a model built for behavior.

An ontology is a formal model of the concepts, properties, and relationships within a domain, and this is not a novel or proprietary idea. The World Wide Web Consortium standardized OWL 2 as a description-logic-based language for defining ontologies with formal semantics that enable machine inference.20 Ontologies rest on a mature, vendor-neutral open standard. The question for telecom is what an ontology has to cover to ground operational AI, and the answer is three operating dimensions.

The semantic dimension defines what exists: customers, accounts, subscriptions, services, resources, policies, and their relationships. The reference models, TM Forum SID and the Open API specifications, live here. Semantic layers and knowledge graphs operationalize this dimension well, giving an agent a consistent vocabulary and a navigable map. This is the dimension most vendor ontologies stop at.

The kinetic dimension encodes what can and should happen, and under what conditions: the set of actions valid in the business, order, amend, validate, reserve, charge, notify, route; the sequences those actions must follow; and the constraints that govern when each is allowed. A knowledge graph can record that a customer holds a subscription. The kinetic dimension records that amending that subscription requires the contract to permit a mid-term change, the billing cycle to be open, and the network to have capacity. Today that logic lives scattered across CPQ, order management, the charging engine, and provisioning. Encoding it once, where every agent can read it, is the heart of the operational layer.

The dynamic dimension is where decisions and learning live: the constraint-evaluation logic that answers a single question, can this agent take this action right now, and if not, why; and the feedback loops that record what worked so the model improves with use. Absent this dimension, the ontology can describe rules but cannot apply them, and every situation needs a bespoke decision system, which reproduces the original problem in new clothing.

A reference layer helps systems read the environment; an operational layer lets systems act on it safely. The dividing line is exactly whether the model spans all three dimensions or stops at the first. The phrase that captures the design goal is the lines, not the boxes: a machine-readable model of how the real-world telco behaves between its systems, instead of another inventory of the systems and their contents.

The evidence that grounding works

A peer-reviewed survey in the ACL Anthology concluded that augmenting language models with knowledge graphs as external knowledge “has demonstrated promising results” for mitigating hallucination and improving reasoning.21 The size of the effect, where it has been measured cleanly, is large. A peer-reviewed study in the Journal of Biomedical Informatics reported that an ontology-grounded knowledge-graph framework built on RDF and OWL reached 98 percent accuracy on clinical questions and cut the hallucination rate to 1.7 percent, against roughly 37 to 52 percent accuracy and 48 to 63 percent hallucination for general language models on the same task.22 That is a clinical-domain result, and the magnitude is what carries across: grounding a model in a formal ontology moved it from unreliable to dependable on a high-stakes question set.

A systematic comparison points the same direction. GraphRAG outperforms standard RAG on multi-hop, reasoning-intensive queries, improving one multi-hop benchmark from 30.7 to 50.6 percent and answering 13.6 percent of multi-hop queries that plain RAG could not reach, while plain RAG stayed stronger on single-hop lookups.23 That result maps cleanly onto the read-side and write-side split running through this paper: retrieval handles single-hop lookup well, and chained, relational reasoning, the kind a cross-system action requires, needs a structured model underneath.

The combined picture is consistent. Independent analysts say a semantic foundation gates agentic outcomes. Peer-reviewed and preprint research shows that grounding a model in a formal ontology or graph sharply improves reasoning and reduces hallucination. The mechanism that telecom needs for safe cross-system action is the same mechanism these studies validate in other domains, applied to the operational behavior of the estate.

The Totogi Ontology implements the operational foundation as a three-layer architecture that overlays the existing BSS, OSS and network estate.

The data layer connects to the systems already running and extracts operational truth from them: schemas, configurations, mappings, and process artifacts. It reads the CRM’s data model, the charging engine’s rate-plan configuration, the catalog’s product definitions, the order-management workflows. It leaves the systems where they are and assumes no lake. Where a lake exists, the data layer can read from it; where one does not, it reads the systems of record directly. That is what makes the overlay data-source-agnostic.

The ontology layer is the differentiator, the machine-readable model of the real-world telco: the entities, the actions, the constraints, the sequences, and the validity rules, spanning the semantic, kinetic, and dynamic dimensions. This is where a catalog product, a charging rate plan, and a CRM subscription are reconciled into one model of what the thing actually is and what may be done with it. It holds the operational decisions that previously lived only in integration code and in people’s heads.

The AI layer is where ontology-aware agents plug in. These agents do three kinds of work: they generate the mappings between systems and the ontology, they validate proposed behavior against the model before anything executes, and they orchestrate actions across systems safely. The agents share one model, so no agent carries a private copy of the rules. They query the shared ontology for validity, so the intelligence lives in the layer and is inherited by every agent built on it.

The care upgrade example

Return to the agent fielding a request to upgrade an enterprise customer to a faster mid-term plan. In the lake-plus-semantic-layer world, the agent can see the history, the contract, the catalog, and the network state, yet cannot evaluate whether the upgrade is legitimate, so it confidently recommends an action that violates a penalty clause the contract carries for mid-term changes.

With the ontology in place, the request becomes a deterministic validity check. The ontology evaluates the constraint chain. The contract permits a mid-term amendment only with a penalty, so the action carries a cost the agent must surface rather than hide. The faster plan requires a network-capacity reservation that is unavailable in this geography this month. The billing engine’s month-end cutoff is two hours away, which constrains when the change can post. The agent returns one of two outcomes: a valid action it can take now, or a clear explanation of why none of the obvious actions are valid right now and what would have to change. The business outcome is an agent that can be trusted to act without a human re-checking every move, which is the only version of an agent that actually reduces cost.

The quote-to-order validation case

The same machinery handles quote-to-order, where significant revenue leaks today. An enterprise quote assembled in CPQ has to be a valid order in the catalog, a ratable configuration in charging, and a provisionable service in the network. Order fallout happens when a quote passes CPQ’s own checks and then fails downstream, because CPQ never knew the downstream constraints. With the ontology, the agent validating the quote checks it against the same shared model that governs catalog, charging, and provisioning before the order is submitted, so invalid configurations are caught at quote time and prevented by design instead of discovered as fallout days later.

The compounding ceiling, reversed

The lake-plus-LLM pattern breaks in a second way, beyond the constraint blindness described earlier, and this one is structural. It surfaces in year two rather than year one. Every new AI initiative re-derives the operational semantics from scratch. The care team writes constraint logic for upgrades; the sales team writes different constraint logic for new quotes; the provisioning team writes a third version for activation. Six months in, three teams maintain three overlapping, slightly inconsistent, individually fragile interpretations of how the telco executes. The data platform has not changed, and the AI overhead has compounded.

Encoding the operational semantics once, in the ontology, reverses that arithmetic — it compounds intelligence instead of complexity. Encode once, build anywhere. The care agent, the quote agent, and the provisioning agent inherit the same constraint logic, the same action vocabulary, and the same validity checks. A post-merger one-bill agent, which has to reconcile two billing systems and two customer identities into a single statement, draws on the same ontology foundation as the care agent. The second agent ships in weeks rather than quarters, and each additional agent’s marginal cost falls toward the cost of its own narrow logic, because the substrate is already there. AI without context is just automation, and the ontology is what supplies the context, once, for everything built on it.

This is an overlay throughout. Totogi Ontology connects to what already runs, maps each system into the model once, and leaves the systems of record in place. It restores interoperability and makes AI operational without a migration onto a new stack.

The results below come from Totogi customer engagements and are cited as reported by Totogi, with forward-looking expectations flagged explicitly. They are kept separate from the independent research above, which establishes the mechanism; these establish what the mechanism has produced in operator environments. Several engagements pre-date the current product name and were published under the legacy name BSS Magic; they are mapped here to Totogi Ontology.

Migration is the clearest demonstration that mapping a system into the ontology, instead of rebuilding its integrations by hand, compresses timelines. At a Tier-1 North American mobile network operator, a billing-system migration of the kind that typically takes four to eight months was completed in 14 days, with 18 interfaces auto-mapped and zero downtime reported, alongside roughly 75 percent lower annual system cost. The speed traces to the mechanism: the ontology auto-maps interfaces because it already holds a model of what each interface means, so the translation work that normally consumes the bulk of a migration is done once rather than re-derived by hand.

Standards certification shows the same pattern. Working with CloudSense, a CPQ platform, TM Forum Open API certification across 13 APIs was completed in 30 days, against an estimated 26 months for the traditional path. That 26-month figure is the vendor’s baseline assumption for the conventional route rather than an audited industry benchmark, and is cited here on that basis. The reduction is large because conforming a system to the Open API specifications is fundamentally a semantic translation problem, which is exactly the work the ontology exists to do once.

On the execution side, a major multi-play operator serving millions of customers across Southeast Asia reduced CPQ order-creation time by more than 80 percent by embedding an AI agent in Salesforce, deployed in four weeks or less. Quote failures put the cross-system validity check on display: at a Tier-1 multinational quad-play CSP, after an acquisition destabilized its CPQ stack, an AI agent went live in seven days, cleared the existing backlog in under 24 hours, and reduced per-case fix time from around an hour to under 30 minutes.

The operational layer reaches the network as well as the commercial estate. At a Tier-1 EMEA operator, the ontology reduced alarm noise by 97 percent by correlating alarms across RAN, power, and transmission into fewer incidents that operations can act on. One result is explicitly forward-looking: StarHub, a CSP in Southeast Asia, expects up to a 10 percent improvement in enterprise sales conversion and a 50 percent reduction in sales-training time once the deployment is fully in place — projected outcomes stated by the operator, not results achieved.

The most important implementation fact is the one most likely to be misread. The ontology is an overlay, and it is data-source-agnostic.

An operator with a lake, a semantic layer, and a knowledge graph keeps all three; the ontology sits above them, reads what it needs, and grounds agents on the dimensions those investments do not cover. An operator without a lake does not have to build one first. The ontology connects to whatever data sources exist, the systems of record themselves, an analytics platform on top of them, or both. A lake is neither a prerequisite for the ontology nor a competitor to be torn out.

What to map first

Modeling the entire estate before delivering anything is the wrong instinct. The right first move is to pick a strategic and high-friction cross-domain workflow, one where order fallout, manual translation, or constraint errors cost a lot today, and map the systems that workflow touches into the ontology. Quote-to-order is a common starting point because the pain is acute, the systems involved are well understood, and the validity check delivers visible value quickly. Each subsequent workflow reuses the systems already mapped, which is where the compounding works in the operator’s favor.

Governance and traceability

When meaning is negotiable, governance becomes policy theater, because there is no enforceable foundation to govern against. The ontology makes the operational model the single thing governance acts on. Because it evaluates constraints explicitly instead of burying them in code, every agent decision is traceable: an action was permitted or refused because of a specific named constraint, and that reasoning can be logged, audited, and shown to a regulator or an internal risk function. This is what makes autonomous action acceptable to the parts of the organization whose job is to withhold approval.

It also speaks directly to a measured barrier. Capgemini’s research finds 71 percent of organizations saying they cannot fully trust autonomous agents and only 46 percent holding AI governance policies.24 An agent that can explain why it refused an action is governable in a way that an improvising agent is not, which is the practical route past that trust barrier.

Standards alignment is table stakes, carried inside the ontology

This is where many architects will want precision, so it deserves care. TM Forum’s SID, Open APIs, ODA, and eTOM, together with the 3GPP specifications, are the shared language of telecom interoperability, and any serious operational layer has to align with them. The SID provides a shared information model for entities. The Open APIs provide standard interfaces. ODA describes a component architecture. eTOM describes process. The 3GPP specifications govern the network and its charging and policy interfaces.

The ontology carries these standards as semantics, and that alignment is genuine and necessary. It is also where the limit of standards alignment has to be stated, because conflating alignment with sufficiency is a common error. The standards describe what entities and interfaces should look like in a conformant world. By themselves they do not encode the kinetic and dynamic dimensions of a specific operator’s estate: the particular constraints this operator’s contracts impose, the specific sequences this operator’s provisioning requires, the actual reconciliation between this operator’s catalog and this operator’s charging engine. Two operators can both be SID-aligned and still execute completely differently. Alignment to the standards belongs inside the ontology and stands as table stakes, not a substitute for it. An operator that has invested heavily in TM Forum conformance has done valuable work on the semantic dimension and still has the kinetic and dynamic dimensions ahead of it.

This framing also aligns with where the analysts point. Gartner’s guidance through this period is to invest in foundations and AI-ready data rather than in more models.25 An ontology that carries the standards and adds the operator’s executable behavior is precisely that kind of foundation.

An operator that puts an executable ontology in place gains agents that can be trusted to act across systems, migrations and integrations that compress because the translation work is done once, cross-domain workflows such as quote-to-order validated before they fail, and a governance posture where every automated decision is traceable to a named constraint.

Scope matters, and the honest claim is the durable one. Totogi Ontology removes specific categories of friction and makes AI safe to act across systems. It does not erase a multi-year transformation, and it should be bought with that in mind. The estate still has to be operated, modernized, and governed. What changes is that the semantic-translation work, the part that consumed the majority of delivery time and blocked AI from acting, stops being redone for every project and becomes a reusable capability. Modernization stops being a project and starts being a capability.

The agents stalled between pilot and production are waiting for a machine-readable model of the operational decisions the business actually has to make. The measured failure data says the foundation beneath the model is the missing piece, the academic evidence says a structured, grounded model is what closes that gap, and the operator results say the gap can be closed in weeks rather than years on the workflows that matter most. That foundation is a different category of layer from the data platform operators have already built well, and it is the layer most are still missing.