What is an ontology for AI agents?

#What is an ontology?

An ontology defines the formal vocabulary of a domain: the classes of things that exist (customer, order, contract), the properties that describe them (status, owner, effective date), and the relationships that connect them (an order belongs to an account, a contract governs a set of transactions). The concept predates computing by a couple thousand years, it's a term from philosophy, concerned with what exists and how it's categorized. Tom Gruber formalized it for computer science in 1993, and it's since been standardized through W3C formats like RDF and OWL.

What makes an ontology different from a plain data model is that it's built to support reasoning. A traditional schema describes how data is stored. An ontology describes what things mean and how they relate, in a form precise enough that a system can infer new facts from stated ones, not just retrieve what was explicitly written down.

#How is an ontology different from a semantic layer, a taxonomy, or a knowledge graph?

These four terms get used close enough to each other that they're worth separating directly:

• Taxonomy: a hierarchical classification, parent and child categories. Simpler than an ontology, no formal relationships beyond "is a type of."
• Semantic layer: standardizes metrics and definitions (what "revenue" means, computed one way, everywhere). It's about consistent numbers, not about modeling entities and their relationships in general. We cover this one in more depth here.
• Ontology: the formal model itself, classes, properties, relationships, encoded so a system can reason over them.
• Knowledge graph: the ontology instantiated with real data. The ontology is the schema; the knowledge graph is the populated instance, actual customers, actual orders, actual relationships between them, following the structure the ontology defines.
• Lineage: the record of how something got to its current state, the sequence of changes and steps behind it. An ontology tells you what connects to what right now. Lineage tells you how it came to be that way.

An ontology without data behind it is a blueprint. A knowledge graph is what you get when that blueprint is filled in with the business's actual entities.

#Why does an agent need an ontology, not just documents?

An agent working from unstructured documents can retrieve a sentence that mentions a customer and an order in the same paragraph. It can't reliably infer that the order belongs to that customer, that the customer has three other orders, or that one of those orders is under an active dispute, unless that relationship happens to be spelled out in the exact document it retrieved.

The reason this breaks down is that organizations don't document things in one place, or one way. A term gets defined in a schema, used differently in a Slack thread, and carries an exception that only lives in someone's head. A person who's been at the company a year navigates that without noticing, they know "user" means a billing account in one system and an individual seat in another, and they adjust automatically. An agent has none of that. It reads "user" in two places and has no way to know they aren't the same thing.

An ontology makes those relationships explicit and queryable. Instead of an agent inferring structure from prose every time, it reasons over a model that already states: an order belongs to an account, an account has an owner, a dispute blocks certain actions on the order it's attached to. The agent doesn't have to rediscover the business's structure each time it's asked a question. It's already encoded.

This is also why the same fragmentation problem shows up repeatedly across an enterprise: without a shared ontology, an HR agent, a sales agent, and a support agent each rebuild their own partial understanding of what a "customer" or an "account" means, from scratch, independently, often arriving at slightly different answers to the same question.

#Does an ontology replace a semantic layer?

No, and they're not really substitutes for each other, they typically work together. A useful way to see the split: a semantic layer defines the nouns and how to compute a number from them, revenue, refund rate, lifetime value. An ontology goes further, encoding not just what a metric means but how the underlying entities relate to each other and, in some formulations, what actions are permitted on them. One enterprise ontology framing splits this explicitly into a semantic layer (the nouns, entities and their attributes) and an operational layer (the verbs, the permitted actions and who can take them).

A semantic layer alone doesn't tell you that an order is blocked because of an active dispute somewhere else in the business. An ontology, built to encode relationships and constraints, can.

#What are the standards behind an ontology?

Ontologies aren't a proprietary format. The W3C has standardized two: RDF (Resource Description Framework), for representing relationships as simple subject-predicate-object statements, and OWL (Web Ontology Language), for richer class hierarchies and logical constraints that support formal inference. An ontology built on these standards is portable in principle, readable by any system that speaks RDF or OWL, not locked to one vendor's proprietary graph format.

#Does an ontology have to be static to be useful?

No, and this is where a lot of early ontology efforts actually failed, not because the concept was wrong, but because the model was updated on a schedule instead of continuously. A business changes daily. An ontology refreshed once a quarter is already stale by the time it ships, which means an agent reasoning over it is working from a snapshot of a business that no longer exists. That's a harder failure mode than just being slow to build, a stale ontology can be actively wrong in a way that's harder to notice than an empty one.

The fix isn't a faster one-time build. It's treating the ontology the way an organization treats its own understanding of itself, something that gets re-linked and updated continuously as relationships, ownership, and constraints change, not re-modeled in a big project every few years. A more practical starting point still helps, bootstrapping from what already exists in a company's CRM, ticketing system, and codebase rather than designing everything up front, but the bootstrap only matters if what comes after is continuous, not another static snapshot with a longer shelf life.

#How does this connect to the three views an agent needs?

An ontology maps most directly onto the structural view, how things relate, who owns them, what depends on what, but it can carry semantic information too, since the classes and properties it defines are themselves a form of shared vocabulary. What an ontology by itself typically doesn't capture is intent: why something was modeled or decided the way it was, and what's already been tried and ruled out. Semantic, structural, and intent are three separate questions, and an ontology, however well built, is usually answering one or two of them, not all three at once.

#How does Uvi handle the structure an ontology defines?

Uvi keeps a working model of how a business's entities relate, close to what an ontology formally defines, current as the business changes, and pairs it with the semantic and intent views an agent also needs. Not a separate ontology project bolted onto everything else, one part of what stays resolved and current together.