When Agents Need to Understand Your Data: From Databases to Ontology

1. How the Discussion Began

Recently, Lao Feng wrote an article about Palantir. His arguments were as sharp as ever, and I agreed with 98% of them. On the closing conclusion, however, I would like to offer a slightly different perspective.

All Palantir has done is take the manual work that hundreds of thousands of engineers do every day—writing ETL, creating tables, and configuring permissions—wrap it in an Aristotelian term, and sell it at an AI-era valuation.

Feng Ruohang, Lao Feng Yun Shu on WeChat, Palantir's “Ontology Scam” (translated from Chinese)

Here is how I see it.

In the pre-AI era, databases were primarily used by people, through front-end interfaces. As a result, the semantics of the underlying schema were rarely maintained carefully in one place. They were scattered across interface copy, product documentation, training materials, and even the knowledge passed verbally between experienced employees.

In the AI era, accurately maintaining what a table or field actually means at the database level, for agents to use, becomes far more valuable. Many forms of real business automation become possible only when we bridge this semantic gap.

During our exchange, Lao Feng replied:

“Show me your code, and I may not know what your business does. Show me your database schema, and I can tell at a glance.”

My addition was this: A human expert can indeed understand what a business does by looking at its schema. But that level of precision often falls short of what an agent needs to operate correctly.

Consider a typical NLP2SQL analytics task. When several fields have similar names, such as status, state, and phase, which should the agent use? What do the values 1, 2, 4, 5, 8 mean? People often have to search documentation, read code, and reorganize that knowledge before they can keep the agent on track.

Lao Feng titled his article “Palantir's Ontology Scam.” Taking the concept of ontology as a starting point, I want to explore a particular perspective: ontologies and databases are aligned at the conceptual level, but ontologies pursue those concepts more rigorously in practice.

---

2. First, Put the Facts on the Table

There is a particularly valuable insight in Lao Feng's article that deserves attention on its own.

The fact is that Palantir Ontology has four core concepts: Object Type, Property, Link, and Action. Across its documentation, white papers, and investor presentations, these four concepts are the starting point.

Now consider this table:

Four terminology systems describing the same thing. This is not merely an analogy or a loose resemblance; it is complete overlap, a strict isomorphism.

Palantir also defines subsidiary concepts such as Interface, Function, and Virtual Table. Translated into database terminology, these are essentially views, user-defined functions, and materialized views.

One could say: If you have learned database modeling, you have already mastered what Palantir calls its “ontology.”

The value of Lao Feng's explanation is that we need not be intimidated by imposing terms like “Aristotle” or “ontology.” At the level of conceptual frameworks, we are discussing the same set of ideas.

What I want to add is a further question: If the concepts are the same, why do databases and ontologies follow such different paths in practice? And why does the AI era make the path that takes semantics seriously increasingly valuable?

---

3. In Practice: Databases Serve Applications; Ontologies Pursue Semantic Completeness

The real divergence lies in implementation.

1. Databases Serve the Current Application

In real engineering projects, a database schema almost always grows around a particular application:

• Table and field names follow a particular version of the business requirements, a set of front-end pages, or a report.
• The same business concept may appear under different names in different tables, such as user_id, uid, and owner_id.
• A single table may contain several confusingly similar business timestamps: start_time, begin_time, and create_time, or end_time, finish_time, and expire_time. An outsider has no way to know which is authoritative.
• The meanings of enum values such as 1, 2, 4, 5, 8 are usually recorded in API documentation or code comments, rather than explicitly constrained in the schema.
• Historical baggage and performance considerations create redundant tables and fields. Their actual meanings are scattered across back-end logic, front-end copy, technical designs, product requirements, and the team's oral tradition.

In practice, then, databases are oriented toward application development. The priorities are making the application work, enabling queries, and shipping it. Whether the semantics are complete, consistent, and easy for a machine to understand is rarely the first concern.

Lao Feng's point about understanding a business from its schema holds for human experts. For agents, however, a crucial mapping is still missing: an explicit, unambiguous account of which concept each table, field, and value represents.

2. A Familiar Scene: The Data Analyst's Investigation

Anyone who has worked in data analysis will recognize this: writing the SQL for a report may take very little time, while working out the precise definitions of the relevant tables takes up most of the effort.

Which field represents the current state, and which records a historical state? What exactly is the difference between order_amount and pay_amount? Does type = 3 mean a return or an exchange in this table? To answer these questions, you read documentation, ask business stakeholders, and inspect code. Only after a lengthy investigation can you trust that your SQL is correct. Even then, the findings usually end up in analysis documents and code, rather than enriching the semantics of the schema itself.

Data analysts typically investigate one project at a time. For each new request, they clarify the exact meanings of the handful of tables and fields needed for that task, then get to work. Tables outside the scope can wait.

This makes perfect sense in a process driven by human labor. People are expensive; clarifying the semantics of every table in the entire database before starting any work is impractical.

The ontology approach takes the opposite position: define all concepts, properties, and relationships precisely at the outset, whether or not there is an immediate reporting request or analysis project.

Previously, that could seem unnecessarily heavy. Getting applications developed and shipped quickly came first. Analysts could investigate whenever a request arrived. But what happens when an agent takes over the analysis?

An agent cannot initiate a round of investigation or ask a veteran employee for a quick explanation. It needs precise semantics prepared in advance, covering the whole domain. That is exactly what ontologies have been working toward.

3. Ontologies Serve Semantics: Harder to Build, but More Complete

The practical design goal of an ontology is different: clarity, consistency, and the ability to reason about the concepts themselves.

• Concepts need explicit definitions, independent of the wording on a particular front-end page or in an internal document.
• Synonyms and closely related concepts must be stated explicitly, including whether they are equivalent, subclasses, or partially overlapping.
• Sets of values, such as status enums, are defined as distinct concepts or enumeration types, rather than hidden as hard-coded values in business logic.
• Relationships, such as what is part of what and what depends on what, are clearly specified to support logical reasoning and validation.

The cost is equally clear: ontologies are usually more abstract and harder to construct upfront. A team must clarify its domain concepts, unify the naming, and specify the relationships before it can build a useful ontology. It does not directly answer “Which table should this button query?” It answers “What are the core concepts in this domain, and what exactly do they mean?”

This explains why many teams have considered ontologies too heavy or of little immediate use. They prefer the pragmatic combination of loosely defined schemas, documentation, and oral tradition. For conventional CRUD applications, this is often the lightest and most efficient way to maintain meaning.

In practice, databases are friendly to application development but loose on semantics; ontologies are rigorous about semantics but less directly helpful to application development. The former are easier to put to work. The latter more closely reflect the business concepts themselves.

---

4. Why Has Semantic Completeness Suddenly Become Valuable in the AI Era?

Before AI, people used databases. They could infer the business meaning they needed from table names, comments, conversations with colleagues, and documentation. Schemas did not have to be semantically complete, and generally were not.

In the AI era, the database user becomes an agent. It cannot ask colleagues or search documentation; it relies on the information you explicitly provide: table structures, field descriptions, value definitions, and synonym relationships.

The difference then becomes clear:

• With only a schema and naming conventions: People can make an educated guess, and agents can too. But agents can easily make basic mistakes about which synonymous field to use or what an enum value means. The results become incorrect and untrustworthy, making the agent unusable in real business settings.
• With an ontology above or alongside the database: Explicitly maintain the mappings between business concepts and tables, fields, and values, along with synonyms and value meanings. An agent can then reason at the conceptual level and map its conclusions precisely to the schema. Accuracy and trustworthiness improve dramatically.

This layer of complete semantics enables agents to move toward sophisticated applications at scale. For example:

1. Agent-based data analysis (Text2SQL): An agent can distinguish order value from the amount actually paid, identify which enum value means a return, and automatically write queries that are 100% correct in business terms, without preliminary human investigation.
2. Automated operations: Given “Send coupons to VIP customers who have made no returns this month,” an agent can follow the ontology graph, find the precise definition of a VIP customer, connect it to the correct business tables, and trigger the associated coupon-issuing action.
3. Anomaly diagnosis and decision support: When a business dashboard shows an anomaly, an agent can follow the ontology's logical links step by step to investigate whether the problem lies in traffic, inventory, or fulfillment.

Many people see database schemas and ontologies as conceptually identical and practically similar during everyday human-led development. For agents, however, that small difference in certainty creates an enormous gap in commercial value. On one side is an occasionally wrong demo that remains a toy—because even 80% accuracy often amounts to unusability in real business. On the other is a trustworthy digital worker that can operate at scale.

One might ask: “Isn't an ontology essentially just a semantic layer imposed on the database?”

Technically, yes. But the fundamental practical difference is how seriously semantics are taken. In the past, that attention could seem like thankless work. Today, it can determine whether an agent succeeds or fails. This goes beyond technology alone: it becomes a challenge of project management and even organizational culture, including how much respect an organization has for data governance.

---

Originally published in Chinese on the DeepFlow AI WeChat account. Read the original article.