AI agents became mainstream in telecom recently. Two years ago they were a research demo. At this year’s Digital Transformation World (DTW) Ignite in June, they were the show. Aria Systems and ServiceNow launched what they call the world’s first agentic BSS. Amdocs put its agentic operating system, aOS, at the center of its stand. Vendor after vendor pitched the same move: put an AI agent on top of your stack and let it act across the business. Putting an agent on mission-critical applications is no longer the bold idea. It is the starting assumption.
The harder question is what the agents stand on. An AI agent is only as good as its understanding of the telco beneath it, and a telco is a fragmented, multi-vendor, multi-system estate with no shared model of how it actually works. Point an agent at that and tell it to act, and it acts with confidence on a partial, inconsistent picture. The orchestration looks impressive in the demo. The decision underneath can still be wrong.
Billing is one of the places where a wrong decision gets expensive and easy to see. An agent assembles what a customer owes, and a deterministic billing engine executes whatever it is handed, reproducibly and at scale, even when the decision behind it is wrong. So the hard part of agentic telecom is not the orchestration. It is giving every agent the same correct understanding of the business to act on. That is the question the rest of the industry spent DTW circling.
The architecture the industry is converging on
Two of the most authoritative voices in the telecom industry, an operator and a standards body, put the same idea at the center: agents need a governed foundation underneath them before they can be trusted to act.
Deutsche Telekom brought its own blueprint. It revealed MARA, its Magenta AI-centric Reference Architecture, presented by Global Chief Architect Shekhar Kulkarni: a plan for deploying AI agents at scale across DT’s operating companies. It replaces scattered AI pilots with structured governance, agent orchestration, knowledge management, and required explainability, and it handles multi-vendor integration through control points at gateways rather than coupling agents into each backend. Inside that architecture sits a rigorous detail: Kulkarni notes that “determinism is required in certain billing or revenue assurance processes.” The point is governed agency across the estate, not keeping AI away from the money.
TM Forum moved the standard in the same direction. Its AI-Native ODA Roadmap pushes agentic scenarios across BSS domains, and at DTW its members added a governed execution layer to the Open Digital Architecture so autonomous agents and large language models can operate through governed ODA component capabilities rather than raw APIs. An updated ODA Canvas orchestrates data, models, and agents across fragmented BSS, OSS, and network domains. TM Forum is also explicit that general-purpose AI models are not sufficient for telecoms on their own.
DT and TM Forum have the diagnosis right, and that matters. They describe the architecture around AI agents and the governance required to operate them safely. The remaining question is what those agents actually reason against: a shared, executable model of an individual operator’s telco. That model is still the missing layer.
Orchestrating agents is not the same as sharing a model
The vendor platforms are not dumb pipes, and it would be wrong to pretend otherwise. Aria and ServiceNow’s agentic BSS and Amdocs’s aOS coordinate agents and reach into CRM, CPQ, and billing, and each brings a real data or semantic layer to do it, ServiceNow through its CMDB and Common Service Data Model, Amdocs through its aOS Cognitive Core and logical data model. They resolve some fragmentation. The question is where they resolve it.
In those platforms, the model and the decision logic live inside the vendor’s own agent runtime. The business logic, what actions are valid, what happens next, how a decision is judged, lives in their agents and workflows. That makes their agents capable within their corner of your estate. It does not give the rest of your estate, the other vendors’ systems, your own agents, the network domain, one shared model to reason against. Connect a system the platform does not own, and the shared understanding stops at its edge.
A telco does not need another island of intelligence. It needs one model of the whole estate that every agent and system can use.
The shared model your estate needs
This layer has to do more than catalog the estate. It has to give every agent the same understanding of customers, products, services, policies, and valid actions. It has to evaluate a proposed action against real constraints before execution. And it has to do both consistently across the estate, or each agent becomes its own interpretation of how the telco works.
The Totogi Ontology offers just that: an open, vendor-neutral, executable model of your real-world telco that sits above your existing CRM, CPQ, catalogs, order management, billing, and 5G core, an overlay rather than a rip-and-replace. It works in three layers. The data layer connects to your systems and extracts real operational truth. The ontology layer is the machine-readable model itself: the entities, actions, constraints, sequences, and validity rules. The AI layer is ontology-aware agents that reason and orchestrate against the model instead of guessing.
Inside the ontology layer are three operating dimensions, and they are the difference between a reference document and an operational one. The semantic dimension makes the meaning of the estate accessible and consumable: what a customer, account, subscription, service, or policy is. The kinetic dimension encodes what actions can happen and under what conditions. The dynamic dimension covers decisions, constraint evaluation, and learning from outcomes. Semantics alone make information usable. The kinetic and dynamic dimensions are what let an agent move from reading the estate to acting on it with confidence. And because the model is shared and open rather than locked in a vendor’s runtime, every agent and system reasons against the same truth, which is exactly what an embedded, vendor-coupled model cannot offer.
Map once, reuse everywhere
The same governed model that lets a revenue-assurance agent act correctly is the one every other agent reasons against. You map each system in once, and every agent reuses it. The revenue-assurance agent checks whether a bill matches entitlement and contract. The care agent answers a customer using the same definitions of account, service, and policy. The commerce agent turns a quote into a valid order against the same catalog rules. The migration agent maps a legacy interface against the same model. The network-operations agent correlates alarms from the NMS and 5G core against it. One model, five jobs, no separate translation for each. The more systems you connect, the more reusable the model becomes. Encode once, build anywhere.
Let’s look at an example. An enterprise customer wants a premium network slice for a 48-hour event, billed per the SLA tier they pick. The commerce agent assembles the intent: this customer, this slice, this SLA, this window, this price book. Before any of it becomes an action, the agent reasons against the shared model: is this customer entitled to this slice, is the SLA tier valid for this account, does the sequence respect the kinetic constraints. Only an intent the model confirms is valid reaches the deterministic billing system of record, which prices and bills it with an auditable record of why. The agent assembled the plan, the model said what was allowed, the system of record made it provable.
The proof: one model, different jobs
This is not theory, and it is not only billing. In network operations, a deployment cut alarm noise by 97% with the Totogi Ontology, using semantic observability to correlate a flood of network alarms into governed action and root cause. In commerce, a Southeast Asian CSP cut CPQ order time by 80% with the Totogi Ontology, turning a request into a valid order across CRM, CPQ, and catalog systems. In migration, CloudSense certified its full set of APIs to TM Forum Open API standards in about one month against a 26-month estimate, by mapping into the ontology once. Different domains, network, commerce, and migration, one model underneath.
Where this leaves you
You can give every agent one open, shared, executable model of how your telco actually works, and let them reason against it before they act. The industry has now named that foundation as the thing agentic telecom depends on. The Totogi Ontology is that model, built and proven, an overlay on the systems you already run. A governed model is not a cage around AI. It is what lets an operator trust agents to act across the business, including revenue, and be right. Billing is just where the gap shows first.
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.
