Portable enterprise ontologies for AI agents – Unite.AI

The term “ontology” is now in vogue. Why? Agents and the LLMs that power them need relevant business context.

Before purchasing an ontology, ask the seller: “When the ontology is wrong in our business, how do our employees fix it, and what is still up to you?” The answer will tell you a lot about the business model you’re buying into. It also points to the bigger stakes: your ability to improve that model as the business changes and to keep that investment worthwhile if you change platforms.

It helps distinguish an ontology from a knowledge graph, although the two often overlap.

Ontology: What kinds of things exist, what relationships mean, and what rules apply. Equipment, components, teams, roles, processes. For example, an ontology can define a type “Equipment” and a relationship “Contains” to a “Component”. A knowledge graph can then state: “Pump P-101 contains seal S-7”: two specific entities and their relationship.

Imagine telling an agent, “Calculate same-store sales growth, but show me a side-by-side screen where we show all stores, then another where we exclude stores that have been open for less than 2 years; then break both sides into domestic, international, and combined.”

This request depends on details that an agent cannot guess:

• which shops exist, when they opened
• where are they
• the internal definition of “same store sales”

One policy might exclude stores until they have been open for a year; the required biennial group adds an additional filter. Again, do you compare calendar months as soon as a store qualifies, or do you only include them after a full prior fiscal year?

The ontology must connect such shops to the policy that governs the computation. Finding related facts helps; applying the right rule is what makes the answer useful.

An agent can use the relationships in the graph to retrieve relevant context before answering a question. And it’s no wonder they are useful, when knowledge domains can easily become very complex.

But extraction can also encode errors. Teams can use different names for the same entity, creating duplicates. Sources may disagree or become obsolete. Even a clean source can be misinterpreted by an LLM. Making these errors seem authoritative does not make them any less dangerous.

These risks increase when a business model becomes a system that acts on it. A wrong relationship can therefore trigger a wrong action, not just a wrong response.

Risks of ontological products

First, be wary of rigid models. In the name of making something “batteries included,” a vendor can make their entities world-class citizens by limiting what yours can do. Customization isn’t enough if custom types lose search, validation, or action functionality.

Second, seek a path from discovery to governance. A tool should allow you to start a graph from what an LLM sees, then validate it against explicit constraints. You should be able to forward exceptions to people and preserve exploratory knowledge without treating it as approved business data.

The biggest risk is tying business processes to a platform that cannot be exited. Your ontology represents your business: its knowledge, its processes and its relationships. This investment in curation and business logic should remain useful even if you change tools. Why would a seller lock it away?

Where chart embeds help

As knowledge graphs become very large, it may be worth choosing a tool or vendor that supports graph embeddings. These are close cousins ​​to the semantic embeddings that power many RAG applications. There are two helpful benefits to consider.

First, a few hops through a densely connected graph can produce too many entities to process. By learning numerical representations of entities and relationships, embeddings offer another way to find relevant parts of the graph. For the right task, this can be more efficient than walking the graph.

Second, embedding models can classify the missing relations of candidates. The same learning can reveal patterns in the attributes and relationships typical of an entity type, helping to build a more complete graph.

The case of progressive improvement

To own your destiny, avoid constraints, and shape your real business instead of a vendor-dictated caricature, how do you get started without an army of forward-deployed engineers? This is where I think modern AI shines, if the tools support a path from discovery to verification.

First, it uses automated detection and extraction. From company documents, policies, emails, or Slack messages, you can build an initial view of a domain. The critical part is that you can’t trust its accuracy until it’s verified.

Verification is the second part. Your tools must provide you with a smooth path from extracted candidates to source-based claims and knowledge validated by a responsible person or authoritative system. Retain the source of any claims.

Freshness is a continuous job. The process for handling a problem report, or the answer to “how many stores are in New Jersey,” may not be the same today as it was three years ago. But updating today’s knowledge must not erase yesterday’s reality. The time a fact was recorded and the time it was enforced may differ; a useful ontology must support both current responses and accurate historical insight. Someone still has to keep that knowledge up to date.

The reach can be enormous. Start with a smaller corpus, map a useful domain, and build towards a complete picture creating value along the way.

Customer support is a useful part: inbound calls, emails, a ticketing system, automated resolutions, a support team that can respond to customers, and a path to escalate real bugs to engineering. It links knowledge to action and exposes the same risks and benefits in a manageable scope.

ServiceNow’s Common Service Data Model illustrates the constraint. Its CSDM 5 white paper warns: “Without this data in your prescribed tables, you may not receive the full value of the ServiceNow AI platform.” The notice itself creates a design and operational constraint: lean on the supplier’s model or accept a risk. What if that means sticking your round peg into the square hole?

Now suppose that an ontology platform also provides acquisition, transformations, actions, and business rules. You may be able to export entities, attributes, and relationships. But can you also push transformations and action pipelines that perform changes in your databases, call webhooks, and create other side effects? Tightly coupled integrations can leave the company itself stranded.

Why flexibility matters now

Software is eating the world and artificial intelligence is eating software. As teams use AI to both build software and power it, more business logic can be tied to these platforms. Any useful automation can also become another migration dependency. It’s dangerous to let a salesperson stand between you and agility.

Conclusions

It’s an amazing time to be alive! No wonder people are exploring ontologies to provide context to agents. Extending that context to processes and integrations can create real value. Let’s go back to the initial question. The corrections made by your employees should make the model a better reflection of your business. That accumulated understanding is too valuable to get stuck when switching platforms. It’s also a terrible time to be backed into a corner.