Recorded June 2026

The model was never the problem

The telecom industry has moved past the question of whether AI works in a demo and into the harder question of whether it survives production. The data on that second question is now measured, and it is sobering.

Gartner forecasts that at least 30 percent of generative AI projects will be abandoned after proof of concept, and that more than 40 percent of agentic AI projects will be canceled by the end of 2027. MIT’s Project NANDA reports that roughly 95 percent of enterprise generative AI pilots deliver no measurable business return.

These failures share a cause, and the analyst and academic consensus is consistent about what it is. The barrier sits in data-accessibility, context, and integration, not in the model. Gartner attributes project failure to the absence of AI-ready data and integration infrastructure. MIT names brittle workflows, weak contextual learning, and flawed enterprise integration. A stronger model does not close the gap, because the missing piece is the foundation beneath the model.

Telecom faces the hardest version of this problem. A communications service provider (CSP) runs six to ten interconnected systems for any cross-domain action, including CRM, billing, order management, product catalog, CPQ, charging, the 5G core, provisioning, and more. The operational rules that decide what an agent is allowed to do right now, given a customer’s contract, a billing cycle, and a network’s capacity, live in code, configuration, customizations and the heads of operations staff. No layer holds those rules in a form an agent can evaluate before it acts.

REGISTER TO DOWNLOAD -

In the age of AI, where decisions get made is changing. Telcos are moving them out of human hands and code, and into models and agents. But is that the right place?

This is a question for your board, not your IT department. Because where decisions live determines how badly things break, how fast you can move, whether AI acts on your behalf, who controls your business logic, and whether your organization compounds knowledge or loses it. It determines if you are AI-native, or AI-abled.

Decisions inside enterprises can live in four possible places: in humans, in code, in inference, and in an ontology. You’ve been in the first two for decades. You’re considering the third. But I’m going to make the case for the fourth: an ontology. Here’s why.

1. Minimize the impact of wrong decisions.

When a human customer service agent makes a wrong decision, it affects one customer. When code is wrong, it’s worse. A miscoded eligibility rule would apply the wrong logic to every subscriber who hits it, silently, for months, until someone notices. That’s a slow, concealed blast radius. Unfortunate, but manageable.

When an AI model infers a wrong decision at runtime and executes it autonomously, it affects thousands of accounts in seconds. That’s a huge blast radius. The agent queries your BSS APIs, gets data back in three different schemas with three different definitions of “customer,” resolves the contradictions, and picks an action. Every step is probabilistic. Every step can hallucinate. And the impact of a wrong inference on an operational decision—misbilling, misprovisioning, a wrong offer applied across thousands of accounts—is orders of magnitude worse than anything that came before. It’s the automation of mistakes at scale.

With the Totogi Ontology, the decision that provisions a service, applies a credit, or changes a billing record never touches inference. Business rules, eligibility constraints, valid state transitions are deterministic—which means they’re known, correct by construction. Decisions are defined. With an ontology, the blast radius is zero, because it literally cannot execute wrong decisions. They’re architecturally impossible.

2. Increase your agility.

Encoding decisions in software takes six months. Decisions coordinated by humans take two to four weeks to execute. And decisions in inference? When your business rules change, the model doesn’t know. It was trained or prompted on the old rules. There’s no single place to update. You just retrain, reprompt, and hope the model picks up the change. None is compatible with an AI-native telco.

When decisions live in the Totogi Ontology, they’re updated once and reflected everywhere instantly. A new eligibility rule, a changed margin constraint, a modified state transition: update the ontology and every agent, every workflow, every system that touches that decision sees it immediately. One update happens everywhere, immediately.

TM Forum’s survey of 110 operators across 72 companies found that 95% believe intent-based operations is the future but 58% say they lack the stack to get there. Your BSS/OSS stack is the bottleneck—not the network. Decisions are trapped in code and humans that can’t move at the speed AI demands.

3. Act quickly, every time.

The real cost of decisions living in the wrong place is your AI becomes a recommendation engine. It generates an insight. A dashboard displays it. Nobody acts on it—or five teams spend a month acting on it manually and by then the subscriber has churned. You haven’t transformed your telco; you’ve built a(nother) recommendation engine everyone might not follow.

Telcos have scaled only 26% of predefined AI use cases despite having more data than most industries. The other 74% is trapped, because decisions live in places AI can’t reach.

When decisions live in the Totogi Ontology, the insight-to-action gap collapses. The model identifies churn risk, the ontology resolves what actions are valid for that subscriber, and the system executes in seconds, not weeks. That’s the difference between AI that advises and AI that operates.

And it changes what you can build. A retention offer engine that used to take six months of requirements gathering, data mapping, and integration development? That can turn into describing what you want in natural language and the ontology already knows what those concepts mean, how they relate, and which systems to orchestrate. The backlog of “someday” becomes something that can be done “today.”

4. Take ownership of your business logic.

If decisions live in vendor code, the vendor controls your business logic. If decisions live in consultant knowledge, the consultants are irreplaceable. Right now, most Tier-1 telcos are paying both.

And if decisions live in inference, you can’t explain them. If a regulator asks why that offer was applied to that subscriber, all you can say is that the model inferred it. There’s no audit trail, no version history, no logic you can point to. Try explaining a probabilistic decision to a compliance team.

When decisions live in the Totogi Ontology, you control the business logic. Every decision has a clear audit trail: this rule, this constraint, this state transition, applied to this subscriber, at this time. Plus, swapping a vendor becomes a configuration change, not a three-year program.

5. Compound organizational knowledge. 

When decisions live in humans, you create tribal knowledge that walks out the door. Decisions in code fossilize. Decisions in AI inference reset to zero with every query, because the model doesn’t learn from last Tuesday’s retention offer.

The Totogi Ontology compounds. Every action enriches it. Edge cases reveal gaps in entity definitions. Success and failure data improves decision logic. Invalid attempts expose missing business rules. Every decision makes the next decision better. Every exception becomes a searchable precedent instead of a Slack thread that disappears. The Totogi Ontology is a living system.

Wait, I thought inference was awesome?

Given all this, why are vendors pushing you to put decisions in inference? Because it keeps your business logic trapped. When decisions live in the model, you still need their consultants to retrain, reprompt, and reintegrate every time a business rule changes. Amdocs generated 66% of its revenue from managed services in 2025. Those consultants exist because your systems don’t speak the same language—by design. An operational ontology like the Totogi Ontology makes that translation layer unnecessary. They will never recommend that.

So where should you use inference? Everywhere else. Generating the communication to the subscriber. Identifying churn risk. Recognizing anomalies. Ranking the best option among the ones the ontology already validated. Creating new workflows from natural language requirements.

Inference is powerful. You want it working hard across your business. You just don’t want it making the decisions that provision, bill, or change a subscriber’s account. The Totogi Ontology constrains the decision space. Inference supports it.

When we show operators the Totogi Ontology—the actual model of their entities, constraints, and valid state transitions—they instantly get it. It stops being a concept and becomes the control system they want to run their business.

How exciting is the promise of AI? I talk to telco CIO after CIO who can finally see a path out of paying for every single change to their BSS/OSS systems. They see a way to write their own systems and free themselves to move more quickly to support the business and subscribers.

But watch out. CIOs are about to repeat the same pattern that got them into the consulting trap in the first place—just with a layer of AI on top. The key is making the right architectural decisions.

What is a change request, anyway?

Let’s strip a telco change request down to the most basic work being done. There are six steps:

1. Read the request in English.
2. Figure out which systems need to change.
3. Translate between the systems’ definitions of customer, product, and state.
4. Write the code to bridge the gaps.
5. Test the code.
6. Document what was done (hopefully).

In 2020, a team of humans was required for each of those six steps. Now, with the capabilities of the frontier models improving every day, let’s look at the six steps in 2026:

1. AI reads and comprehends English faster than humans.
2. AI maps intent to APIs against a structured object model, if it has one.
3. AI translates between fragmented systems instantly, if the architecture underneath lets it.
4. AI generates the code at superhuman speed.
5. AI tests the code at a scale no human team could match.
6. AI writes the audit trail as it works.

Steps 1, 4, 5, and 6 are no longer interesting questions. Models comprehend English. Code generation, automated testing, and audit trails are a given. Any team building on modern AI infrastructure gets them for free.

Steps 2 and 3 are where the real work happens. Mapping to the right systems and translating between their fragmented definitions are the two things AI still needs help doing. The reason is structural: AI models reason over patterns in language, not over grounded truth about your business. Without an underlying structure that tells the model what your systems actually mean to each other, the model will hallucinate about your operations. Get this right, and the other four steps are easy. Get it wrong, and you’ll be back to needing humans for everything.

Getting it right

You may think the right move is building an agentic system—by putting your business logic into a series of agents. Most vendors in telco are pitching that today. Their agents understand their rules and their systems, so to the naked eye, it may seem like the right choice.

But it’s the wrong move.

Start with what an agent actually is. An agent is a reasoning capability. It takes inputs, applies logic, and produces outputs. It is not a knowledge store. When you put your business logic inside an agent, you’re conflating two different things: the reasoning that interprets a situation, and the knowledge that defines what your business actually is. Confuse those two, and every problem with agent-based architectures follows automatically.

Think about what putting business logic inside agents actually commits you to:

1. Every agent you deploy contains business logic and rules.
2. Every agent needs its own copy of every rule it touches.
3. When a rule changes, you need to propagate it to every agent that holds it—or the agents drift apart.
4. Agents reasoning about the same customer return different answers at runtime.
5. Swapping one agent vendor for another means re-encoding all the rules that live inside the agent.
6. The vendor that ships the agent owns the rules inside it—and charges you to change them.

Now do the math. You have four hundred BSS/OSS systems per telco. You’re likely going to deploy hundreds of agents. The coupling between agents and rules grows as a product, not a sum. Instead of freeing yourself from vendor lock-in, you’ll replicate it across every agent you deploy, multiplied by every rule you carry. You haven’t escaped the consulting bill. You’ve relocated it. You’ll have moved critical business knowledge from your applications into your agents—and added a new complication on top: the cost of keeping all your agents synchronized.

The answer: an ontology

The right architecture puts the business logic somewhere else: in an ontology. An ontology captures your operational logic—the rules and decisions that run your business—into a structure your agents can reason and act against.

Building something like this is not easy. The knowledge extraction is the real work, and it doesn’t happen overnight. Totogi is an AI-first software company, building the ontology for the industry to use, based on open standards from TM Forum. What you bring is your operational knowledge, business rules, and process. We work together to create your ontology. Once you have it, the architecture gives you:

1. One copy of your business logic, used by every agent, regardless of creator.
2. Agents that carry no operational knowledge of their own because they reason against the ontology.
3. A single place to make changes, where every agent sees them immediately.
4. Agents reasoning about the same customer return the same answer at runtime.
5. The ability to swap agent vendors via a configuration change, not a re-implementation.
6. Access to your own business logic, because it’s no longer trapped in vendor code and configurations.

The structural difference is not subtle. In the first architecture, your business logic is duplicated across every agent that uses it. In the second, it lives once, in a layer you control. As you deploy more agents and capture more rules, the gap between those two numbers is the difference between an AI strategy that compounds in your favor and one that keeps you trapped, dependent on vendor consultants.

Once you have it captured, the value compounds. Changes are easy. Switching to new systems is trivial. You don’t need consultants anymore.

Zain Sudan deployed the Totogi Ontology to diagnose dormant cell sites. Detection-to-resolution dropped from 48 hours to 30 minutes. In the same loop, the ontology informed the network team about the cell, briefed customer support on what to say, alerted revenue forecasting to the issue, and reported to leadership what had happened—instantly, with no human in the loop coordinating. That’s the N + M architecture in action.

So, don’t put your business logic inside an agent. This approach puts you right back where you are now: not in control of the operational rules that run your business. Investing in your ontology future-proofs your systems for decades, enabling faster vendor swaps, faster business changes, and full leverage of AI.

This is the only way to do enterprise-scale AI.

You already own the deepest assets in enterprise software: networks, spectrum, trucks, last mile, and regulatory trust. The operational logic that runs on top of them sits in your consultants’ hands today. Use the Totogi Ontology to build the right AI architecture for your telco.

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.

- DOWNLOAD PDF

- DOWNLOAD PDF

This is not a model problem, nor a data problem. This is an architecture problem. And it is the reason most telco AI initiatives are stuck in a long, expensive loop of promising demos and cautious rollouts, while the board asks a reasonable question: when does this start showing up in the P&L?

Every telco running multiple operational systems (CRM, BSS, OSS, catalog, CPQ, charging, core, and many others) knows the friction. When an AI agent or automation workflow has to reason or act across more than one system, it has no machine-readable model of how your business actually works. No governed truth layer. No common language for constraints. It has API documentation and tribal knowledge, and that combination is poison for reliable AI.

The usual first move is to bolt AI onto a specific system. A BSS or OSS vendor ships an AI assistant that works well inside its own stack and data model, and the operator deploys it. That works if your estate is a single-vendor monoculture. In a multi-vendor telco, which is essentially all of them, the agent reasons confidently inside its native domain and falls back to brittle handoffs the moment it has to cross into another vendor’s system. The next move is to build a bespoke integration for each new AI project: connect the agent to the systems it touches, hard-code the business logic, ship it, and hope the pilots stay pilot-scale. Most do not. Six months later, you are running yet another one-off automation that only your senior architect understands and no one else dares to modify.

Where the traditional approach cracks

 That pattern has three forces compounding it. First, every AI initiative becomes a custom integration project, because you have never formalized the model of your own operations in a way machines can read and reason over. Second, your operational reality is distributed. A single customer transaction touches six to ten systems, often from different vendors, and none of them speaks the same language. Third, AI agents need context to behave intelligently: what actions are valid now, what constraints apply, what systems can execute what they propose. Without context, they fail silently or execute dangerously.

The result is predictable:

• Pilots succeed in controlled environments with clean data and a single happy path.
• Production reveals that the agent lacks context about constraints it was never taught.
• Manual workarounds and escalation queues grow.
• The business case collapses.
• The team moves on to the next AI initiative with the same architecture.

This is not bad AI engineering. This is what happens when you ask a machine to reason about a domain it has never been formally taught.

A concrete failure: the cross-system care agent

Imagine a telco with a customer care use case: an AI agent that listens to a customer’s request, consults the CRM for account history, checks the 5G core (or the NMS in 4G estates) for network state, queries the catalog for available services, consults the CPQ for pricing, validates feasibility against current subscription terms, and then orchestrates the order. This is a realistic business outcome. Care productivity goes up. First-contact resolution improves. The math works.

Now map the failure path. The agent receives a request to upgrade a customer to a faster plan. It checks the CRM, queries the catalog, runs the CPQ, receives a quote. But the agent does not know that this customer’s subscription contract forbids mid-term upgrades without a penalty. It does not know that the faster plan requires a network capacity reservation that is unavailable in this geography. It does not know that the billing system’s month-end cutoff is in two hours, and orders placed after will break the customer’s invoice cycle.

The agent had no way to know these things. They were never encoded in a way it could access. So it either failed silently, or it offered a solution that created downstream chaos. In production, you caught it. In a live escalation, your customer might not.

The fix is not better prompting or a stronger model, but semantic governance. You need a machine-readable model of how your telco actually works.

Semantic governance, not more middleware

The canonical industry response is integration middleware: more APIs, more data pipelines, more orchestration glue. Telcos have spent billions on this. It works for simple, linear processes. It breaks down the moment an AI agent needs to reason across multiple systems, or when you want to build a second agent that touches the same systems differently. And the math is against you. Point-to-point integrations scale quadratically. Every new system or agent multiplies the pairwise connections you have to build, test, and keep alive. AI capabilities evolve in months; integration projects take quarters and years. Middleware does not close that gap. It widens it.

The real lever is semantic. You need a governed, machine-readable model of your operations that every system can reference and every agent can consult. A data lake stores raw material and is strong for analytics, but it does not encode the actions, constraints, or sequences your business runs on. An API gateway mediates traffic, but it cannot tell an agent what is allowed to happen next, or why. What you need is a model. Something that encodes not just what entities exist, but what actions are valid, what constraints apply, what sequences are allowed, and what each system actually owns and enforces. This is not a knowledge graph for summarization or retrieval-augmented copilots. It is a blueprint for orchestration and validation. Summaries tell an agent what happened. A governed model tells the agent what it is allowed to do next.

AI without context is just automation. Automation with only API knowledge is fragile. But agents grounded in a formal model of your business can reason safely and scale.

Three-layer architecture: how to build a grounded AI platform

Totogi Ontology introduces a three-layer mental model:

The data layer connects to your existing systems (CRM, billing, OSS, catalog, CPQ, core) and extracts real operational truth. Schemas. Configurations. Mappings. Process artifacts. This is not a data warehouse. It is a translation layer that normalizes how your systems represent the same things.

The ontology layer is where the real work happens. A credible telco-specific ontology is not just a richer data model. It has to span three operating dimensions. The semantic dimension defines the core entities of the business and the relationships between them: customers, accounts, subscriptions, services, resources, policies. It tells the system what exists. The kinetic dimension encodes behavior: the actions that can be taken (order, amend, validate, reserve, charge, notify, route), the sequences they must follow, and the constraints that govern them. It tells the system what can happen, and under what conditions. The dynamic dimension is where decisions, constraint evaluation, and learning live. Validity rules answer the question, “Can this agent take this action right now, and if not, why not?” A worked example: “Is a mid-term upgrade permitted for this customer, given their contract terms, the current billing cycle cutoff, and available network capacity in their geography?” The ontology is what makes that a yes-or-no question instead of a human escalation. Most vendor-claimed ontologies stop at the semantic dimension. That is a reference layer. To actually operate the business, the ontology has to be executable across all three.

The architecture is deliberately an overlay, not a rip-and-replace. Your existing systems and integrations stay in place. The ontology sits above them and gives every agent, whether a large language model, a traditional RPA tool, or a custom orchestrator, a common and governed way to reason about what your telco can actually do.

What changes

In the care scenario, the agent now has formal access to subscription constraints, network capacity, billing cycles, and catalog dependencies. It queries the ontology before proposing an action. “Can I upgrade this customer?” becomes a yes-or-no question backed by real business rules, not an ambiguous API call.

The quote-to-order flow becomes deterministic. The agent generates a proposal. It validates against constraints in the ontology. It orchestrates the actual transactions across systems. Fewer escalations. Fewer orphaned orders. Fewer manual fixes.

The same approach holds when you layer on the next use case. Consider a post-merger operator running two charging stacks and two CRMs. A one-bill agent has to produce a unified invoice across legacy and acquired accounts, respecting pro-rations, shared-minute pools, loyalty credits, and tenant-specific promotions. Without a governed model, it is another bespoke integration with its own rules engine. With the ontology already encoding customer identity, product structure, and charging semantics, the one-bill agent draws on the same foundation the care agent does. Same constraints, same action vocabulary, same validity checks. You build agent logic on a reusable substrate, not a new substrate each time.

The same math applies to MVNO onboarding, network slice monetization, and every AI use case that comes after. You encode the business rules once, in the ontology. Every new agent inherits the context. You ship agent logic, not integration and constraint logic. Weeks, not months.

The telco gets reusable intelligence. One ontology. Many agents. One source of truth for how your business works, accessible to every tool, every process, every team.

The realistic outcome

This solves one of the biggest problems telcos face when scaling AI: the context and execution gap. It makes AI safe to deploy across systems and collapses the feedback loop between “demo works” and “production fails.” Your AI initiatives scale beyond one-off integrations.

Your existing systems stay. Your teams stay. The friction goes away.

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.

Recorded March 2026

Appledore Research analyst John Abraham joins Telco in 20 to argue that telco's AI problem is a context problem, not a data problem, and that an ontology is what gives AI the business context to act reliably.

Every telco exec is talking about AI agents. Almost nobody is talking about what those agents actually need to work: context.

Not just data — the logic, rules, and decision-making processes that define how your business actually operates. That knowledge currently lives in two places: buried in vendor code nobody fully understands, and inside people’s heads. No agentic system, no matter how shiny, can make decisions without it.

In this episode, I sit down with John Abraham, Partner and Principal Analyst at Appledore Research, to dig into why a lack of context is the real blocker for AI at scale, why most approaches only solve half the problem, and how an ontology gives AI the business logic it needs to not just analyze, but decide and act.

Listen now to hear:

• The three Cs holding telcos back from using AI at scale [04:42];
• Why AI agents risk creating a new generation of silos [08:59];
• How a small use case can unlock compounding AI value [14:13]; and
• Why a data lake is a costly side quest [15:09].

What’s really blocking telco AI success?

It’s not the model. It’s not the data. It’s the missing middle: the Totogi Ontology.

REGISTER TO DOWNLOAD -

Recorded at MWC26, this Telco in 20 episode has Danielle Rios cut to the one question operators should ask any AI vendor before they buy, and explains why the Totogi Ontology is what turns AI promises into measurable, real-world outcomes instead of another stalled pilot.

At MWC, vendors will flood the floor with AI demos that look impressive but can’t prove their actual value. Telcos have spent billions connecting systems, but connection isn’t comprehension. Most AI initiatives are blind—unable to see across the fragmented landscape of BSS, OSS, and network systems that speak different languages and live in isolated realities.

The Totogi Ontology is a semantic layer that gives AI the ability to understand your business. Once it does, the army of consultants you’ve been paying to manually stitch together data across systems becomes redundant—and the economics of everything changes. So when the same vendor selling you AI is also billing you for the consultants that AI should replace, ask them to show you the money. 

Listen now to hear:

• Why AI demos fail when they touch your architecture [03:11];
• How the Totogi Ontology solved Zain’s dormant cell problem and turned 48-hours of troubleshooting into 30-minute fixes [04:34]; 
• Why the ability to comprehend across systems and domains is so impactful [6:06] and
• The one question that separates real AI value from empty promises [08:00].

Recorded October 2025