What an Ontology for AI Agents Actually Needs

How to think about the semantic system that makes an agent coherent, governable, and useful.

The word ontology now covers almost every kind of semantic ambition in data and AI.

It can mean a metrics layer that consistently calculates “revenue”. It can mean a data catalog with a glossary, lineage, and ownership. It can mean a learned context graph, an operational model of entities and actions, or a standards-based model of business meaning. Nimit Mehta’s market map identifies five such categories.

These artifacts are related, but they do not do the same job. A catalog can tell you who owns a table without telling an agent whether two records identify the same customer. A metric layer can calculate active-customer count without defining which action an agent may take for an active customer. A context graph can assemble information for a task without becoming the authoritative definition of its terms.

That is more than a terminology issue. It is an architectural one. If a team cannot distinguish these roles, the ontology becomes a moving target: a diagram for one group, a semantic model for another, a platform feature for a third, and a vague promise of better AI for everyone else.

The useful question is not which artifact is the “real” ontology. It is which semantic capability an agent needs at each stage of its lifecycle.

An ontology for AI agents is not a single file or graph. It is a system: a durable model of meaning, connected to real facts, used to plan retrieval and action, extended to reflect operational complexity, verified as it changes, and governed as shared infrastructure.

Meaning, facts, and context

The distinction that keeps the system honest is simple: meaning is not the same as facts.

The ontology is the semantic model. It defines the kinds of things that exist in a domain, the relationships that may connect them, and the rules that constrain those relationships. In formal terms, it is the schema layer: classes, properties, and restrictions.

The knowledge graph is the instance layer. It holds the actual entities and relationships that conform to that model: this customer placed this order; this order contains this product; this supplier serves this region.

The difference becomes practical as soon as an agent must act. Consider a discount-approval agent. The ontology defines what an Active Customer is, what counts as a Product, which policy applies to each category, and what a valid approval relationship looks like. The graph contains the customer’s orders, the product’s inventory, and the policy records. The ontology defines the grammar; the graph provides the evidence.

Other semantic artifacts sit nearby, but each has a narrower role.

A taxonomy organizes an is-a hierarchy. An espresso machine may be a small appliance and a product. That hierarchy helps with search, filtering, and policy assignment, but it does not capture all the relationships that define a business.

A semantic layer makes analytical definitions reusable. It can define how active customers, revenue, or conversion rate are calculated across reporting tools. It should align with the ontology, but it cannot replace one. Metrics answer the question, “How do we calculate this?” An ontology also asks, “What is this?” and “What can relate to it?”

A context graph is the smallest useful set of information for a decision. For the discount agent, it might include the customer’s status, recent orders, product category, current inventory, applicable policy, and relevant support history. It is not the enterprise graph. It is the slice of context the agent needs right now.

This separation lets teams design each component for its purpose. Durable meaning belongs in the ontology. Current evidence belongs in source systems and graphs. Decision-specific context belongs in the agent runtime. Blend them, and the system tends to become either too abstract to use or too brittle to govern.

Model the business, not the database

An ontology should describe the business, not mirror the current database layout.

Many semantic programs begin by translating source tables into friendlier names. A table called cust_mstr becomes Customer. A foreign key becomes a relationship. The result may be easier to read, but it still carries the source system’s accidents: historical compromises, overloaded fields, vendor terminology, and missing business rules.

Start with the decision an agent must support. What concepts must it distinguish? Which relationships change the answer? What policies constrain the outcome? Which source is authoritative for each fact? The answers define a thin semantic slice that domain experts can recognize and challenge.

In an unfamiliar domain, that slice should not emerge from a months-long modeling exercise conducted in isolation. A more practical approach is to discover first, then formalize.

Explore the corpus. Use open extraction to identify candidate entities and relationships without forcing every mention into an immature schema. Normalize duplicate labels, resolve obvious synonyms, and review the emerging vocabulary with domain experts. That produces a seed ontology. Then run extraction again with the ontology as guidance, producing typed entities and relationships that can be validated.

This does not reject ontology-first thinking. It recognizes that a new domain cannot be modeled accurately from assumptions alone. Discovery earns the first model; the model guides the next round of extraction.

As the model grows, a few rules matter:

• Use the language of the business, not the language of a particular application or table.

• Define recurring concepts once. If customer status, product eligibility, or regional policy appears in ten workflows, it should not have ten slightly different definitions.

• Keep the core stable enough that agents and integrations do not break whenever the domain changes.

• Define clear semantic contracts between producers and consumers. An extraction pipeline, graph service, workflow engine, and agent should not each interpret the same object differently.

The goal is not a universal ontology. It is a bounded model that can scale as the business requires.

Keep two loops running

Teams often treat ontology work as a delivery: define the model, publish the graph, and move on. That is how a useful semantic layer becomes a historical artifact.

An agent-ready ontology needs two linked loops.

The build loop turns changing data into governed knowledge. New documents, events, and records travel down at least two paths. One creates embeddings and supports semantic exploration. The other extracts candidate entities and relationships against the current ontology. Automated checks catch obvious violations—an invalid relationship type, a missing required property, or a mismatch between a relationship’s expected domain and range—before a reviewer sees them.

Review and validation then do two things. They add or correct instance data in the graph, and they reveal where the ontology itself must change: a missing class, a new relationship family, or a definition that was too broad. The next extraction pass runs against the improved model.

The query loop serves each agent interaction. A question arrives, and the ontology helps interpret it. Which concept does this term refer to? What relationship should the system traverse? What ambiguity should it surface? Which policy matters? The system then uses graph traversal for precise, structured, multi-hop facts and vector retrieval for narrative or fuzzy context. It assembles a decision context, produces an answer or action plan, and escalates when the task is ambiguous or high-stakes.

The loops run at different tempos. The query loop runs whenever an agent is invoked. The build loop may run continuously, daily, or after a material source changes. But the query loop is only as trustworthy as the build loop’s latest state. A polished agent experience built on stale concepts and unverified relationships is still fragile.

A vector store and a graph should not compete for architectural ownership. They solve different retrieval problems. The graph provides the agent with precise structure; the vector store provides it with semantic recall. The ontology tells the system when each is appropriate and how to reconcile the outputs.

Make the model operational

Classes and edges are only the beginning. When an agent moves from answering questions to supporting decisions and actions, the ontology must represent more of the business’s operational reality.

Interfaces and composition let different object types share meaningful capabilities. A contract, claim, and discount request may all be reviewable. A store, vehicle, and delivery address may all be geolocatable. These are not necessarily parent-child relationships; they are reusable semantic contracts. Composition often describes this reality more clearly than a deep inheritance hierarchy.

Structs and metadata preserve useful detail without turning every value into a standalone entity. An address, geopoint, money amount, or time range can be a grouped value. Provenance, confidence, recency, ownership, and lifecycle state can travel with an extracted relationship. That metadata matters when an agent must explain why it relied on one fact instead of another.

Derived properties turn normalized facts into governed conclusions. A discount agent should not read a stale eligible_for_discount flag copied across five systems. It should determine eligibility from the active-customer definition, product category, inventory, region, and applicable policy. The calculation remains inspectable, and a policy change updates the conclusion everywhere it should.

Entity resolution links records that describe the same real-world object. An agent that cannot determine whether “A. Smith,” “Alex Smith,” and a customer ID refer to the same person cannot assemble trustworthy context. But resolution must retain provenance and uncertainty. A guessed match should not quietly become a fact.

Security policies also belong in the semantic system. Agents should resolve meaning and permission together. It is not enough to know which contract clause applies if the requesting user cannot view it or cannot use it to trigger an action. Object-, row-, and field-level controls determine what context can enter the agent’s reasoning path in the first place.

This is where entity, object, and action models earn their place. They do more than name objects. They connect an object to permitted operations, policy checks, and consequences.

An agent that can identify a shipment but cannot determine whether it may reroute it has only half an operational model.

Give trust a lifecycle

The uncomfortable truth about AI-assisted knowledge construction is that a plausible relationship is not necessarily a valid one.

An extraction model may infer a relationship because two terms co-occur often, appear in similar documents, or resemble a known pattern. None of those signals proves that the relationship belongs in an ontology-backed graph.

Treat new relationships as hypotheses. Store them as candidate edges, separate from verified edges. Give them provenance, confidence, and a lifecycle state. Then decide how the system will collect stronger evidence.

Grab’s feedback-driven taxonomy-verification approach offers a useful production pattern. It separates candidate from verified relationships, exposes selected candidates in lower-risk search contexts, aggregates contextual interaction signals, and promotes or prunes relationships based on the evidence. The larger lesson is that graph edges should earn trust over time.

The exact method depends on the domain. Search interaction may be useful evidence for product taxonomies. It is not enough to rely on clinical, financial, or legal knowledge, where human review and authoritative sources carry far more weight. Even in low-risk domains, engagement is not truth. It is evidence with biases.

The lifecycle still matters everywhere. A relationship should be proposed, evaluated, accepted, remapped, or retired. Without those states, an ontology becomes a warehouse for model guesses. With them, it can improve without pretending every extraction is certain.

Build a knowledge spine

An ontology that exists only in slides, a modeling tool, or a static glossary cannot ground an agent at runtime. It may describe meaning, but it does not deliver it.

The idea of a knowledge spine captures what operationalization requires: a queryable, versioned semantic model connected to domain graphs, lakehouses, operational systems, and unstructured sources that hold the enterprise’s actual knowledge.

The spine should centralize the resolution of meaning, not necessarily the storage of data. A customer record can remain in a CRM system, inventory in a product platform, and policy text in a governed document repository. Mappings and federation let the ontology bind these sources at query time. Domain teams retain ownership of their data, while agents consistently resolve shared concepts and identifiers.

That operating model requires software discipline. Version ontology changes. Test constraints and mappings. Review changes to definitions that affect downstream workflows. Preserve lineage. Apply access policies when meaning is resolved. A changed definition of Active Customer has operational consequences; it is not just a wording change in a glossary.

That is the difference between a semantic program and semantic infrastructure. A program publishes a model. Infrastructure makes the model available, explainable, and accountable when an agent needs it.

Start with one decision

Do not begin by modeling the enterprise. Begin with one decision an agent must explain or execute.

Choose a domain where scattered definitions, policies, records, and documents already make the work difficult. Identify the concepts, relationships, permissions, and sources that shape the decision. Build a small seed ontology and one context path through it. Validate the facts. Expose uncertainty. Extend the model only when the next decision requires more of it.

That sequence is modest, but it avoids two failures that have stalled ontology efforts for years: the grand model that never becomes operational, and the useful agent prototype that nobody can explain or govern.

The real test of an ontology is not whether it can describe the business. It is whether an agent can use it to resolve meaning, retrieve evidence, apply policy, and improve the next decision.

Further reading

• Ontology Market in Peak Confusion: 5 Emerging Trends — Nimit Mehta

• Crowdsourced taxonomy verification — Grab Engineering

• The Knowledge Spine: Why Your Ontology Needs to Grow a Backbone — Bojan Ciric