Palantir Ontology Functions: Turning Business Logic into Reusable, Typed Assets for Agents

The article opens with a common problem: business logic lives in multiple places — planner applications, approval pages, Excel formulas, and Agent prompts — causing inconsistent results when rules change. Palantir Functions solve this by turning logic into a named, testable, monitorable asset that multiple consumers can call.

What Functions Do

A good Function typically handles one of four tasks:

Compute a derived value or metric from the current object state.

Query an object set, traverse links, and perform real‑time aggregation.

Orchestrate model calls, platform APIs, or external systems, translating technical I/O into business results.

Calculate a complex set of edits for a Function‑backed Action, which then submits them.

All these tasks need current business objects and relationships, have explicit inputs and outputs, and are reused by more than one application.

Using Business Objects as Inputs

Traditional backend APIs require callers to assemble dozens of primitive fields (order_id, site_code, vendor_no, etc.) and know how to handle missing values. An Ontology‑aware Function can accept a Purchase Order object directly. It reads quantity and expected delivery date, follows links to Supplier, Product, and Warehouse, and pulls historical fulfillment, current inventory, and demand forecasts — all without the caller knowing the underlying tables.

Example signature: evaluateExpediteOptions(purchaseOrder) The output is a structured business result, not a raw array:

缺货风险：高
预计缺货：5 天
可选方案：空运 / 分批到货 / 仓间调拨
建议：先调拨，不足部分加急采购
依据：库存、在途、供应商履约、需求预测

The key value is a unified business contract: operational apps, approval pages, Agents, and API callers all see the same result.

Four Tools, Different Responsibilities

Confusing shared logic with the wrong tool creates another form of chaos. The article distinguishes four tools by asking: who triggers? when does it run? read or write? data volume?

Pipeline — Suited for: Large‑scale cleansing, joining, pre‑computation. Typical example: Recalculate inventory health for all products daily.

Function — Suited for: On‑demand computation for current objects. Typical example: View expedite options for a specific purchase order.

Action — Suited for: Controlled business modifications initiated by a person or Agent. Typical example: Confirm expedite purchase and record reason.

Automation — Suited for: Automatic reaction when event or time conditions are met. Typical example: Notify planner after supplier delay.

Rule of thumb: if ten thousand users see the same result, don’t let ten thousand pages recompute it. Modifications that need human confirmation must not hide inside a Function.

Function Computes Edits, Action Executes

Palantir Functions can return Ontology edits (create, update, delete objects, update links), but running them in the debugger does not mutate real objects. To commit changes, the Function is wired to a Function‑backed Action.

This separation enforces responsibility:

Function answers: what objects, properties, and links must change to perform the business operation?

Action answers: who initiated the action, under what conditions, is submission allowed, and how should it be recorded?

For example, calculateExpediteEdits generates the edit set; Approve Expedite Request is the user‑visible business action.

Function handles deterministic logic; Action handles controlled world‑changing.

Functions as Stable Tools for Agents

Without a shared Function, an Agent asked “Help me decide if this purchase order needs expediting” must locate the order, query inventory, read supplier history, call the forecast model, and reconstruct the company’s judgment rules from its prompt — both finding data and inventing the algorithm.

With evaluateExpediteOptions(purchaseOrder), the Agent’s job reduces to:

Identify the referenced Purchase Order.

Call the Function to get structured risk and alternatives.

Combine user intent and permissions to explain the recommendation.

If a write‑back is needed, propose or invoke the corresponding Action.

Deterministic knowledge — how to calculate inventory gap, risk thresholds, which supplier records to include — stays in the Function. When rules change, the team updates one version‑controlled, tested Function instead of hunting through ten Agent prompts.

Managing Functions as Production Software

Because shared Functions gain many downstreams (Workshop pages, Actions, Automations, OSDK apps, Agents), they must be treated as production software. Four essential practices:

1. Treat Inputs and Outputs as Contracts

Prefer business objects, interfaces, or meaningful structures over dozens of technical fields. Adding a required input, removing an input, or changing an output type is a breaking change.

2. Write Tests for Business Boundaries

Palantir Functions support unit tests with stub objects, Ontology edit validation, and object query/aggregation testing. Tests should cover edge cases: inventory exactly zero, supplier with no history, user selects an already‑cancelled order.

3. Monitor Latency and Failures

Track p95 execution time and total failures. Distinguish user‑understandable business errors (“order already cancelled”) from system errors (“external service timeout”) in monitoring.

4. Don’t Turn Page Scrolling into Large‑Scale Computation

Function‑backed columns recompute on demand as users scroll. This flexibility carries real cost: object queries, external calls, model inference. Reuse results via batch computation, batch queries instead of per‑item loads, and parallelize independent calls.

Eight Questions to Decide If Logic Warrants a Function

Before writing code, ask:

Does the logic depend on current Ontology objects, properties, or links?

Is it on‑demand or can it be pre‑computed in batch?

Will many users repeatedly view the same result?

Will two or more applications, Actions, or Agents reuse it?

Can inputs be expressed as business objects or meaningful parameters?

Is the output a value, object set, structured result, or pending edits?

What business error should the user see on failure?

Which tests, versioning, and monitoring metrics give downstream confidence?

If questions 2 and 3 both point to batch reuse, a Pipeline is often better. If question 6 yields edits, design a meaningful Action — don’t hide the write‑back.

Not All Formulas Need Assetization

One‑off analysis formulas don’t need immediate company‑wide Functions. While rules are unstable, validating in a single app is normal. Stable, large‑scale, pre‑computable results shouldn’t be forced into Functions just for “real‑time” appeal. External systems don’t gain stability or transaction guarantees merely by being called from a Function.

A practical signal: the same business logic has been copied to a third place, or it starts being invoked by an Agent as a production tool. At that point, the real design questions are who defines the logic, who owns versioning, and who is accountable for results.

Functions move the Ontology from “a set of business nouns” to “a set of reusable business capabilities.”

References

Palantir Docs: Functions overview — https://www.palantir.com/docs/foundry/functions/overview/

Palantir Docs: Functions on objects — https://www.palantir.com/docs/foundry/functions/functions-on-objects/

Palantir Docs: Use functions in the platform — https://www.palantir.com/docs/foundry/functions/use-functions/

Palantir Docs: Ontology edits — https://www.palantir.com/docs/foundry/functions/edits-overview/

Palantir Docs: Optimize performance — https://www.palantir.com/docs/foundry/functions/optimize-performance/

Palantir Docs: Function monitoring — https://www.palantir.com/docs/foundry/functions/monitoring/

Palantir Docs: Function versioning — https://www.palantir.com/docs/foundry/functions/functions-versioning/

Palantir Docs: Unit testing — https://www.palantir.com/docs/foundry/functions/unit-test-getting-started/