Palantir Ontology Explained: Core Concepts, Agent Integration, and Building a Minimum Viable Ontology

This article continues from a previous piece that explained why enterprises need Ontology despite having databases, data warehouses, BI, RAG, and large models. The core problem: organizations lack a system that connects data, logic, actions, and permissions into a decision-making fabric.

The most common follow-up question is: What exactly is Ontology? Some call it a knowledge graph, others a business semantic layer over data tables, or a knowledge base for Agents. Each captures a piece but misses the full picture.

This article clarifies Palantir Ontology's fundamental building blocks— Object Type, Object, Property, Link Type, and Action Type —and then shows how Agents consume them.

What Palantir Means by Ontology

Officially, Ontology is a classification of the world. In Foundry, it is described as the organization's digital twin: mapping datasets, models, and other digital assets into object types, properties, link types, and action types to form a coherent whole.

In simpler terms, Ontology is a runnable business model . It defines what things exist in the enterprise, their states, their relationships, and what people and systems can do to them.

Ontology is a business map plus a controlled operating system.

Two layers:

Business model – deals with business concepts like Customer, Order, Supplier, Risk Event, not technical fields like customer_id or order_tbl.

Runnable – not just descriptive; it includes Actions that modify objects and relationships, callable by applications, functions, and Agents.

Object Type vs. Object: Type vs. Instance

Order

is an Object Type (defines what an order looks like). ORD-0718 is an Object (a concrete instance).

A database analogy helps beginners:

Dataset → Object Type

Row → Object

Column → Property

Field value → Property value

Join → Link Type

But Object Type is not merely a renamed table. It should represent real-world entities or events (Customer, Equipment, Order, Maintenance, Risk Alert) that have identity, lifecycle, and need independent tracking—not just because a source table exists.

Property: State Carried by the Object

Properties describe an object's characteristics. For an Order: amount, delivery date, payment status, risk level. On ORD-0718, the values are 860000, 2026-08-01, High.

What state is this object in right now?

Not every column belongs on the object. customer_name could sit on the order row, but Customer has its own industry, credit status, owner, and history, and participates in many other processes. Better to make Customer a separate Object and link it.

Link Type: From Field Joins to Business Relationships

Link Type defines the relationship between two Object Types; a Link is a concrete relationship instance between two Objects.

Customer submits Order

Order depends on Supplier

Order relates to Risk Event

Risk Event impacts Product

The key is the business meaning of each link. A database join only needs matching keys; an Ontology link must answer why they connect, direction, business name, and which applications/Agents may traverse it. This turns a “node hairball” into a navigable business map.

Action Type: From Describing the World to Changing It

Objects, Properties, and Links are mostly nouns. Action Type introduces verbs. Palantir defines an Action Type as a set of object, property, and relationship changes that happen atomically, plus any side effects triggered on submit.

In a high-risk order scenario, Actions might include: Mark High Risk: update risk level and disposition status Create Audit Task: generate task and link assignee Pause Payment: change payment status, notify finance Swap Supplier: modify Order–Supplier link, record reason Escalate Handling: add order to special handling queue

An Action is not just letting a user edit fields. It can enforce standardized parameters, validate preconditions, restrict permissions, and trigger notifications, function calls, or writes to other systems.

I want to accomplish “swap supplier,” not manually edit five fields across three tables.

This is the key step from data center to decision center.

Ontology Is Not Just Another Name for Knowledge Graph

Overlap exists: objects as nodes, links as edges; both emphasize business-semantic connections. Palantir's object relationships can be visualized and explored as a graph.

But reducing Ontology to “nodes plus edges” misses three critical aspects:

Connected to live operational data. Objects carry current state, not just static taxonomy entries.

Connected to logic and applications. Functions read objects and object sets; applications organize UI and workflows around objects.

Connected to controlled actions. Actions modify objects, properties, and links under rules, permissions, and submit conditions.

Therefore, knowledge graph is better understood as a related technology and presentation form; in Palantir's product context, Ontology's boundary is closer to a semantic-and-action layer for operations. The graph is just one face.

How Agents Use Ontology

With Ontology, an Agent's reasoning path becomes clear. Example user query: “Which high-risk orders need priority handling today?”

Without Ontology, the Agent must guess data locations, field meanings, customer–supplier links, and which API modifies state. Teams often stuff all that into prompts or attach a pile of uneven database/API tools.

With Ontology, the chain is:

Step 1: Lock the Business Object

Agent resolves “high-risk orders” to an Order object set, not a full-table scan for fields containing “risk.”

Step 2: Traverse Relationships for Context

It reads order amount, due date, risk level, then follows Links to customer priority, supplier anomalies, and related risk events.

Step 3: Call Deterministic Logic

For overdue days, supply risk, revenue impact, the Agent invokes predefined Functions or models—not the LLM guessing.

Step 4: Propose or Invoke Actions

Agent returns orders needing escalation with rationale, then per design boundaries:

Only generate suggestions for human confirmation

Create pending audit tasks

Or directly call an Action if permissions and preconditions allow

Step 5: Write Results Back to the Business World

Outcomes persist beyond chat: order status, audit tasks, assignees, disposition reasons become object/relationship updates, forming context for the next query and decision.

Per Palantir's public pro-code Agents docs, Agents read/write Ontology via OSDK, Ontology MCP, etc.; developers explicitly declare callable tools, and access is scoped by permissions.

Ontology does not dump all enterprise knowledge into the model; it gives the Agent a set of semantic, queryable, invokable, permission-controlled business interfaces.

The LLM handles intent understanding, context assembly, and next-step selection; deterministic functions handle computation; Actions handle controlled mutation; permissions decide what the Agent can see and do. Such an Agent works inside enterprise systems, not just chats from outside.

Start with a Minimum Viable Ontology

A common pitfall: immediately drawing a grand enterprise-wide blueprint. A practical start is picking one recurring, action-requiring business problem.

Using “high-risk order disposition,” version one needs only:

4 Object Types : Order, Customer, Supplier, Risk Event

Essential Properties : amount, due date, payment status, risk level

3 Key Links : Customer submits Order, Order depends on Supplier, Order relates to Risk Event

1 Deterministic Logic : risk scoring

2 Actions : Create Audit Task, Escalate Handling

Clear Permission Boundaries : who can view, suggest, execute

This already lets an Agent close the loop: detect → enrich context → assess risk → submit action. Additional objects and actions are added when real scenarios demand them. Ontology quality—stable semantics, natural relationships, Actions actually invoked by processes—matters more than node count.

Final Summary

Object Type defines what things exist in the business; Object is a specific thing; Property describes its state; Link Type describes its relationships to other objects; Action Type defines how to change this world under control.

For people, it's a shared business language. For applications, it's a stable business interface. For Agents, it's both map and guardrail.

Next article: how to extract true business objects from database tables and fields—when to create a new Object versus just a Property or Link.

References

Palantir Docs: Ontology Core Concepts [1]

Palantir Docs: Object and Link Types Reference [2]

Palantir Docs: Action Types Overview [3]

Palantir Docs: Ontology SDK Overview [4]

Palantir Docs: Agents Overview [5]

Cited Links

[1]

Palantir Docs: Ontology Core Concepts: https://www.palantir.com/docs/foundry/ontology/core-concepts/ [2] Palantir Docs: Object and Link Types Reference: https://www.palantir.com/docs/foundry/object-link-types/type-reference/ [3] Palantir Docs: Action Types Overview: https://www.palantir.com/docs/foundry/action-types/overview/ [4] Palantir Docs: Ontology SDK Overview: https://www.palantir.com/docs/foundry/ontology-sdk/overview/ [5] Palantir Docs: Agents Overview: https://www.palantir.com/docs/foundry/agents/overview/