Nail your AI architecture before you scale telco AI

The core problem: Telcos can use AI to free themselves from having to pay consultants for every change to their BSS/OSS systems. But will they? Most vendors are trying to maintain the status quo by pitching agentic AI with business logic baked in. The right architecture puts the business logic in an ontology: a structured, executable representation of operational semantics that every agent can reason against. It’s the only way to do enterprise-scale AI that gets you out of paying by the change.

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.