Ontology as an Operational Layer for AI Agents

# Ontology: Giving AI Agents a Model of the World

An ontology gives data meaning by describing the real-world things represented by the data and the relationships between them.

Palantir describes its Ontology as the operational layer of an organization. It sits above datasets, virtual tables, models, and other digital assets and maps them to real-world things such as plants, equipment, products, orders, transactions, and people. Palantir also describes it as a kind of digital twin of the organization. (https://www.palantir.com/docs/foundry/ontology/overview/)

# What is an ontology?

An ontology is a model of how a world/system works.

It describes:

- what kinds of things exist,

- what information those things have,

- how those things relate to one another,

- and sometimes what can happen to those things.

 
Imagine we are modeling an online store.  Things in that world might be:

Those are different types of things. Then we describe them.

Then we describe how they relate:

Together, this starts becoming an ontology.

# Why do we need this? Don't databases already do this?

A database stores data. For example, a company may have:

Another database:

And Salesforce might contain:

Humans can look at these and understand: "These records are all talking about Alice / Customer 101."

The systems themselves don't necessarily understand that meaning globally. They primarily contain:

An ontology adds a semantic layer over these systems. Instead of thinking:

you can think:

Now the computer has something much closer to the business's view of reality.

An ontology defines the vocabulary your organization uses to describe reality.

# Ontology is not just a knowledge graph

Ontology defines the model. Knowledge graph stores the actual instances and relationships. An ontology defines what those concepts mean and what kinds of relationships are allowed.

For example:

This decribes how the world can be structured. In practice, products sometimes use the word "Ontology" more broadly to refer to both the semantic model and the operational data represented through it.


A knowledge graph contains the actual entities and facts that follow that model.

The ontology tells the graph what its entities and relationships mean, while the knowledge graph represents the real-world facts using that structure.

## 

## Ontology is becoming an enterprise pattern

Palantir uses the Ontology as a shared operational model of a company. It connects data from databases, ERP/CRM systems, APIs, models, and other sources to real-world business concepts like customers, orders, factories, employees, assets, and transactions.Then it defines:

Objects — what things exist
Properties — information about those things
Links — how those things are related
Actions — what users or AI agents can do
Functions — business logic and rules
Permissions — who or what is allowed to see or change something

So instead of an AI agent seeing disconnected tables and records, it will have well defined connected facts. 

The important part is that Palantir is not using ontology only for organizing data. It uses the Ontology as an operational layer where humans and AI agents can understand the business, reason over its current state, and take governed actions back into enterprise systems.

Microsoft is building Ontology into Microsoft Fabric. Microsoft describes it as a shared, machine-understandable vocabulary of a business that represents entities, properties, relationships, rules, and constraints, then binds those concepts to real enterprise data. It is also designed to provide business context to AI agents so they can reason across systems using concepts rather than individual tables. (https://learn.microsoft.com/en-us/fabric/iq/ontology/overview)

Siemens uses ontologies as the foundation of its enterprise knowledge graph approach. Siemens describes an ontology as the structured framework that defines domain concepts, rules, and relationships through a shared vocabulary. The resulting knowledge graph connects entities and context across otherwise fragmented enterprise data and provides AI agents with more structured context for reasoning and action. (https://www.siemens.com/en-us/solutions/data-analytics-artificial-intelligence/knowledge-graphs/#11QoYGTrdPBsDDhMeIbUe2)

LinkedIn built its knowledge graph around entities such as members, companies, jobs, skills, schools, job titles, and locations. LinkedIn explicitly describes these entities and their relationships as forming an “ontology of the professional world.” This structure has been used across search, recommendations, analytics, monetization, and other LinkedIn products. (https://www.linkedin.com/blog/engineering/knowledge/building-the-linkedin-knowledge-graph)

Amazon uses ontologies and knowledge graphs to structure its enormous product catalog. Its AutoKnow system includes what Amazon calls an ontology suite, which identifies product types, attributes, taxonomies, and relationships and uses them to automatically expand and improve Amazon's product graph. (https://www.amazon.science/blog/building-product-graphs-automatically)

NASA has developed ontologies across domains including Earth science, air-traffic management, and space operations. NASA describes ontologies as a semantic layer above individual database designs that can help data from independently developed systems be queried, translated, integrated, and understood consistently. NASA's Air Traffic Management Ontology, for example, formally models entities such as aircraft, flights, airports, airlines, routes, facilities, weather phenomena, and their relationships. (https://data.nasa.gov/dataset/the-nasa-air-traffic-management-ontology-atmonto)

The implementations differ, but the underlying idea is similar: instead of allowing every database, application, team, and AI agent to maintain its own interpretation of the organization, create a shared model of the important entities, concepts, and relationships that make up the real world.

## How are ontologies actually created?

In practice, ontology creation is usually a combination of existing enterprise schemas, domain experts, and Traditional ML/LLMs.

A common pipeline looks like:

LLMs are especially useful for understanding unstructured data. They can read documents, tickets, emails, contracts, or logs and propose that certain concepts are entities, identify their properties, and extract relationships between them.

But the LLM usually produces candidate knowledge, not unquestioned truth.

Palantir historically lets teams construct the Ontology by mapping datasets to object types, properties, and links in Ontology Manager. More recently, Palantir's Pilot introduced an Ontology builder agent: a user can describe an application in natural language and the agent generates candidate object types, relationships, and action types. The generated Ontology can then be reviewed and refined conversationally. Palantir's MCP tooling similarly allows AI agents to propose Ontology changes, while permanent modifications go through a human review and approval process.

Microsoft Fabric takes a more schema-driven approach. It can automatically generate an initial Ontology from an existing semantic model: tables become entity types, columns become properties, and existing relationships become Ontology relationships. Microsoft then expects users to review and complete the generated model. The public documentation does not describe this generation step as LLM-based; LLMs are used more heavily later for natural-language querying and agents reasoning over the Ontology.

LLMs make ontology construction much more scalable, especially when the organization's knowledge is buried inside unstructured text, but the ontology remains the governed structure that constrains what the LLM discovers and how that knowledge is represented.

## How Ontology Help in building Context to AI Agents

LLMs becoming largely very important in Enterprise AI. Organization building AI agents with LLMs, but the problem is that they are stateless. RAG based  simple vector search hasn't been the solid approach. Knowledge graph based on ontologies is becoming popular in industry to build the context layer for LLMs. An AI agent does not just need more data. It needs to understand what the data represents and how different pieces of information are connected.

The ontology provides that shared meaning:

The knowledge or context graph then stores the actual entities, relationships, history, and state that follow this model.

During retrieval, the agent can identify the relevant entity and follow its relationships to assemble the context needed for the current task. Instead of retrieving only text that is semantically similar, it can retrieve information because it is actually related to the entity or situation being reasoned about.

This is also how HydraDB approaches the problem. HydraDB provides the graph-native context infrastructure while allowing the application to own its ontology, defining what concepts such as CUSTOMER, CONTRACT, or POLICY mean and what relationships such as OWNS, DEPENDS_ON, or SUPERSEDES represent. HydraDB then stores and retrieves those connected facts, including their relationships and temporal state, so the relevant graph context can be supplied to an AI agent at inference time. (https://hydradb.com/)

## Closing Note

Ontologies are becoming important because they give machines a structured way to understand the world behind the data.

For enterprises, that means turning fragmented systems into a shared model of entities, relationships, state, and meaning. For AI agents, it means moving beyond retrieving isolated pieces of information toward retrieving the connected context needed to reason and act.

The ontology defines the world. The knowledge graph represents that world. And retrieval brings the relevant part of it into context. That combination is increasingly becoming the foundation for building AI agents for building reliable context layer.