Agentic AI has reopened data problems we thought we’d solved

The problem isn’t that LLMs aren’t smart enough

It’s not that foundation LLMs aren’t extremely capable. They recognise patterns, summarise information and reason across inputs. But what they don’t automatically understand or inherently know is your operator’s internal logic.  For example:

• How your organisation distinguishes a customer from an account
• How services relate to subscriptions
• Which definition of “active” applies in a particular context

If those definitions vary across systems –  and in telecom they often do  –  the model can only reason with what it sees.

If systems don’t share the same understanding about what key terms mean, the LLM may give an answer that sounds right but doesn’t actually match how the business operates or help to deliver the right outcomes.

This isn’t about intelligence – it’s what happens when different systems define the same things differently.

Ontology solves the problem of multiple definitions in different systems

By using ontology as a common language, source systems can keep their own definitions, while the platform reasons over a single, consistent semantic model – a shared version of the truth.

Unfortunately, while LLMs excel at language, they’re much less reliable when it comes to business meaning.  For example:

What’s the relationship between a service and a subscription? When exactly do we consider something active, suspended or terminated?

The LLM don’t inherently know which definition of “active subscriber” matters in a given context, or which relationships are valid for a specific operator. Instead, they’ll confidently combine concepts that might look right linguistically, but are actually wrong operationally.

This is where ontology helps. It sets boundaries, creates shared definitions, and the model doesn’t need retraining.

By using ontology as a common language to understand meaning, source systems can keep their own definitions of:

• What entities exist
• How do they relate
• What their states mean
• When those states change

With AI, the model isn’t just displaying information – it’s interpreting and sometimes acting on it.

Without shared definitions, an LLM can generate fluent but misaligned answers. Ontology doesn’t make the model more fluent; it makes its reasoning grounded in clear business definitions.

Once the LLM understands meaning, then it’s all about Context 

Even with aligned definitions, the model still needs guidance – a billing dispute follows different logic than a retention offer, and a network issue requires different reasoning than a product change.

Here’s a simple example:  a customer’s service is marked as “suspended.” The term may be clearly defined, but the reason behind it matters:  Was it non-payment? A fraud trigger? A provisioning error?

Each scenario requires a different response and allows different actions.

That's where context comes in.

Context includes the instructions, tools, and knowledge pushed into the model’s context window during one or more reasoning cycles. In addition, context also defines how the model should reason and what actions it is allowed to take. It can include decision rules, constraints, and step-by-step reasoning expectations, ensuring the model doesn’t just generate an answer, but follows the correct business logic before responding or triggering an action.

Because of this, what you include (and when) has a major impact on answer quality.

That's why context engineering matters. It’s about deciding what the model must learn immediately, and what can be deferred.

How do you make AI work for telecom

Telco knowledge is multifaceted and highly domain-specific: customers, subscriptions, services, networks, policies, etc. It’s a mistake to just throw all that into an LLM model and expect anything more than superficial or incorrect answers.

Making AI work in telecom isn’t about building a new “telco LLM” because foundation models already handle language well. The real work is done by what surrounds the model. In order to produce answers that can be trusted, you need an architectural layer around the model that follows the essential principles of:

• Ontology, to define business meaning
• Telco knowledge, grounded in that meaning
• Context engineering, to deliver the right knowledge, reasoning constraints and allowed actions at the right moment

That’s exactly what Amdocs’ Cognitive Core does.

The BI Lesson that AI Has Reopened

For years, ontology felt like something that belonged to BI modeling but LLMs have brought back those old debates about definitions and made them impossible to avoid.

LLMs are good at language, but language isn’t knowledge. Knowledge depends on shared meaning, and that’s what both ontology and context provide. If the BI era taught us anything, it’s that without agreed definitions and shared meaning, outputs won’t be trusted.  

Suddenly, those old BI lessons don’t feel old at all.