Palantir: the Ontology is the product

Decisions happen in one place and data lives in twenty.

Take a supply chain planner who hears that a supplier is in trouble. To respond well, she needs supplier records, part lists, inventory, open purchase orders, customer commitments and contract terms. Those live in different systems owned by different teams. Then she needs the authority to change something, and a record of what she changed and why.

Most companies solve this with spreadsheets, meetings and people who know where things are. It works until it does not scale. Adding an LLM does not fix it on its own. A model can summarize the situation, but letting it change orders requires permissions, review and an audit trail that a chat window does not provide.

So the problem Palantir solves is narrower and harder than analytics. It is giving one shared, current picture of the operation to everyone who makes decisions about it, people and software alike, and letting them change that picture safely. A dashboard answers what happened. This has to answer what should we do, let someone do it, and remember that they did.

A worked example shows how the pieces fit.

The Ontology has four building blocks, each defined in Palantir's documentation. The example below is illustrative. It is assembled from documented features, not taken from a published customer case.

Objects. A supplier's plant floods. In the Ontology, Supplier, Plant, Part and PurchaseOrder are object types, each backed by datasets, virtual tables or models that pipelines keep current. The flood arrives from a news feed or a supplier message and is recorded as a new Disruption object linked to the Plant.

Links. Link types define typed relationships, one to one, one to many or many to many. From the Plant, the system follows links to the Parts it makes, then to open PurchaseOrders for those parts, then to the customer orders that depend on them. A traversal like this, called a search around, returns up to 100,000 objects by default. In seconds the planner sees which customers are exposed instead of assembling that picture by hand.

Actions. The response is an action type called, say, Reallocate order. Its submission criteria decide who may run it and under what conditions. A function holds the logic, such as moving volume to a second supplier within contract limits. A webhook pushes the change to the ERP. Every submission lands in the action log, so the decision itself becomes data.

AIP agent. An agent built in AIP Agent Studio can do the first pass. It queries the linked objects, calls a scoring function to rank alternative suppliers, and proposes the Reallocate order action. Depending on configuration, the action runs automatically or waits for the planner to confirm. Either way it runs with the planner's permissions, so the agent cannot see or change anything she could not.

The documented features cover data, logic, action and delivery.

• Ontology and OSDK: object types, link types, action types and functions, plus a software kit that lets developers build apps on the model.
• AIP Logic: a no code tool for building functions powered by LLMs that read and write the Ontology through defined tools.
• AIP Agent Studio: agents that query objects, call functions and apply actions, with actions set to run automatically or after user confirmation.
• Workshop and Automate: application building and scheduled or event driven workflows, with Automate runs lasting up to four hours.
• Model choice: models from xAI, OpenAI, Anthropic, Meta, Google, Mistral and NVIDIA, plus a bring your own model option.
• Ontology MCP: exposes object types, actions and query functions as MCP tools to external agents such as Copilot Studio, Claude and Gemini Enterprise.
• Iceberg tables: managed and virtual Apache Iceberg tables, including tables registered from external catalogs.
• Developer Tier: limited self serve access to Foundry and AIP, introduced in 2024.

Under the hood, the model is transactional and the permissions travel with the data.

Palantir describes the Ontology as a four fold integration of data, logic, action and security, built in three layers: a modelling language, a read and write engine, and a developer toolchain. The unusual part is the write path. Most semantic layers are read only. Here, edits are atomic transactions that flow back out to operational systems.

Object Storage v2 separates indexing from querying so each can scale on its own. The documented limits are tens of billions of objects per type, 2,000 properties per type and 10,000 objects edited in one action by default. Functions run for 60 seconds by default. TypeScript v1 functions are capped at 128 MB of memory, while TypeScript v2 and serverless Python can be configured from 512 to 5,120 MiB.

Apollo uses a hub and spoke design. A hub's orchestration engine issues plans. A control plane inside each spoke environment carries them out locally and reports back. Because spokes act on their own, the same model works on air gapped networks with no live link to the hub. Releases move through DEV, RELEASE_CANDIDATE and RELEASE channels.

Security uses markings. They are mandatory, and a user must hold every marking on a resource to see it. They carry over to anything derived from marked data, and even a dataset owner cannot remove one without a separate permission. The same model governs people and agents, which is what makes letting an agent act a manageable risk.

The team seems to follow four ideas.

These ideas explain choices that look odd from outside, such as spending years on deployment tooling before AI was fashionable, or insisting that agents act through the same action types as people rather than through direct database access.

• Capture the decision: every action is logged against the objects it touched, so later automation has history to learn from.
• Guardrails in structure: an LLM can only ask for a tool call, and the call runs with the user's rights, not the model's.
• Build for the hardest place first: software designed for classified and disconnected networks also works in a commercial cloud.
• Models are replaceable: the Ontology, permissions and action definitions are the durable asset, and the LLM is a component.

Some of the stack is public and some is not.

• Confirmed: Apache Iceberg as the primary table format, TypeScript and Python for functions, MCP for external agents, and OAuth 2.0 for Ontology MCP access.
• Confirmed: Apollo manages environments such as a set of microservices in a single Kubernetes cluster.
• Unconfirmed: the internal databases and search engines behind Object Storage v2 are not publicly documented.
• Unconfirmed: how Palantir hosts models inside classified environments beyond what the supported models page states.

Growth came from engineers on site, then from compressing the first mile.

For most of its history, Palantir sold through forward deployed engineers who worked inside customer environments to connect messy data and build workflows with users. It was slow and people heavy. The platform now absorbs much of that work. Bootcamps put a prospect's team on the product with their own data, and Palantir's annual reports say they deliver real workflows in days. The same reports note that Palantir funds these pilots itself, with no guarantee they convert.

Adoption is clearest in government. In 2025 the US Army folded 75 contracts into one enterprise agreement worth up to $10 billion over ten years. Maven Smart System, built on Palantir, had more than 20,000 users in May 2025 and more than 100,000 by April 2026, and it is moving to a formal program of record by the end of fiscal year 2026.

Health care shows the limits of headline numbers. NHS England figures reported in June 2026 put 168 of 214 trusts signed up to the Federated Data Platform and 123 live. Reporting also found many trusts with access rarely log in, and in July 2026 the UK statistics regulator asked NHS England to be clearer that its benefit figures do not prove cause and effect.

The tradeoff runs through all of this. The model that makes agents safe to use is also proprietary, and every decision a customer encodes raises the cost of leaving. In 2017 the NYPD publicly disputed Palantir's handling of analysis it wanted to export. Iceberg keeps the raw data portable today. The decision logic is harder to move.