The model cannot fix the fact that every system means something different by “customer.”
That sounds like an integration problem.
It is also an AI problem.
A lot of enterprise AI conversations still start too late. We talk about the model, the retrieval layer, the agent, the graph, the automation, the interface. Those things matter. But the first question is often much more basic:
What are the business objects this system is allowed to reason about?
Customer.
Site.
Device.
Contract.
Asset.
Entitlement.
Ticket.
Approval.
Exception.
These words look simple because humans carry the missing context. We know, often without saying it, that “customer” may mean the billing account in one system, the delivery location in another, the legal entity in a contract, the contact person in a CRM, or the operational site where a technician shows up with a scanner.
The model does not own that distinction.
The business does.
This is where many AI projects inherit old semantic debt.
The database is visible, so teams discuss tables.
The API is visible, so teams discuss endpoints.
The UI is visible, so teams discuss screens.
But the meaning is often sitting somewhere else: in an integration document from ten years ago, in a project manager’s head, in a dispatcher workaround, in a spreadsheet that became the real source of truth, or in the exception rules nobody wants to formalize.
Then the company adds an AI agent on top and calls it context.
That is not enough.
If two systems disagree on what a customer is, the agent is not missing a bigger context window. It is operating across broken semantics.
If a device belongs to a site in one workflow and to a contract in another, the agent needs to know which relationship is authoritative for the action it is about to take.
If a ticket can be closed in the support system but the field workflow still has an unresolved exception, the agent needs more than the word “closed.” It needs the operational meaning of closure.
This is not academic ontology work.
This is how work avoids landing on the wrong object.
The important distinction is not schema versus graph versus vector search.
The important distinction is storage versus meaning versus action.
A schema describes how information is stored.
An ontology describes what the information means.
A knowledge graph, when it is done properly, connects real entities and relationships using that meaning.
But for enterprise AI, I would add a fourth layer:
Which actions are valid against which object, under which authority?
That is where the theory becomes operational.
An agent that can read a contract is one thing. An agent that can decide whether a customer is entitled to a replacement part is another. An agent that can update the entitlement record or trigger a shipment is another again.
Each step depends on meaning.
Not generic meaning. Business meaning.
Which customer?
Which site?
Which device?
Which contract?
Which entitlement rule?
Which exception path?
Which system proves the action happened?
Without those definitions, the model may still produce fluent text. It may even look useful in a demo. But the moment it acts, ambiguity becomes risk.
I have seen this pattern in enterprise mobility and integration work for years, long before AI became the headline.
The hardest problems were rarely just technical connectivity. They were mismatched meanings.
One team says location.
Another says depot.
Another says delivery point.
Another says customer site.
Another says ship-to address.
Sometimes they are the same thing. Sometimes they are not. Sometimes they are the same until one exception happens, and then the distinction matters very much.
Humans compensate for this all the time. They call someone. They know the customer history. They remember the exception. They read between the fields. They know which system is wrong today because the migration is not finished.
AI will not magically absorb that operational judgment from labels alone.
It needs the business to expose the objects, the relationships, the ownership, and the valid actions clearly enough that the system can respect them.
That is why semantic readiness is not documentation polish.
It is deployment infrastructure.
This matters even more when AI moves from answering to acting.
A chatbot can survive some semantic ambiguity because the human still interprets the answer.
An agent cannot rely on that forever.
If the agent creates a ticket, changes a status, updates a customer record, drafts a contract clause, routes a field exception, or triggers a workflow, the business object has to be precise enough for action.
The action boundary depends on the meaning boundary.
If the object is vague, the permission is vague.
If the ownership is vague, the audit trail is vague.
If the source of truth is vague, the answer may be grounded in the wrong record.
That is why knowledge graphs and ontologies are useful only when they are tied to operational ownership. A graph that connects words is interesting. A graph that tells an agent which entity exists, who owns it, which facts are current, which actions are allowed, and which record proves the result is much more useful.
The goal is not to build a beautiful semantic model for its own sake.
The goal is to reduce the number of places where the agent has to guess what the business meant.
This is also where AI readiness becomes very concrete.
Before asking whether the company is ready for agents, ask:
- Which business objects are central to this workflow?
- Which system owns each object?
- Which fields are descriptive, and which fields decide action?
- Which relationships are authoritative?
- Which definitions change by country, entity, customer, contract, site, or device?
- Which exceptions break the normal definition?
- Which actions can be taken against each object?
- Which record proves the action happened?
Those questions are not glamorous.
They are also the questions that prevent an agent from confidently acting on the wrong thing.
In this regard, semantic debt is very similar to technical debt. It can stay invisible for years because humans keep absorbing it. Then automation arrives, scale increases, and the ambiguity becomes a production issue.
AI does not create the debt.
It stops letting the business hide it.
There is a tempting shortcut here.
Give the model more data.
Give it longer context.
Give it a graph.
Give it a tool.
Sometimes that helps. But none of those things replaces the decision the business has to make about meaning.
What is a customer?
What is an active contract?
What is an eligible device?
What is a completed ticket?
What is an exception versus a normal flow?
Which system has the right to decide?
Until those definitions exist, AI can only approximate the work from the traces left behind by people who understood the work already.
That may be enough for discovery.
It is not enough for controlled action.
The companies that get enterprise AI right will not only be the ones with the best prompts, the largest context windows, or the most fashionable graph architecture.
They will be the ones that do the boring semantic work: define the objects, assign ownership, map valid actions, respect source-of-truth boundaries, and make the result inspectable.
Then the model has something stable to reason over.
Then the agent has a boundary it can respect.
Then the audit trail can explain not only what answer was produced, but which business object the system believed it was acting on.
That is where AI readiness starts to look less like experimentation and more like enterprise engineering.
The model can only act on objects the business has defined.
Everything else is guesswork with a better interface.