Consider a composite scenario built from real production patterns. A telco deploys an AI agent to clear a backlog of failed orders. The job is narrow and sensible: read the failed order, identify the likely cause, select the approved remediation path, and resubmit the change. In the pilot, it works. The agent fixes missing fields, retries failed steps, and resolves cases that previously required manual review. There is a list of approved actions. There is human review for exceptions. So the team lets it run in production.
One morning, the agent clears a large batch of stuck orders. Each step looks valid inside the system that executes it. The order can be resubmitted. The service can be activated. The goodwill credit can be issued. What the agent cannot see is the composite state across the business: some services activate before billing is ready, some credits attach to orders that later fail, and some customers move into states no single system owns. By the time anyone notices, the actions have propagated into provisioning, billing, and care. Cleanup means order fallout remediation, billing corrections, and customer-facing work.
That is what prevents AI from scaling safely. The model used clean data and each action looked valid in isolation. The failure only appeared when those actions hit the constraints of the real business, and by then they had already scaled. Where a decision lives determines its blast radius.
Where decisions live
Every operational decision in a telco lives somewhere, and the place it lives sets a ceiling on how much damage a wrong version of it can do.
A human can reason about each case, but only one case at a time. A human weighs the specifics before deciding, so a bad judgment lands on one customer, and the next customer gets a fresh look. Two people will also read the same policy differently, and none of them decides as fast as software. It reasons, but it does not scale, so the blast radius is small.
Hardcoded logic is the opposite. It runs the same fixed rule every time, across every account at once, written once against the assumptions that held the day it shipped, and it keeps executing long after some of those assumptions stop being true. An eligibility rule might keep provisioning an add-on for a plan that was retired two quarters ago, and it surfaces as a stream of downstream order exceptions rather than as an alarm anyone can act on. It scales, but it does not reason, and because a wrong rule is wrong the same way every time, the blast radius is wide but stays hidden until something downstream breaks.
AI is different from both. It reasons about each case the way a person does, and it runs across every account at once the way hardcoded logic does. It is the only one of the three that reasons and scales at the same time. That is what makes it valuable, and on write-side work it is also the whole problem.
Scale is indifferent to correctness.
An AI solution applies a wrong decision as efficiently as a right one, and it applies it to everything in its scope in one pass. Because its decisions are probabilistic, a wrong one is not wrong in the same predictable way a hardcoded rule is. It can be wrong in a new way on every account, which makes the error harder to see coming and harder to catch. The property that makes AI valuable for reading the business at scale is the property that makes it dangerous for acting on the business at scale. It reasons like a person and scales like code, and a wrong version does the most damage of the three. It is also the exact place the industry is now rushing to hand its operations.
So the question is no longer whether AI belongs in the loop. It is where operational decisions should actually be committed.
The guardrails you have already built
If you run AI in production, you did not leave that question unanswered. You added guardrails. You wrote evals. You put a human in the loop on the decisions that carry weight. These are the right instincts and they help. They also share one important limitation. They reduce the chance of a bad decision reaching production. They do not guarantee that every decision is valid within the rules of the business.
Guardrails look for unsafe, inappropriate, or unexpected outputs. Evals tell you whether the model behaves well across the scenarios you thought to test. A human reviewer catches the cases that stand out. All three improve reliability, but none evaluates every proposed action against the operational rules that govern your business. That is why the remediation still succeeded: nothing checked whether those actions were valid together, across the business, before they committed.
None of these mechanisms deterministically refuses an invalid business state transition before it executes. They shrink the blast radius. They do not bound it.
Inference to think, an ontology to act
The way through is not to trust the model more, and it is not to trust it less. It is to stop asking one layer to do two jobs that have different shapes.
AI inference is very good at reading the business: spotting churn signals, ranking retention offers, predicting which customer segments are drifting, and recommending the next best action. Keep it, and use it for all of that. Those are probabilistic problems, and probabilistic models are exactly the right tool to solve them.
Acting on the business is a different kind of problem. Committing a state change, applying a price, migrating a plan, releasing an order, is a question with an answer the business already knows: is this transition allowed, right now, given this customer’s contract, this account’s history, and this segment’s rules? That is not a question you want answered by sampling. It is a question you want evaluated against the rules and answered the same way every time.
The split is between read-side and write-side. AI grounded on a modern data platform reads well, which is the argument we made in your data lake won’t fix your telco AI problem. The gap is on the write-side, where an action has to be checked against operational rules before it commits. Reading is inference. Acting is a decision, and a decision needs a system built to govern state.
What an ontology actually does
The missing piece is an ontology that sits between inference and execution, evaluating what the model proposes and allowing only valid transitions to reach the systems that commit them. That is where the decision should live, and it is what the Totogi Ontology provides. It is an executable model of how the telco actually works, encoding the actions that are valid against each entity, the constraints they must obey, and the state transitions that are legal right now. It sits as an overlay above your existing systems such as CRM, CPQ, catalog, order management, and charging systems, not as a replacement for any of them.
The mechanism is the part that matters for blast radius. When inference proposes an action, the Totogi Ontology evaluates that action against the encoded constraints before anything commits, and it refuses the transitions that are invalid in the domain it models. The activation that would run ahead of billing readiness never commits. The rule it breaks, that a service cannot go active until billing is ready for it, is part of the model the action is checked against, not a test someone hoped to have written. A credit that would attach to an order that is not yet valid is stopped the same way, and a quote that configures an invalid product combination is stopped before it becomes an order that fails downstream.
One thing has to stay honest about that claim. Correct-by-construction applies only within the domain the ontology models. It does not remove every possible error, but it changes the shape of the risk. An invalid write-side decision is refused before it executes instead of propagating across the backlog into provisioning, billing, and care. The exposure that remains is explicit and bounded, and it shrinks as the model expands, rather than surfacing as a surprise in next month’s reconciliation.
This is also the line between a reference model and an operational one. A semantic layer or a knowledge graph tells an agent what exists and how entities relate to each other. Neither one tells the agent that this action is not permitted right now. The ontology encodes what can happen and under what conditions, which is a different category of thing from a better map of what is.
The outcome
The payoff lands on the write-side. You can finally let inference operate at the scale it promises, because the ontology underneath it bounds what those decisions are allowed to commit. The remediation agent can run across the whole backlog, because the actions that would leave the business in an invalid state are refused before they commit. Scale stops being the thing that makes automation frightening and becomes the thing you bought it for.
Every validated decision also strengthens the same governed operational model. The next AI use case builds on that model instead of recreating its own rules, constraints, and integrations, so the value of the ontology compounds over time.
This is already how operational AI reaches production instead of staying in the demo. One tier-1 multinational operator put an AI agent live in seven days to remediate quote failures, with every action traceable, because the agent proposed the fix and the model validated it before anything committed. A remediation that would have created an invalid order was refused underneath the agent, not pushed downstream as the next failure. Agents do not stall because the model is weak. They stall because there is nothing underneath them that makes acting safe, a point we develop in agent orchestration and shared understanding.
Decide where your decisions live before you automate them. Use inference to think. Ontology to act.
About Totogi: The Totogi Ontology is a governed, machine-readable layer that sits above your CRM, CPQ, catalog, order management, charging, and network systems. It gives AI agents one executable model of how your telco works, so they can reason over the whole estate and act on it safely. Learn more at totogi.com.
