What does Palantir actually do?

A company can have a warehouse full of data and still need six people on a call to answer a simple question: can we move this order to another factory?

The inventory system knows where the parts are. The maintenance system knows which machine is unavailable. Someone in logistics knows the truck has already left. Each answer exists. Getting them into the same conversation is the work.

Palantir sells software for bringing those pieces together, building applications around them and connecting decisions to actions. Its customers include businesses and government organizations. AI is now a prominent part of the offering, but the underlying problem is older than the chatbot: organizations need their software to understand enough about their operations to help people run them. Palantir’s platform overview describes that combination as data, logic and actions.

Four names, different jobs

Foundry is the data-and-application platform. Teams use it to connect information from existing systems, transform it, analyze it and build operational software. Gotham serves intelligence and defense workflows, where analysts and operators need to work with complex information and relationships. These are areas of emphasis, not a clean rule that businesses get Foundry and governments get Gotham: Palantir describes government customers using both. Foundry platform documentation, Palantir’s intelligence offering.

AIP, short for Artificial Intelligence Platform, connects AI models to an organization’s data and workflows. Apollo handles software deployment and management across environments. They address different parts of the same practical problem: make useful software, give it the right information and capabilities, and keep the deployed system working. AIP overview, Apollo introduction.

The names can make this sound like four mysterious machines. A factory example is more helpful.

Foundry gets the pieces into the same room

Consider an illustrative manufacturer with two factories.

An order for 400 pumps is scheduled at Factory A. A machine there will be unavailable tomorrow. Factory B has capacity, but its inventory application calls a required component “seal-kit-07,” while the purchasing system calls the same item “SK7.” A planner wants to know whether moving the order will still meet Friday’s delivery commitment.

Before anyone asks AI, the systems need to agree on what they are talking about.

Foundry provides connectors for bringing data from external systems into its environment. Its Data Connection tools support synchronization and outbound connections; transformation tools then prepare data for use. A pipeline is the sequence of steps that turns source records into something dependable enough for an application to consume. In this example, those steps could reconcile the component identifiers, standardize dates and combine inventory with production schedules. Data Connection overview, Foundry data pipelines.

That reconciliation is consequential. If “SK7” and “seal-kit-07” remain unrelated, the software may report a shortage even when the part is sitting on a shelf. If two genuinely different components are merged, the answer can be confidently wrong in the other direction. Connecting systems creates the opportunity to resolve those meanings; the connector cannot decide the business truth by itself.

Once the data is usable, there is another question: how should applications represent the business?

The Ontology gives the data a working vocabulary

Palantir calls its operational model the Ontology. The word sounds more intimidating than the first idea behind it: represent the things the organization works with and the relationships between them.

Our manufacturer might define an Order, Factory, Machine and Component. Each object has properties, such as a delivery date or machine status. Links connect an order to the components it requires and the factory assigned to build it. Palantir’s Ontology sits above integrated data and models, connecting these digital resources to real-world entities. It also includes ways to express logic and actions, rather than stopping at a catalog of information. Ontology overview.

For the planner, that means the application can follow the order to its required components and then to stock at Factory B. The planner does not need to remember which database column contains each answer. For developers, the same business concepts can become reusable building blocks instead of being reconstructed inside every application.

The model becomes more interesting when the planner decides to move the order. An Action can package changes to objects and relationships, with defined inputs, rules and permissions. In our example, a “Reassign production” action could take an order and destination factory, check configured conditions and change the assignment. That workflow would need to be built; it does not arrive merely because somebody creates an Order object. Action types.

This is why a dashboard alone is an incomplete comparison. A chart can reveal the scheduling problem. An operational application can carry the decision into a controlled change. Both are useful, but the second has a longer journey to complete.

AIP brings AI into that journey

Now the planner asks, “Can we move the 400 pumps to Factory B and still deliver Friday?”

An application built with AIP could use an AI model to interpret the question, retrieve relevant operational context and help prepare a response or proposed action. AIP provides tools for building AI-powered workflows, functions and agents, including AIP Logic, Chatbot Studio and evaluation tooling. An agent here means software that can use configured tools while working through a task, not just produce a paragraph of text. AIP documentation.

Palantir’s role in this arrangement differs from that of the company supplying the underlying language model. AIP supports models from other providers and options for connecting customers’ own models or provider accounts. Availability depends on the deployment and supported configuration. Calling AIP “Palantir’s ChatGPT” misses the work of connecting a model to enterprise information, application logic and permitted operations. Supported models, bring-your-own-model documentation.

For our manufacturer, we could give the language model the job of interpreting the planner’s request and summarizing the alternatives. Code or an optimization model would calculate whether capacity, components and transport can support the move. The application would present the proposal, and an authorized planner would approve the reassignment.

Suppose Factory B can build 500 pumps in the available slot and has 420 unreserved seal kits, with one kit required per pump. The 400-pump order fits both constraints. If confirmed transport can still deliver Friday, the application can propose the move and show those inputs. Change available kits to 380, and spare machine capacity no longer makes the plan feasible. The planner can see the 20-kit shortfall and ask whether a transfer from another location would close it in time.

That follow-up is where conversational AI can earn its place. The planner can explore another possibility without hunting for a different report and rebuilding the question. Underneath the conversation, the application still has specific work to do: find eligible stock, calculate timing and return the evidence for the proposed plan. A better language model may make that interaction smoother; it cannot make the missing kits appear.

When the decision reaches the scheduling system

Changing the assignment inside an application may still leave the factory’s scheduling system untouched. To make the move real, the workflow needs an integration that updates the system used on the factory floor.

Foundry supports webhooks, configured requests to external systems. Its documentation distinguishes two behaviors: a writeback webhook runs before object changes, whereas a side-effect webhook runs afterward. With a side effect, a user can see success for the Foundry change before the external operation has completed. A writeback avoids applying Ontology changes when the external request fails, but it does not guarantee an all-or-nothing transaction across both systems: the external request can succeed and the later Ontology update can fail. Webhook behavior.

For the pump order, that leaves a very ordinary engineering question inside the grand AI story: which system now believes Factory B owns the work?

This is where site reliability engineering, or SRE, has something concrete to contribute. A production implementation should make it possible to trace a proposed move to its approval, the outbound request and the resulting assignment. If the response is lost, the integration needs a way to discover what happened before trying again. Otherwise a reasonable retry could repeat a change that already took effect.

The same trail makes a correction possible. If the planner spots the wrong destination, the team needs to know whether it can still cancel a proposal or whether it must undo an assignment in the scheduling system. Those are different operations. Giving an agent permission to suggest a move need not give it permission to submit one, and permission to submit one does not automatically supply a way to reverse it.

Apollo gets an update to the right place at the right time

The planner now has an application worth relying on. That creates a less glamorous obligation for its engineers: keep improving it without interrupting the people using it.

Apollo is Palantir’s deployment and software-management platform. It coordinates releases across environments, including cloud, on-premises and disconnected installations. A release is a particular version of software; an environment is a place where that software runs. Apollo allows developers and environment operators to express conditions that must be satisfied before a change proceeds. Apollo introduction.

Suppose our manufacturer runs separate installations of its planning service at the two factories. Version 2 adds a better transport calculation, but needs version 3 of a supporting service. Factory A has that dependency; Factory B is still on version 2. Sending the new planner everywhere at once would leave Factory B running software against a dependency it cannot use.

Apollo’s documented product-dependency constraints let a team declare the permitted versions. Its deployment engine checks those conditions before issuing a plan, the instructions to make a change. With that dependency configured, Factory B’s upgrade waits. A maintenance-window constraint can also hold an otherwise eligible update until the time the local operator has allowed. The blocked plan exposes the reason, so an engineer can distinguish “waiting for the dependency” from “waiting until tonight.” Plans and constraints.

The release can also move through channels, such as an early-testing group followed by a stable group. Environments subscribe to the appropriate channel, and configured health criteria govern promotion between them. This gives a team a way to learn from a smaller deployment before offering that version more widely. The criteria still have to measure something meaningful about the software. How Apollo works.

That brings us to observability: understanding a running system through evidence such as metrics, logs and request traces. Apollo’s introduction explicitly describes integration with existing monitoring tools, including Datadog and Prometheus. A team could continue using its tracing system to investigate a slow scheduling request while using Apollo to inspect the deployed version and its rollout history. There is no need to squeeze all of Palantir into the category of “observability replacement” to explain the benefit. Apollo and existing monitoring.

Gotham lets an analyst follow the connections

Gotham serves intelligence, defense and investigative work, where the starting question may be less tidy than an order with a delivery date. An analyst may have reports, locations, events and organizations spread across sources, and need to establish how they fit together.

Palantir’s public 2024 Gotham service definition describes applications that work on a shared data foundation. An analyst can explore relationships in Graph, examine geography in Gaia and assemble findings in Dossier. Moving between these views lets the analyst ask different questions of related information without rebuilding the investigation from separate exports. Gotham service definition, pages 3–5.

In a hypothetical supply-network investigation, delivery records connect two vendors to the same warehouse. A relationship view makes that shared location visible; a geographic view helps place it among the other facilities involved. The analyst opens the underlying records and discovers that the warehouse serves many unrelated companies. The connection was worth examining, but it supports a different explanation from common ownership. A report can carry that finding and its supporting material to colleagues. The point of the connected workspace is that an analyst can follow the question while keeping the evidence close at hand.

This work also shows why permissions and provenance matter. Provenance is the record of where information came from. A colleague needs to distinguish a source report from an analyst’s interpretation, and being allowed to see one part of an investigation need not grant access to everything connected to it. Gotham’s public documentation describes granular permissions and audit records for access and activity. Gotham security documentation.

When the objects represent people and the decisions affect their liberty or safety, the consequences extend far beyond a bad production schedule. In August 2025, Amnesty International raised human-rights concerns about Palantir’s work with US Immigration and Customs Enforcement, including ImmigrationOS, and the risks of surveillance and harmful immigration enforcement. Those concerns address what connected information enables authorities to do, not merely whether a database is protected from intruders. Amnesty’s assessment.

Palantir describes privacy and civil-liberties protections in its products, while its own implementation guidance states that technical controls do not determine whether a use is lawful, necessary or proportionate. An access rule can enforce a decision about who may view a record. The justification for collecting it, linking it to other records and acting on the result still requires scrutiny of the institution and the purpose. Palantir’s privacy and civil-liberties guidance.

Where the value comes from, and what it costs to keep

Palantir is most interesting when a decision repeatedly crosses systems, teams and permissions. The factory planner benefits if inventory, capacity and approved changes become one usable workflow instead of a daily scavenger hunt.

Building that workflow still requires people who understand the operation. Someone must decide what counts as available inventory, which application owns the schedule and who may override it. When the business changes, its software model needs to change too. The Ontology makes those decisions explicit and reusable; maintaining that shared understanding remains work.

There is also a tradeoff in adopting an integrated platform. Keeping data preparation, business models and applications close together can reduce the glue a team builds. Foundry supports exporting data to other systems, but consider what moving our manufacturer’s application would involve. Exporting the order records would preserve the assignments. It would not, by itself, recreate the reassignment screen, the rule that checks capacity or the permissions governing approval. Those behaviors would need an equivalent home, and someone would have to verify that the new workflow still means the same thing. Foundry export capabilities.

For a small team with one clear database and a straightforward process, the same outcome might be easier to build with its existing tools. For an organization whose work spans many incompatible systems, the integration itself can be a substantial part of the product’s value. The comparison needs to include the people and time required to build, maintain and eventually move those workflows.

Our planner’s question now has a more useful answer than it had at the start. With 420 available kits, enough machine capacity and suitable transport, there is a feasible proposal to approve. With 380 kits, there is a specific shortage to resolve. After approval, the scheduling system’s assignment tells the team where the work will happen.

Getting those answers into one working conversation is what makes this kind of software valuable. The six people from the opening may still need to talk when an unusual case comes along. They can spend that conversation deciding what to do, with the parts, schedule and consequences in view, instead of first trying to discover which system has each piece of the answer.

Documentation reviewed October 22–23, 2026. The Gotham application example draws on Palantir’s public 2024 service definition. This is an explanatory article, not a hands-on product review; capabilities and availability vary by deployment.