Three Systems All Show 100 in Stock. So Why Can't You Promise the Customer 80?

A customer comes to you and asks: I want 80 units. Can you deliver tomorrow?

You check three systems. The warehouse system shows 100 units of physical stock. The e-commerce system shows 100 units available for sale. The procurement system shows 100 units in transit. 100 plus 100 plus 100 equals 300 — so you can deliver up to 300 units, right?

Obviously not.

Some of those 100 units in the warehouse may already be reserved for other orders, and some may not yet be received or picked. The 100 units in the e-commerce system may be scattered across different warehouses and may not come together as a single order. The 100 units in procurement do exist, but they may not arrive tomorrow.

So being able to look up the data is not the same as knowing what that data actually means for the business. That is exactly the problem Palantir's Ontology sets out to solve.

Palantir breaks a real business decision into four parts

In Palantir's framework, a real business decision is split into four parts:

• Data: what is happening right now
• Logic: how you should judge it
• Action: what you do next
• Security: under what conditions you are allowed to do it

Let's walk through the inventory case one piece at a time.

Data: not stitching tables together, but translating data into the business world

What Palantir means by Data is not simply joining a few tables from a database. It means translating the data in those systems into the language of the business world.

It does this with a few of the most basic modeling elements: Object, Property, and Link. In plain terms:

• Object: what this thing is
• Property: what characteristics it has and what state it is in right now
• Link: how it relates to other things

An order, for example, can be a type of Object. A specific order has Properties like order status, amount, and creation time. A product is also an Object, with Properties like product name, SKU, category, and price. And between an order and a product there is a Link — a relationship. Which products does this order contain? One order can contain many products, and one product can appear in many orders.

Palantir officially calls Object, Property, and Link the Semantic Elements of the Ontology — the semantic elements used to describe the business world.

At this point, many people's first reaction is the same as mine: isn't this just a knowledge graph? If the Ontology only went as far as defining objects, attributes, and relationships, it would indeed look a lot like a knowledge graph, a semantic layer, or domain modeling. But Palantir goes one step further.

Logic: from "knowing the facts" to "making a judgment"

Back to the inventory problem. By now you know that the warehouse holds 100 units of physical stock, 20 of which are already committed and 10 reserved or frozen, plus another 100 units in transit that will not arrive until the day after tomorrow. You can read the business world.

But what your boss is asking is: can I deliver 80 units tomorrow?

So knowing the facts is not enough — you have to be able to make a business judgment. This is where Palantir's more central layer comes in. It does not just describe the world; it lets the company make decisions inside that world. That is Logic.

Say the company has an internal rule: the inventory you can promise for tomorrow equals physical stock minus reservations minus frozen stock, plus whatever can arrive before tomorrow. Run the numbers: 100 minus 20 minus 10, plus 0, equals 70. The customer wants 80, so you cannot promise it.

In Palantir, this Logic can be implemented through functions, rules, or models. You could write a function that calculates the promiseable quantity: feed it inventory, reservations, in-transit status, and arrival time, and it outputs the deliverable quantity. If the customer wanted 60 units instead, the system would judge that you can say yes.

Action: saying "yes" is not enough — you have to actually change the business state

But if the AI only replies "yes," it is still essentially a question-and-answer system. What the company really needs is to actually lock down those 60 units.

In Palantir, this ability to genuinely change the business state is called an Action. Locking inventory is an Action; issuing a refund is also an Action. This is one important difference between an Ontology and a plain knowledge graph: an Ontology does not just tell the machine what the world looks like now — it also lets the machine actually change that world.

Security: once execution is possible, the boundary itself becomes business logic

Once AI can really lock inventory, issue refunds, and cancel orders, the next question arrives immediately.

Locking 60 units can be automatic — but what about 6,000? A 100-yuan refund can run automatically — but what about 100,000 yuan? Which operations can AI perform directly, which need human confirmation, and which must have a manager's approval?

That is Security. So Security is not a permission setting you bolt on at the end. Once AI starts actually executing operations, who can do it, under what conditions, and whether approval is required are themselves part of the business logic.

What Palantir actually built out of this

So far we have been talking about the core idea of the Ontology. What did Palantir actually turn it into?

Officially, Palantir divides the Ontology system into language, engine, and toolchain. The language defines the business world, the engine makes those objects queryable and modifiable, and the toolchain lets developers' applications and agents actually use this Ontology. So to be precise, Palantir's Ontology is not a static business model — it is a combination of a business model and a runnable state.

As for the Foundry, AIP, and Apollo platforms you often hear about, there is no need to overcomplicate them. Foundry leans toward data and operations, AIP is the platform for large models and agents, and Apollo handles platform deployment and continuous delivery. The Ontology is not a fourth platform — it is the core system of the whole architecture, which Palantir officially calls the heart of that architecture.

For most companies, understanding it to this point is enough. There is no need to dig into how each platform is implemented internally, because we are not going to replicate Palantir's technology stack anyway. What is genuinely interesting is the next step: what can we borrow from it in the era of large models?

What can we borrow in the era of large models?

Companies used to have many systems — ERP, CRM, WMS, OA — and they were fragmented too. So why did that not feel especially serious back then? Why did no one feel the need for an Ontology?

Because in the middle there was one very important thing: a person. A supply chain lead with years of experience would not promise 300 units just because three systems all said 100 in stock. They know which number to trust and which to discount. Large models have given agents reasoning ability, but the company still has to tell the agent what kind of world it is reasoning about.

Palantir's Ontology was born before large models. It represents a very typical kind of explicit-modeling thinking: first define the business reality clearly, then let software and AI run on top of that model.

But today is different. A new generation of agent harnesses, represented by Claude, already has strong natural language understanding, reasoning, tool selection, code execution, and context management. On top of that we have skills, knowledge bases, and MCP. Much of what once had to be structured, engineered, and explicitly modeled in advance can now be handed to the agent to understand and combine at runtime.

So if you were building an enterprise agent from scratch today, what you should borrow is Palantir's philosophy for solving the problem — not its original implementation.

Data: the agent needs order status, customer information, product, and logistics data. In simple scenarios, you do not necessarily have to model all of it as objects, properties, and links first. You can query ERP, CRM, and other systems directly through tools or MCP, then use schema and context to tell the model what this data means.

Logic: many processes that involve judgment calls can go into a skill, or become a tool.

Action: this is even more direct. Refunds, locking inventory, and canceling orders are usually just tools inside the agent harness. Underneath, they can call APIs directly or be exposed to the agent through MCP.

Security: this matters even more in the agent era than before. A 100-yuan refund can run automatically, 10,000 yuan needs human confirmation, and 100,000 yuan should never have that permission handed to an agent at all. And these boundaries should not be written into a prompt or a skill in the hope that the model polices itself. The real boundary belongs in tool permissions, API permissions, approvals, and auditing.

Don't build the Ontology first and the agents second

After studying Palantir, companies should not rush to kick off a project saying, "Let's build an enterprise Ontology too."

If you have just one agent and one business scenario right now, use skills and MCP and get the business running first. Do not do a lot of abstraction up front for the sake of an Ontology.

But as agents multiply, you will probably start to notice: the support agent and the sales agent both use the same order, yet the two sides may define order differently. The same sentence has been written once in each of three skills. Different MCPs may return completely different structures for customer. A dozen agents all need to issue refunds, create orders, and lock inventory, yet each one has wrapped its own set of tools.

That is the point at which you should pull out what is genuinely duplicated. If multiple agents keep using customer, order, and product, gradually unify those business concepts. If multiple skills keep relying on the same deterministic judgment, abstract it into shared code or a shared tool. If multiple agents all need the same business action, consolidate it into a shared business action.

In other words: don't build the Ontology first and then start building agents. Build agents first, and as they multiply and the business grows more complex, let the things that genuinely need stability and reuse settle out over time.

Compare the two paradigms. Palantir is more like building the Ontology first and then the applications. In the agent era, it is more like building the agents first and letting the Ontology grow along with the complexity.

That, I think, is what makes revisiting Palantir's Ontology so valuable today. We are not going back to remodel the entire business. We are using it to re-examine one question: once agents truly enter enterprise operations, enterprise AI cannot just be a large model with a pile of tools bolted on. We still need to give agents a clear enough business world, the ability to judge and act, and a security boundary.