What is Palantir - Part 6: The workflow platform you already own

This series has been working through Palantir's Foundry one software category at a time. Part 1 covered what the platform is. Part 2 covered the data capabilities you would otherwise buy from a warehouse vendor. Part 3 built the Ontology, the part with no equivalent elsewhere. Part 4 covered the analytics a business intelligence stack promises. Part 5 covered the screens a low-code app platform builds.

This part closes the loop on the fourth category: the workflow platform.

Most enterprises run one. It watches for something, decides what to do, routes it to a person when it has to, and keeps a record. It is usually near the top of the software budget, and it arrives with its own structure for your business.

Foundry does all of it, on the structure you already built.

What a workflow platform sells you

Strip the branding off any of them and the same list appears.

• A canvas where you draw the process, with branches and loops
• Something that watches, and starts the process when a condition is met
• Judgement inside the steps, not just comparisons
• A way to take in the documents and forms that work arrives as
• Testing, before it touches anything real
• A picture of the process as designed, and a check on whether reality matches
• Monitoring, so someone hears about it when a workflow stops
• A view of what depends on what, and a way to change it in bulk
• Change control, so nobody edits a live process by hand
• An audit trail, and an answer to who this ran as

Foundry has all ten. Nine applications cover them, and one of the ten is better than the category usually manages.

The canvas

Foundry's Workflow Builder is the piece that looks most like what you already have. Palantir describes it as "a unified workspace for building, testing, and monitoring automated use cases with the Ontology."

It is a graph. Each step is a node, and the connections between nodes set the order and carry objects from one step to the next. One graph can hold several workflows.

There are seven node types. A trigger starts things, on a schedule or when an Ontology object changes. A compute node runs an existing function, or builds a transform without code. A use-LLM node runs an AI model and can call Ontology tools while it works. A fork branches the path on a condition. An effect calls an action, or deliberately does nothing. A loop iterates over an object set. A subgraph groups nodes into a reusable unit.

Forks and loops nest inside each other, and each has a paired node that runs once all the branches or iterations finish. This is the shape of real process logic, not a rule that fires once.

Workflow Builder is in beta and may not be enabled on your enrollment. It already supports Marketplace and Global Branching.

The judgement inside the steps

A workflow platform gives you conditions. Real process logic usually has to weigh something rather than compare it.

Foundry's AIP Logic is where that gets built, without code. A function is assembled from blocks, each one taking an input and returning an output, with one block's output feeding the next. Palantir's own list of what blocks do: read or write the Ontology, perform a calculation, aggregate data, call other functions, or interact with an LLM.

Six are named as the commonly used ones: Use LLM, Apply action, Execute function, Conditionals, Loops, and Create variable. That list is Palantir's own selection of what gets used most, not a claim that it's all there is. Apply action is worth noticing on its own. It calls an action without an AI model in the path, so the parts that should be certain stay certain.

Use LLM is where the judgement happens. It takes a prompt, a set of tools, and the shape of the answer you want. Four tools are available inside it: Apply actions, Call function, Query objects, and a calculator for arithmetic that has to be right. The AI model never touches those tools directly. It can only ask, and AIP Logic executes the call within the permissions of the person who invoked the function.

One rule holds for all of it. Ontology edits only land if the function is published and called from an action, even when the function contains an Apply action block.

Testing it on real objects, before it touches anything

This is where the category usually asks you to trust a test environment.

You preview a workflow while you build it. Pick real objects, several at once, and watch each one move through the graph. You see the exact path it takes, including which branch it followed at a fork. The preview re-runs live as you edit, so a change shows its effect immediately. Hover a node to see what it held. When the run finishes you get a list of every object created, edited or deleted.

Where an AI model is in the path, testing needs more than a walkthrough. The same input can produce a different answer on Tuesday than it did on Monday.

Foundry's AIP Evals covers that. An evaluation suite is "a collection of test cases and evaluation functions used to benchmark a target function's performance." Each case carries a known input and an expected value, and a case passes only when every metric meets its objective. You run it on every change to the prompt, the AI model or the logic, and set it beside the last run.

A pass rate against an agreed suite is something a risk function can read. It is also written by the people who want to ship, so it buys reproducibility rather than independence.

Taking in the documents

Work arrives as a document more often than as a field. A delivery exception turns up as a PDF attached to an email.

Foundry's AIP Document Intelligence is the platform's entry point for document extraction. You try strategies against real documents and compare what each returns. They run from metadata and layout-aware OCR up to a vision model with a prompt you tune. The extracted text maps back to bounding boxes on the original page, so a value can be traced to where it came from.

It deploys as a pipeline transform, or as a per-page function you orchestrate.

The process as designed, and the process you have

Two applications cover the design half.

Foundry's Solution Designer draws the architecture before anything is built. AIP Architect generates a plan from your requirements, and AIP Critic reviews it in conversation.

Foundry's Machinery draws the process as a state machine over an object type whose possible states must be enumerable. Every object sits in one state at a time, and actions mark the transitions. You mark which are automated and which need a person.

Then it does the part a drawing tool cannot. It mines the real process out of your event log and lays it over your design. Amber marks paths the data takes that you never drew. A dashed line marks a step you drew that has never once happened.

Conformance filtering computes metrics only over the processes that follow the design, keeping the deviating ones hidden until you look. The event log behind it can carry an identifier separating manual actions from automated ones. That field is optional, so the attribution is only as good as your log.

The log lags the live objects by a build and an indexing job, typically two to five minutes. This is an assurance surface, not a live console.

Hearing about it when it stops

The failure nobody plans for is not a wrong decision. It is a workflow that quietly stopped in March.

Foundry's Automate is the trigger layer behind all of this. It is where a condition watches on its own, rather than as a node on a canvas. Object changes are caught live, within minutes. A threshold crossing runs on a schedule someone sets. Failure handling is configured rather than assumed, with retries between one and five and a fallback once those are exhausted.

Foundry's Autopilot shows where things are stuck, drawing the workflow as a state machine with a column per state and a card per object. Its events tab carries per-object trace logs with stack traces, and you can retry one object or a filtered set. It is in beta, and an administrator switches it on.

Nothing in it pages anyone. Foundry's Monitoring views does that. Its rules are named for the questions you would ask, and "Automation has no new triggers" is the one that catches a workflow that stopped. Alerts reach subscribed users inside Foundry and services outside it, with named integrations for PagerDuty, Slack and webhooks.

Two stop buttons exist and they differ. Muting keeps the condition running while no effect fires. Pausing stops everything, including work already under way. Mute to keep the evidence coming while the consequences stop. Pause to stop it now.

Changing it without breaking something else

Before you touch a live process you need to know what depends on it.

Foundry's Workflow Lineage opens a workflow and shows its objects, actions, functions and applications, each carrying its inputs, Ontology edits and submission criteria. An AI model carries its lifecycle stage, so a deprecated one is visible before it bites.

It also makes the change. You can update action versions in bulk, swap an AI model across many Logic functions at once, and edit submission criteria without raising a proposal. That is what decides whether an estate stays maintainable once there are more workflows than one person can hold in their head.

Then the change itself. Global Branching covers automations alongside Workshop modules, Logic functions and Ontology actions. A change is built and tested on a branch rather than against the live operation. Palantir's rule: "all required approvals for the automation must be satisfied before the branch can be merged."

Who it ran as, and what survives

An automation has an owner and runs on that owner's permissions. Conditions are evaluated as the owner, and effects execute as the owner. Notifications work the other way, rendering against each recipient's own clearance. A control that runs as one named person belongs in your leaver process.

Automation history records when a condition is met, when it recovers, and when someone edits, pauses or mutes it. It is kept for six months. What survives after that is the action log on the object and the platform audit log.

The decision also has to reach people who do not work in Foundry. Action types carry side effects beyond the Ontology edit, and a webhook sends the decision and its reasoning into a system the team already uses. That call runs outside the single Foundry transaction, and its failure is not reported in the action's result, so it is the step to instrument.

The part that does not move

Take a manufacturer whose supplier starts slipping. A trigger notices. A node reads the exception notice and decides whether it matters. You watched a real purchase order take that exact path before any of it went live, and an evaluation suite proved the judgement holds up. Machinery shows how many orders took a route nobody designed. Monitoring pages someone when the whole thing stops. Lineage says what breaks if you change it, and Branching makes the change safely.

That is a workflow platform. All ten capabilities. The testing goes beyond what the category usually delivers, because you run real objects through a real graph and watch where they go.

The difference is underneath. A workflow platform bought on its own arrives with its own structure of your business. Its own idea of what a supplier is, its own copy of the purchase orders, its own definition of late. The warehouse has the same problem, and so do the reporting layer and the app platform. Four products, four structures, and the work is keeping them in step.

Foundry's workflow layer reads the Ontology from Part 3. The same objects the analytics in Part 4 read. The same objects the apps in Part 5 act on. One structure, four categories.

That is the argument. Palantir is not competing with a workflow vendor. It is competing with the assumption that you need a different product, holding a different structure, for each thing you do with your own data.

What none of this handles is the question nobody wrote a rule for. How exposed are we if this supplier fails again during monsoon season? That needs an AI model that can read and reason over what it finds. Which AI model, where it runs, and what leaves your boundary when it does, is a decision of its own. Part 7 starts there.