You built the whole screen with LEGO and it works fine — so why does it look so cluttered, and why won't this one button do what you want?

Building a Workshop screen is a lot like building a LEGO house

Building a screen in Workshop resembles building a house out of LEGO. Snap the pre-made bricks (widgets) together via their studs (variables), and you get a fairly convincing result fast, without writing a line of code. Widget placement and variable binding itself was already covered in a separate article, so here we cover what comes next — why a house built entirely from LEGO can still look cluttered, and what happens when you need a brick shape that isn't in the set.

The instruction manual for a tidy LEGO house — official layout principles

Palantir's official documentation lays out specific numeric guidelines for designing a Workshop screen.[1]

• Keep primary actions per screen to 5 or fewer. Cram too many functional bricks into one set, and users can't tell what to click.
• Avoid more than 10 components in a single view. Pack the bricks too densely and the finished shape disappears.
• Maintain 30-40% whitespace. Even a LEGO set's product photo needs background space for the build to stand out.
• Choose a layout pattern: grid (left-to-right flow), column (top-to-bottom flow), or mixed (fixed filter panel on the left, expanding content on the right).
• Use the default typeface (Source Sans Pro) or an installed system font. A custom font silently falls back to the default if it isn't installed.
• Use shadows only to signal hierarchy. Drop shadows for important sections, inset shadows for lower priority — overuse this rule across the whole screen and the hierarchy disappears entirely.

There's even a way to verify it — squint at the interface.[1] If the important elements still stand out when everything's blurry, the hierarchy is working. If everything looks the same, go back and recheck the 5-actions-or-fewer rule first.

When you need a brick that isn't in the set — the customization ceiling

LEGO's strength is fast assembly from a fixed set of bricks, and its weakness is exactly the same thing — a shape outside the set simply can't be built. Workshop is no different. Real reviewers' experiences land squarely on this point.

One reviewer working as a Palantir Foundry developer put it plainly:

"The Workshop application could be improved because it is not very customizable"[2]

A more specific case: a software engineer at a retail company recalled:

"the Workshop application has some widgets inside that we wanted to modify, but when we reached out to Palantir, they informed us that it was a design decision"[2]

In other words, a given widget's behavior isn't a bug — it's something Palantir deliberately designed that way. Once you hit that boundary, you have two options: work around it within the constraint, or move to Slate (Palantir's code-based application builder) and build the custom UI yourself.

One specific wall people actually hit: URLs that won't become hyperlinks

The Palantir Developer Community has a real thread documenting someone running into exactly this "brick that isn't in the set." A user had concatenated local variables into a URL string inside a Property List widget, and asked how to render it as a clickable link.

The response from staff member Phil-M acknowledges the limitation directly:

"local variables can not be part of vanilla URL" ... "there is no way to display/value format the resulting string as hyperlink"[3]

Two workarounds were offered instead.[3]

1. Use a function-based column that takes the local variables as input and concatenates the string, then have the user right-click to copy the value.
2. Use a looped layout to display each object individually, then render the URL as rich-formatted text inside a Markdown widget.

To carry the LEGO analogy through: when the exact brick shape you need isn't in the set, you combine two or three similar bricks to approximate it. It works, but it's a step you wouldn't have needed if that brick had existed in the first place.

So how is it different from Retool or Appsmith?

I looked for a discussion directly comparing Workshop to general-purpose no-code tools like Retool or Appsmith, but couldn't find one that actually compares all three. Instead, here's the structural difference based on each tool's official scope: Workshop is natively bound to the Ontology (Object Types, Link Types) and can't connect directly to an arbitrary database outside Foundry, while Retool and Appsmith connect directly to general-purpose data sources like PostgreSQL, REST, and GraphQL. This isn't a matter of one being better — it reflects that Workshop was designed from the outset for the narrower purpose of "operational screens on top of the Foundry Ontology."

A practical decision framework

1. Screen doesn't respond → check the binding. Start with the Object Set variable and Active Object variable connections covered in the earlier article.
2. Screen works but looks cluttered → check the layout principles. Start by counting components (10 or fewer) and whitespace (30-40%).
3. Can't customize something the way you want → check whether it's an intentional constraint first. Before filing a bug report, searching the official docs or community for "design decision" can save time.
4. If the custom behavior is truly necessary → consider switching to Slate. When you need behavior outside Workshop's preset widgets, moving to the code-based builder is often faster in the long run than repeating workarounds.

FAQ

Q. Can I use custom CSS in Workshop? Preset widget styling (shadows, padding, color emphasis) can be adjusted within configuration settings, but injecting arbitrary CSS isn't an official workflow. If you need that level of customization, Slate is the right thing to look at.

Q. If a widget behavior is labeled a "design decision," is there no way around it? It means it isn't officially supported — not that a workaround is always impossible. As with the URL-hyperlink case above, function columns or combining widgets differently can often achieve a similar effect.

Q. Do I really need to follow the layout rules (5 actions or fewer, 10 components or fewer)? They're official guidelines, not enforced rules. But once you exceed these numbers, it shows up immediately in the "squint test" — if you get feedback that a screen feels cluttered, counting against these numbers first is the fastest diagnosis.

References

[1] Palantir, Workshop • Application design best practices, Foundry official documentation.

[2] PeerSpot, What needs improvement with Palantir Foundry? — real user reviews (Palantir Foundry Developer, Software Engineer III).

[3] Palantir Developer Community, Help with Dynamic Variables and URLs in Property List Widget in Palantir Workshop — real user question + Palantir staff (Phil-M) response.

[4] Palantir, Workshop • Widgets, Foundry official documentation.

Keep reading

• Why Your Screen Won't React No Matter How Nicely You Arrange the Widgets
• You Know the Ontology Theory, But What Do You Actually Click — A Practical Guide to Ontology Manager

This article first appeared on AI Map Ontology, where I write practical guides on Palantir Foundry, ontology-driven architecture, and enterprise AI.

The evaluation section of this article — specifically the points about automatic updates occasionally breaking things, and support responsiveness compared to local vendors — is the author's personal, first-hand opinion, not something drawn from official sources. The description of Apollo's architecture and features is based on Palantir's official documentation.

What Apollo Does

Palantir Apollo is the continuous delivery (CD) platform that automatically deploys and manages Palantir software (Foundry, AIP, and more) across multiple environments. It spans cloud, on-premises, and even air-gapped environments completely disconnected from the internet. Official documentation describes it as "a constraint-based autonomous deployment platform that operates above the infrastructure layer across heterogeneous environments."[1]

Apollo originally started as Palantir's internal tool for deploying its own 500+ independently-released microservices across 300+ environments,[2] and today it's also used by customers to manage Palantir software — and their own applications running on top of it — in their own environments.

Hub and Spoke — Environments Pull Updates, the Center Doesn't Push Them

Apollo's core architecture splits environments into two types: Hub and Spoke.[3]

• Hub: The central repository holding product definitions, deployment settings, security/governance policies, and release promotion rules.
• Spoke: The actual target environments where software runs (Kubernetes clusters, edge hardware, and so on). Each Spoke runs a local orchestration agent that reports status back to the Hub.

The key design decision here is that Apollo is pull-based, not push-based.[3] Instead of a central system pushing out "deploy now" the way traditional CI/CD does, each Spoke's local agent continuously checks the current environment state against constraints — schema versions, inter-service dependencies — and requests and applies upgrades on its own once conditions are met. A single Hub can manage multiple Spokes, and a Hub can even manage itself.

Release Channels — Not Every Environment Updates at the Same Pace

Apollo doesn't push a release to everything at once. Instead, releases are promoted through stages called Release Channels.[4] Product teams define the promotion criteria between channels, and each environment subscribes to the channel that matches its stability requirements — test clusters typically subscribe to an earlier channel, production clusters to one that's already been validated.

Promotion isn't scheduled on a fixed timeline — it's driven by whether constraints are satisfied.[1][4]

• Are inter-service and schema dependency requirements met?
• Has the release passed its defined soak-time and health-check/SLO thresholds?
• Does it fit the environment's maintenance window and compliance approval rules?

Apollo also integrates with monitoring tools (Prometheus, Datadog, etc.) so that if real error rates cross a threshold, promotion can automatically pause or the deployment can be blocked outright.[1]

What Happens When Something Goes Wrong? Recalls and Rollbacks

The most important question for any automated deployment system is: how do you undo a bad release? Apollo handles this through a process called a Recall.[5]

A recall can be triggered three ways:

• Manually, by an engineer
• Automatically, through continuous vulnerability scanning (CVE detection) and similar checks
• Programmatically, via an API call from an external service

Once a recall fires, Apollo halts further propagation of that release and remediates affected environments using one of several roll-off strategies.[6]

• Roll Forward: Upgrade to a newer, non-recalled release that satisfies all constraints
• Allow Downgrade (Rollback): If rolling forward isn't possible, revert to a known-good earlier release at or above a specified minimum version
• Freeze All Version Changes: Hold the environment on its current release until a specified expiration date or a manual override
• Test Roll-off on Specific Environments: Apply the roll-off/rollback to designated test environments first, before rolling it out fleet-wide

The simple fact that "recall" and "roll-off strategy" exist as official, named procedures tells you something important: automatically-deployed releases do sometimes cause real problems, and Palantir designed the system around that assumption.

Sometimes an Automatic Update Just... Doesn't Happen: "Blocked Update"

Apollo's documentation also spells out a concrete case where automatic updates fail outright. For example, if a new Module version adds a new variable with no default value, Apollo can't automatically update that installation — it marks it as a "Blocked Update" and shows the reason why.[7] When this happens, someone with environment-editor permissions has to either fix the module definition to resolve the backward-compatibility issue, or update the installation manually.

This isn't something Palantir hides — it's documented, expected behavior. It also means the automation isn't trying to silently handle every case: it's designed to detect the cases it can't handle and hand them back to a human.

Everything From Here Is My Own Opinion

Everything above was based on official documentation. From here, this is my personal take, formed from working with autonomous deployment systems like Apollo in practice.

What's genuinely good about this: staying continuously current on patches and new capabilities is a real advantage. Nobody has to manually track versions or schedule upgrade windows, and the recall mechanism means security vulnerabilities can be addressed quickly.

Where it gets complicated: because all of this runs automatically, something that worked fine yesterday can just stop working today. A "Blocked Update" like the one above — where the system stops itself and tells you why — is the good case. The harder case is when behavior quietly changes underneath you, and it takes real time to figure out why.

And in that moment, I've found it's hard to expect the kind of fast, hands-on, in-person response you might get from a domestic vendor. That's not a statement that Palantir's support is bad — it's more that a global SaaS vendor's support model is simply designed differently from the "we'll send someone over right away" approach common among local system integrators and solution vendors. There's a real trade-off between the benefits you get from automation and the responsiveness of having a person immediately available when something breaks — and I think that's the realistic way to look at it.

Summary

• Apollo is a pull-based CD platform that automatically deploys and manages Palantir software across multiple environments.
• The Hub holds policy; each Spoke checks its own conditions and pulls upgrades on its own.
• Release channels and constraint-based promotion mean not every environment updates at the same pace.
• The existence of an official recall/roll-off process means Palantir's own design assumes automated deployment can fail.
• (Personal opinion) Staying continuously current is a real benefit — but it comes bundled with unexpected changes from automation, and comparatively slower hands-on support.

References

[1] Palantir, Introduction • Apollo, official Apollo documentation.

[2] Palantir Blog, Palantir Apollo: Powering SaaS where no SaaS has gone before, official Palantir blog.

[3] Palantir, Apollo • Getting Started, official Apollo documentation.

[4] Palantir, Overview • Core • Apollo, official Apollo documentation.

[5] Palantir, Recalling Releases • Overview, official Apollo documentation.

[6] Palantir, Recalling Releases • Roll-off strategies, official Apollo documentation.

[7] Palantir, Managing Modules • Update a Module installation, official Apollo documentation.

Keep reading

• Palantir Foundry Architecture Overview: From Connect to AI in Five Layers
• You Ran a Pivot Table and the Numbers Look Wrong — A Practical Guide to Foundry Contour

This article first appeared on AI Map Ontology, where I write practical guides on Palantir Foundry, ontology-driven architecture, and enterprise AI.

Throw everything into one box in a warehouse, and you'll have to search the whole box just to find what you need — the same is true for ontology design

Nobody gets ontology design right on the first try

Most ontology work starts the same way: "let's just get the data in first." The problem is that the Object Types pile up like a disorganized warehouse — nobody knows what's where, or how many places the same thing is stored in duplicate.

Palantir's official documentation catalogs these mistakes as eight anti-patterns.[1] We already covered "the same customer called by three different names" in a separate article, so here we'll walk through the other six that show up constantly in practice.

Mistake 1: Everything goes in one box — The God Object

Imagine a warehouse box labeled "Assets" that holds equipment, software licenses, real estate documents, and financial instrument contracts all at once. It looks convenient — open one box and everything's there — but finding anything specific means digging through the whole box.

That's the exact example the official docs use: cramming equipment, software licenses, real estate, and financial products into a single Asset Object Type.[1] This is the God Object. The fix is splitting each into its own Object Type, and modeling shared attributes (like "is this depreciable") through an interface instead.[1]

Mistake 2: Dragging along ETL leftovers — The Kitchen Sink

Nobody moving house keeps the shipping label and tape scraps from the box. But this happens constantly in ontology work. Migrating CRM data often drags along ETL processing metadata like _crm_extracted_at and _crm_batched_at as if they were real attributes.[1]

These fields mean nothing to a business user — they're just technical residue from the source system. The official principle is clear: only deliberately curate attributes that carry clear business or technical value.[1]

Mistake 3: Hammering everything with the same tool — The Golden Hammer

Even a well-organized person can wreck a warehouse by using the wrong tool — a screwdriver where a nail is needed, a hammer where a screw should be turned. In ontology work, this shows up as confusing Action Types with pipelines.

The official docs cite implementing bulk batch processing as an Action Type, or the reverse — handling decisions that need human judgment through an automated pipeline.[1] The rule: Action Types for human decisions, pipelines for automated bulk transformations.[1] Pick the tool that matches the nature of the work.

Mistake 4: Ten handles on one drawer — Action Sprawl

A drawer with ten handles is more confusing than helpful. In ontology terms, this is creating separate actions for "update employee name," "update email," and "update department" individually.[1]

In practice, name, email, and department changes usually happen together as part of one real business operation. The official fix: bundle related changes into a single business-operation-level action.[1]

Mistake 5: Keeping every old receipt on the shelf — The Time Machine

Some teams treat every revision of a contract — v1, v2, v3 — as a separate object sitting side by side on the shelf. The official docs call modeling each version of an entity as a separate object the Time Machine anti-pattern.[1]

The fix is keeping the contract as a single object, while managing history through a linked history Object Type or time-series attributes.[1] Treat each version as a new entity, and answering "what's the currently valid contract?" means hunting for the latest version every single time.

Mistake 6: Labeling the shelf just "Stuff" — The Misnomer

Label a warehouse shelf "Item," "Thing," or "Type," and nobody will know what's on it later. In ontology terms, this is using vague names like Item, value, type, or date.[1] The official docs recommend specific, human-readable names like Product, monetaryValue, or orderPlacedDate instead.[1]

So how do you actually organize the warehouse — 4 design principles

The official documentation lays out design principles in priority order to avoid the mistakes above.[2]

1. Model reality, not the source data. Instead of copying a CSV row as-is (an "OrderData" object mixing customer name, email, and product SKU together), separate order, customer, and product into distinct entities.[2]
2. Refactor on the third repetition. The same structure appearing twice might be coincidence — by the third time, it's a pattern. Consolidate it or abstract it through an interface immediately.[2]
3. Protect the core, keep it open for extension. Instead of continuously bolting new attributes onto an existing Object Type, extend through a separate linked Object Type or interface. If equipment suddenly needs certification data, don't touch Equipment itself — link a new Equipment Certification object instead.[2]
4. Favor composition over deep inheritance. When something has multiple natures at once (a building that's also a schedulable resource, for instance), don't build a deep inheritance chain — combine multiple interfaces like Building and SchedulableResource instead.[2]

The official docs are explicit that these are guidelines, not absolute law.[2] Under deadline pressure, implementing a reasonable interim solution with a documented improvement plan is fine — but naming, semantic clarity, and security are the things not worth compromising on.[2]

FAQ

Q. Do I need to fix all of these anti-patterns right now? No. The official docs acknowledge real tradeoffs. Compromising on some points for performance or deadlines is fine, but naming conventions and semantic clarity are much harder to fix later, so it's worth getting those right early.

Q. How do I know if I have a God Object? Ask yourself: "does this Object Type represent two or more genuinely different things in the real world?" If you're calling both equipment and software licenses "Asset," you already have a God Object.

Q. How do I tell Kitchen Sink metadata from metadata I actually need? The test is whether you can explain the attribute's meaning to a business user. "When this record was batch-processed" means something to an engineer, but nothing to the person actually using the data.

References

[1] Palantir, Ontology design: Anti-patterns, Foundry official documentation.

[2] Palantir, Ontology design: Best practices, Foundry official documentation.

Keep reading

• Customer and Client Living in the Same Ontology — What Happens When Naming Breaks Down
• I Tore Apart Ontology's 7 Components Using a Single Piece of Equipment
• You Know the Ontology Theory, But What Do You Actually Click — A Practical Guide to Ontology Manager

This article first appeared on AI Map Ontology, where I write practical guides on Palantir Foundry, ontology-driven architecture, and enterprise AI.

You run a pivot table and the numbers look wrong — the problem is usually somewhere upstream, not in the last step

If you're used to Excel pivot tables, Contour feels familiar at first

"Isn't this just an Excel pivot?" is a common first reaction to Foundry's Contour. On the surface, it looks similar — drag in data, pick rows and columns, choose an aggregation, get a table.

Used it for a while and there's a real difference. An Excel pivot table shows you one final result. How it got there, what got filtered out along the way, stays hidden. Contour doesn't work that way — every filter, every join, every aggregation becomes its own standalone step called a Board.[1] Think of a conveyor belt: raw material (your source data) moves down the line through a series of stations (boards), changing shape at each one, and you can stop at any station to check what the product looks like right now.

25 boards, sorted into four groups

The official Contour docs define 25 board types.[1] You don't need to memorize all of them — grouped by role, they break down like this.

On the conveyor belt, you'd pass through "filter & clean" stations first, merge with other material at a "combine" station if needed, then shape the final output at an "aggregate & visualize" station. You can slot a "verify" board in after any of them.

When the numbers look wrong, don't start by suspecting the last board

When a pivot result looks off, the instinct is to stare at the last board (the Pivot Table). The official guidance actually points the other way.[2]

• Drop a Table board in between steps. Check whether a new column computed correctly, or whether the previous board did what you intended.
• Switch to the table panel. Click "Show table" to see the actual data as you apply each board — especially useful while writing Expressions.
• Add a Histogram board. A quick look at how values distribute across categories tells you fast whether your filtering actually did what you meant.

In other words: put an inspector at every intermediate station on the belt, not just the end. If you only look at the final output and call it "wrong," finding where on the belt it actually went wrong takes much longer.

Pivot tables sometimes only show you part of the picture

Here's something that surprises a lot of practitioners. Per the official FAQ, pivot table previews cap out at the first 100 columns or 10,000 values to protect performance.[3] The aggregation itself runs over the full dataset — what's capped is just what's displayed. To see the complete result, you switch to the "Switch to pivoted data" option to move to the fully-computed pivot.[3] Worth knowing on top of that: exporting directly from Contour hits a 100,000-row limit[3] — for anything larger, save the result as a Dataset instead of using Export.

What real users are actually frustrated by

Palantir's developer community has a thread that goes right at the pivot table board's limitations. One user put it plainly:

"The pivot widget today is very limited in its capability — sometimes it is more pain than the value it delivers."[4]

The specific complaints:[4]

• No support for calculated fields
• Can't filter or sort within the result itself
• Reusing a value is so awkward you often have to inspect the browser console to copy it
• No row-level conditional formatting

A Workshop team developer responded in the thread with plans for "more pivot table investment in T3 and 2025."[4] So this isn't a case of users missing something — it's a real, acknowledged gap. If you need a calculated field today, the practical workaround is building the calculated column with an Expression board before the Pivot Table board, not inside it.

A practical order to work through it

1. Decide what question you're answering before you start. "Compare this metric by region" and "trace why this number looks wrong" call for different first boards.
2. Stack filter/clean boards first. Narrow to what you need with Filter and Expression before you aggregate. Doing it in the other order makes it easy to forget a condition you meant to apply.
3. Bracket aggregation boards with Table or Histogram checks. This matters especially for boards like Pivot Table where the preview only shows part of the result — confirming the data going in is correct saves time tracing problems later.
4. Build calculated fields with Expression before the pivot board, not after. Knowing upfront that the pivot board itself has no calculated-field feature saves you from redesigning midway through.
5. If the result exceeds 100K rows or needs to be reused, save it as a Dataset instead of exporting. Most people discover the export limit only after hitting it.

Where this leaves things

The real difference between Contour and an Excel pivot table isn't the feature list — it's the structure. Excel shows you one result; Contour stacks the path to that result as boards you can pause at, one at a time. The pivot table board's functional limits (no calculated fields, partial previews) are real constraints, not user error — knowing them upfront and routing around them with an Expression board is the path of least friction in practice.

FAQ

Q. Do I need to know SQL to use Contour? No. Most analysis is doable point-and-click by stacking boards. Complex calculations do require learning Contour's own expression language.

Q. My pivot result looks wrong — what should I check first? Start with the filter and join boards before the pivot, using Table boards to verify each — not the final pivot board itself. The root cause is usually upstream of the aggregation.

Q. Is there really no way to add a calculated field? Not inside the Pivot Table board itself. Building the calculated column with an Expression board before stacking the pivot board gets you effectively the same result.

Q. Contour is slow on large data — what helps? The official FAQ recommends using well-partitioned datasets instead of raw CSVs and materializing intermediate results as datasets so your analysis path doesn't get too long.[3]

References

[1] Palantir, Contour • Boards • Board descriptions, Foundry official documentation.

[2] Palantir, Contour • Boards • Verify results, Foundry official documentation.

[3] Palantir, Contour • FAQ, Foundry official documentation.

[4] Palantir Developer Community, Pivot Widget: Rework to make it excel equivalent — real user forum thread with an official Palantir response.

Keep reading

• Object Explorer vs Quiver vs Contour: Choosing the Right Tool
• I Tracked a Churn-Risk Customer Without Writing a Line of Code — A Practical Guide to Palantir Insight

This article first appeared on AI Map Ontology, where I write practical guides on Palantir Foundry, ontology-driven architecture, and enterprise AI.

A blueprint is not the same thing as the building it describes

Ontology vs. Knowledge Graph — What's the Actual Difference?

We get this question a lot. Both terms involve "understanding data through relationships," so they can sound like two names for the same thing. The short answer:

Ontology (the blueprint) + real data = Knowledge Graph (the finished building)

An ontology defines what kinds of things exist and how they're allowed to relate — "Book → has author → Author." A knowledge graph fills that structure with real data to create a web of concrete facts — "To Kill a Mockingbird → has author → Harper Lee."[1] You can build a knowledge graph without an ontology, but the ontology is what keeps new data connecting consistently as it comes in.

So why did Palantir dust off an old philosophy term for this?

Here's where it gets more confusing. The "ontology" this blog keeps writing about — Palantir's — isn't quite the same as the academic ontology just described either.

The traditional Semantic Web ontology is defined with standards like RDF and OWL, and it's read-oriented: query → reasoning → result, then it's done.[2] That's like looking at a blueprint and asking "what's on the third floor?"

Palantir's ontology goes a step further. On top of the Semantic layer, it adds a Kinetic (execution) layer — so instead of stopping at lookup, it executes real business Actions and feeds the outcome back into learning, in a loop.[2] Keep the building metaphor going: this isn't just reading the blueprint, it's wiring sensors into the building that adjust the temperature in real time, and the system learns whether that adjustment worked.

Laid out side by side

These three aren't competitors — they overlap. Palantir's ontology has, internally, the same web of Objects (instances) and Links (relationships) a knowledge graph has; it just has an Action layer for execution sitting on top of that.

It clicks faster next to RDB

We've already compared this to relational databases in RDB Joins vs. Ontology Traversal, using a corporate-card credit limit lookup as the example. That same logic extends cleanly to knowledge graphs.

• RDB: recalculates relationships via JOIN every time. Works without a blueprint, but you re-solve the same question from scratch every run.
• Knowledge graph: relationships are pre-stored as a graph. Finding "who's connected to whom" is much faster.
• Ontology (the blueprint): defines why those relationships exist in the first place and which kinds of things can connect, so the knowledge graph grows consistently.
• Palantir ontology: adds "so what do we do about it right now" on top of all that.

Stack them like steps: storage (RDB) → a web of relationships (knowledge graph) → the design rules for that web (ontology) → execution on top of that web (Palantir's ontology).

Where people trip up in practice

"We already have a knowledge graph, so we don't need an ontology" is a common misconception. A knowledge graph without an ontology (design rules) means the same concept gets a different name every time your data grows — exactly the problem covered in our ontology naming strategy piece.

"We built the ontology, so the knowledge graph comes automatically" is also wrong. A blueprint with no data in it can't answer anything. The ontology is the frame; the knowledge graph is the work of actually filling that frame with data.

Treating "Palantir's ontology" as identical to the academic term will get you into trouble with AIP. When Palantir's docs use the word "reasoning," it's often used in a broader sense than pure logical inference — it usually includes data-driven judgment and Action execution too.

Where this leaves things

An ontology is the blueprint; a knowledge graph is the building built from it. Palantir's ontology goes one step further, wiring that building with sensors so it executes and learns. This isn't a question of which one is "better" — it depends on whether the problem in front of you is "defining what exists," "finding what's connected," or "deciding what to do about it right now."

FAQ

Q. Can I have an ontology without a knowledge graph? Technically yes, but it's not very useful on its own. The ontology only defines rules — the actual data you query or analyze lives in the knowledge graph (the instances). Rules with no data behind them aren't actionable.

Q. Is a graph database like Neo4j an ontology? No. A graph database is the storage technology (the container) a knowledge graph lives in; the ontology is the set of meaning-rules for the data inside it. You can use a graph DB without an ontology, but then you're just accumulating data without rules.

Q. Can I build an "executing ontology" without Palantir? Not exclusively — you can bolt a separate workflow-automation or action-execution layer onto an ontology/knowledge graph yourself and get something similar. What's different about Palantir is that it ships all three layers — meaning, execution, and learning — built into one platform by default.

References

[1] Enterprise Knowledge, What's the Difference Between an Ontology and a Knowledge Graph?

[2] Pebblous, What Is Palantir Ontology? — 5 Key Differences from Classic Ontology

Keep reading

• RDB Joins vs. Ontology Traversal: The Same Question, Two Data Approaches
• What Is Palantir Ontology? A Practitioner's Explanation

This article first appeared on AI Map Ontology, where I write practical guides on Palantir Foundry, ontology-driven architecture, and enterprise AI.

A business user drags and drops the pipeline together on screen, and IT just snaps in one piece of code — a nice picture, but you still need to check where that nice picture stops holding up

Somewhere between IKEA and a woodshop

There are two ways to build a data pipeline in Foundry: click-and-assemble Pipeline Builder, and hand-written Python/SQL in Code Repositories. Think of it as the difference between IKEA furniture and a local woodshop. IKEA gives you fixed parts and an instruction sheet — anyone can assemble it fast, but you can't make a shape that isn't in the parts list. A woodshop will carve whatever you want, but it takes longer and isn't something just anyone can do.

Palantir's own docs describe the two as "complementary, and built to work together to provide solutions for all pipelining needs."[1] True enough. But the question that actually comes up in practice is more specific: "I want business users to keep building this pipeline themselves. But one particular stage needs iterative computation, or has to call an external API, or the data shape changes every run — do I move the whole thing to code, or can I just carve out that one piece?" This piece works out where that line actually sits, using the official docs, real threads from Palantir's own developer community forum, and real user reviews.

What Pipeline Builder is actually good at

Pipeline Builder's stated goal is "building production-grade data pipelines without using code."[2] Its biggest strength is collaboration — in the docs' own words, "users who code and users who do not code can collaborate jointly on a pipeline workflow."[2]

The interface is graph- and form-based, giving real-time feedback (suggesting join keys, column type casts) as you work. Under the hood it runs on both Spark and Flink, so it handles batch and streaming alike.[2] Operations split into "expressions" (one column in, one column out) and "transforms" (whole table in, whole table out) — everything from basic filters, joins, pivots, and aggregations to geospatial joins, k-means clustering, and regex parsing, with over 500 built-in functions.[3] The IKEA catalog, in other words, is a thick one.

But it looks different from the builder's chair

It's convenient for the person using the furniture (the business user), but not necessarily for the person assembling it (the developer). On the review site PeerSpot, one principal consultant put it this way: "low-code tools are great for fast development, but highly customized workflows sometimes still require engineering workarounds or deeper technical implementation."[4] Another reviewer noted: "if I get stuck with the drag-and-drop nature of Pipeline Builder, it is going to be more difficult to migrate that to a different platform."[4]

Palantir's own developer community forum echoes the same thing. One user, discussing ontology design, wrote:

"In our organization, we prefer using the pipeline builder over the code builder despite its limitations (e.g., lack of IDE tooling for refactoring, difficulty in copying and adapting code, and easier transform creation in code)."[5]

That's exactly the tension. Collaboration with business users gets easier, while the actual builder's own tools — refactoring, code reuse — get more constrained.

Four moments where you need the woodshop

Pulling together the official docs and real community forum threads, the places where the IKEA parts genuinely run out narrow down to four.

These four categories are what you get whether you dissect the single official doc ("Considerations: Pipeline Builder and Code Repositories") or run an independent web survey through Gemini — both converge on almost the same four items. When the vendor's own framing and an independently-run survey land on the same conclusion, that's a stronger signal than either alone.

One thing worth being precise about: "can't build loops" isn't unique to Pipeline Builder. A Code Repositories branch fails the same build check if it introduces a circular dependency.[6] That's because Foundry's dataset build system is one-directional at the platform level, full stop. What you can do is write a while loop or a recursive function inside a single Python transform — Pipeline Builder's declarative graph simply has no syntax to express that kind of procedural repetition at all. That's the real difference.

Palantir's own comparison table

Here's the official feature comparison table, as Palantir publishes it.[1]

Palantir's official recommendation: "build your pipeline design in Pipeline Builder," and only "in cases where users require specialized code-based logic not available in Pipeline Builder" should Code Repositories be used to build that one stage.[1] The examples the docs give for "specialized logic" line up almost exactly with the four categories above — API calls, custom libraries, code-based logical concepts.[1]

The important part is that the two are fully interoperable. A dataset built in Code Repositories can be used directly as input to a Pipeline Builder pipeline, and vice versa — meaning you can slot a single code-built stage anywhere in the pipeline: front, middle, or end.[1] Schedules and health checks are managed as one unit across the whole pipeline in Data Lineage, regardless of which tool built which stage.[1] It's the same as snapping a custom-carved drawer, made at the woodshop, into a piece of IKEA furniture — the furniture is still one piece of furniture.

A practical order to work through it

1. Start in Pipeline Builder, full stop. For standard ETL — filtering, joining, aggregating, type casting, regex cleanup — Pipeline Builder is the default. There's no reason to give up collaboration speed and type safety before you've hit a real wall.
2. Only drop to code when you hit one of the four. Does it need iteration, a schema that shifts at runtime, deeply nested data, or an external API? If none of those apply, there's no reason to write code.
3. Carve out just that piece — don't rebuild the whole pipeline. Rather than migrating the entire pipeline to code, build the problem stage alone in Code Repositories and slot it into the existing Pipeline Builder pipeline. That's the officially recommended pattern, not a compromise.
4. If the graph gets huge (roughly 100+ nodes), reconsider the structure. This isn't a number from a specific official source, but it tracks with the PeerSpot observation that "highly customized workflows sometimes still require engineering workarounds." Pipeline Builder isn't broken at that point — it's that readability and debuggability degrade past a certain size, and that's when splitting into modules or moving part of it to code pays off.

Where this leaves things

Pipeline Builder and Code Repositories aren't competitors — they split the work. If business users and developers need to work on the same screen, Pipeline Builder is the default, and the friction developers feel there (no IDE tooling, hard to reuse code) is a real, existing tradeoff. But "it can't do loops" isn't a reason to move an entire pipeline to code. Carving out just the stage that hits one of the four limits — iteration, dynamic schema, nested data, external APIs — is both the officially recommended approach and, in practice, the one with the least friction.

FAQ

Q. Is there any way to fake a loop inside Pipeline Builder? Window and aggregation functions like "Aggregate over window" or "Rollup" can substitute for some repetitive patterns — running totals, ranking, and similar.[3] But real recursion or looping that has to keep recalculating based on a condition simply isn't in the declarative graph's vocabulary — that has to move to Code Repositories.

Q. If I slot in one Code Repositories stage in the middle, does schedule/health-check management get more complicated? No. Per the official docs, regardless of which tool built which part, the whole pipeline can be scheduled and health-checked as one unit through Data Lineage.[1] Mixed tooling doesn't mean split management.

Q. How do I know if my data actually has a dynamic schema? If your column structure varies by source system, or the output columns need to change based on the data content at runtime, that's dynamic. If the source is fixed and you can define the column list ahead of time, Pipeline Builder is enough.

Q. Is the "100 nodes" threshold an official Palantir guideline? No. It's a practical rule of thumb that came out of a Gemini web survey run while researching this piece, not a number written anywhere in Palantir's documentation. The real threshold depends on pipeline complexity and team experience — treat it as a reference point, not a rule.

References

[1] Palantir, Building pipelines • Considerations: Pipeline Builder and Code Repositories, Foundry official documentation.

[2] Palantir, Pipeline Builder • Overview, Foundry official documentation.

[3] Palantir, Pipeline Builder • Transforms • Overview, Foundry official documentation.

[4] PeerSpot, Palantir Foundry Reviews — real user reviews (principal consultant, data engineer, and others).

[5] Palantir Developer Community, Creating link types between Pipeline Builder owned object types and object types not owned by Pipeline Builder, community.palantir.com — real forum post.

[6] Palantir, Building pipelines • Best practices • Development best practices, Foundry official documentation — on circular dependencies and loop prevention.

[7] Palantir Developer Community, Dealing with dynamic schema's in pipeline builder, community.palantir.com — official Palantir team response.

[8] Palantir Developer Community, Nested array problem, community.palantir.com — real user bug report.

[9] Palantir Developer Community, What's the best way to do geocoding in Foundry?, community.palantir.com — real user question and answer.

Keep reading

• Foundry Data Pipelines: Pipeline Builder vs. Code Repository
• Palantir Gave the FDE Role to an AI Too — The Complete Guide to AIP's 'AI FDE'
• Palantir Foundry Architecture Overview: From Connect to AI in Five Layers

This article first appeared on AI Map Ontology, where I write practical guides on Palantir Foundry, ontology-driven architecture, and enterprise AI.

Moving beyond productivity gains to customer value — the semantic layer and Ontology

What This Article Argues

Organizations are already deploying AI to draft documents, search for information, write code, and handle customer inquiries faster. Real productivity gains from this are already being documented.

But processing work faster doesn't, by itself, create new value for customers.

Customers feel the difference when AI finds meaning inside company data and turns that meaning into the next action.

• Instead of just answering fast after a problem occurs, AI catches it before it happens.
• Instead of sending every customer the same message, AI offers the help each one actually needs right now.
• Instead of stopping at a status report, AI tells you what to do next.
• Instead of relying only on a staff member's experience, AI drives consistent, data-backed action.

Here's the flow in one line:

Adopt AI → Improve productivity → Understand the meaning of data → Make better decisions → Take real action → Value customers actually feel

The hardest part here isn't getting AI to produce an answer. It's understanding precisely what your data means, and using that meaning to choose an action that isn't wrong.

That's why DB metadata, data dictionaries, semantic layers, and Ontology matter. These aren't just data-cleanup chores — they're the foundation that turns an AI's answer into customer value.

Below is a short summary of the whole argument, followed by a detailed walkthrough of why the meaning of data matters and how to build toward it.

Summary First

Where We're Headed

Five Key Points

1. AI's productivity effect is already visible. There are documented cases of AI cutting processing time and raising output in writing, development, and customer support.

2. But productivity gains alone don't add up to customer value. The value customers feel is created when AI finds meaning in data and turns it into better judgment and real action.

3. The starting point is DB metadata and a data dictionary. AI can only read your company's data properly once the meaning of tables, columns, codes, units, and dates is spelled out precisely.

4. Reaching customer value requires a semantic layer and Ontology. A semantic layer manages official metrics and calculation logic in one place; Ontology connects business concepts and relationships across systems. Together they keep AI from having to keep guessing when a DB description alone isn't enough.

5. The closer AI gets to driving customer-facing action, the more validation and control matter. Use approved data and rules, keep evidence for every result, and start with human approval before automating only the workflows you've verified.

The One-Sentence Conclusion

Establish DB metadata and a data dictionary as the baseline, then build a semantic layer and Ontology on top of it to turn the meaning of your data into accurate judgment and execution.

The Detailed Case

AI's First Win Showed Up as "Speed"

Generative AI has already shown clear potential in repetitive knowledge work.

A study of roughly 5,000 customer support agents found that agents using an AI assistant resolved about 14% more customer issues per hour.[1] In a controlled experiment with 95 developers, GitHub found that the group using Copilot completed a given development task 55% faster on average.[2]

These numbers don't transfer identically to every company and every task — the effect varies by task type and user experience. But the direction is already clear: AI is useful for speeding up work like this:

• Drafting and summarizing documents
• Searching for and organizing information
• Writing code and automating repetitive tasks
• Suggesting support replies
• Writing meeting notes and reports

The value at this stage is mainly doing the same work faster. It cuts internal hours and cost, and frees staff to focus more on judgment and problem-solving.

That's a real win. But from a customer's point of view, it may not be enough on its own. What matters to a customer isn't that the company can write a report faster — it's whether their own problem gets solved faster, whether they get a more relevant suggestion, and whether an inconvenience or risk gets resolved before it becomes one.

Customer Value Is Created When Data Turns Into Action

For AI to actually help a customer, it has to go beyond answering a question.

Say an analysis flags a customer as high-risk for churn.

Showing that result on a dashboard changes nothing for the customer by itself. Value only appears once the process continues:

1. Identify which customer has the problem.
2. Understand why the problem occurred.
3. Choose the right action for that customer.
4. Notify the responsible person, or have the system execute the action.
5. Confirm the problem was actually resolved.

Customer value shows up only when the chain runs all the way through.

• Catching a likely shipping delay early and notifying the customer
• Spotting a recurring failure signal and acting before service goes down
• Recommending the next feature or product that fits how the customer is actually using the service
• Detecting a churn signal in a contract and providing the right support
• Anticipating a stock shortage and adjusting inventory before an order fails

In other words, the next step in using AI isn't generating more answers — it's finding meaning in the data and connecting that meaning to judgment and execution.

But the "Meaning" of Data Is Hard to Read From the DB Alone

Suppose a user asks:

"Find customers whose service usage has dropped recently and who are at risk of churning."

To answer this, AI needs to know:

• Does "customer" mean a signed-up account, or a paying contract customer?
• Does "usage drop" mean logins, feature usage, or transaction volume?
• Compared to what period, and by how much, does a drop count as risk?
• How should a temporary usage dip caused by an outage or holiday be handled?
• When multiple accounts belong to one client company, how should they be grouped?
• How should already-cancelled customers or test accounts be excluded?

AI can't reliably infer these rules just from table and column names in the database. Without that information, it will construct the most plausible-sounding rule it can.

If a wrong analysis only ends up in a report, a person has a chance to catch and correct it. But once the analysis result feeds directly into a customer notification, a pricing offer, a sales outreach, or a service restriction, the impact of a wrong interpretation of meaning gets much bigger.

The closer AI gets to taking action, the more the accuracy and validation of data meaning matters.

The First Thing You Can Do: Give Your Database a Good Manual

The most realistic starting point is building solid DB metadata and a proper data dictionary.

Metadata is, simply put, information about your data. A data dictionary is a reference that documents what tables, columns, codes, and business terms mean.

For example, it manages things like:

• What each table and column means
• Which data source is the official, authoritative one
• The reference point for dates and the unit for amounts
• What each status code means
• When data was last updated, and who owns it
• Which data should or shouldn't be used together

When this documentation is solid, AI can find and understand your data far more accurately.

If your data structure is simple and doesn't involve many calculation rules, a well-maintained metadata layer and dictionary alone can already get you meaningful results. You don't need to build a large Ontology from day one.

Reaching Customer Value Requires a Semantic Layer and Ontology

Even when every column's meaning is documented in a data dictionary, AI still has to make judgment calls on its own.

For example, to find "customers at risk of churning," AI may have to decide, on its own:

• Which customer table to use
• Which data to use to calculate usage
• How to reconcile customer IDs across multiple systems
• What time window and threshold define churn risk
• Which customers and exceptions to exclude

If you leave this judgment to AI every single time, you can get a different answer to the same question on different days.

A semantic layer turns your most-used metrics and calculations into official, fixed rules.

• Official metric: usage decline rate over the last 30 days
• Population: valid, paying contract customers
• Comparison: average usage over the prior 30 days
• Exclusions: test accounts, service outage periods
• Customer join key: contract customer ID
• Risk threshold: usage down 40% or more

This lets AI use an approved metric instead of inventing a new churn definition every time.

Ontology organizes the business concepts and relationships scattered across multiple systems — customers, accounts, contracts, services, usage activity. For example, it makes relationships like "one client company can have multiple accounts," "an account belongs to one contract," and "usage activity is tied to a specific service" understandable to a machine.

DB Documentation Is the Starting Point; the Semantic Layer and Ontology Are the Next Step

You don't have to pick one or the other.

DB metadata and a dictionary are the baseline. To understand customers well enough to drive action, you need a semantic layer and Ontology built on top of that baseline.

The two layers do genuinely different jobs. The semantic layer owns "which number gets calculated with which formula and which data." Ontology owns "how customers, accounts, contracts, services, and activity relate to each other." One creates consistency in calculation; the other connects meaning across your data.

So the target structure this article proposes is:

1. Use DB metadata and a dictionary to document the basic meaning of your data.
2. Use a semantic layer to manage official metrics, formulas, and correct data joins.
3. Use Ontology to connect business concepts and relationships across systems.
4. Use validation and access control to make sure these rules actually hold in real execution.

If your data is simple, building a large Ontology first just adds management overhead. On the flip side, if you're trying to connect data across systems to actually change customer behavior but only provide column-level documentation, AI will keep having to guess at the calculations and relationships that matter most.

The Safeguards You Need as You Move From Answering to Acting

Adopting Ontology or a semantic layer doesn't make things automatically safe. The rules you define have to actually be wired into the real execution path.

Check before executing

• Did it use approved data and official metrics?
• Did it join the data the correct way?
• Were the customer, time window, and exclusion conditions applied correctly?
• Were privacy and access permissions respected?
• Is there an unusually large query or a dangerous command in here?

Keep the result and its evidence together

• What data was used?
• Which formula and criteria were applied?
• How did AI interpret the question?
• What parts of the result are uncertain?
• What action was actually taken?

Automate high-stakes execution in stages

Start by having AI recommend an action and a person approve it. Expand the scope of automatic execution only for repeated workflows where accuracy and impact have been thoroughly verified. Keep stronger validation and approval steps around decisions involving pricing, contracts, service restrictions, or sensitive information.

What the Evidence Outside Our Company Shows

There's evidence that providing business meaning and data relationships can improve the accuracy of data queries.

• Snowflake reported plain Claude 3.5 Sonnet averaging 57% across four datasets, versus Cortex Analyst — which includes a semantic model — averaging 78%.[3]
• A 2026 arXiv preprint reported that adding business-semantics documentation improved accuracy by 17–23 percentage points across three models, on 100 questions over a single retail dataset.[4]
• On Spider 2.0, which covers realistic enterprise data work, an o1-preview-based coding agent's success rate topped out at 21.3%.[5]

These numbers come from different datasets and evaluation conditions, so they can't be used directly as an accuracy forecast for your own company. But two directions are clear:

1. Even AI that performs well in a clean environment struggles with complex enterprise data.
2. Providing business meaning and official relationships reduces how much AI has to guess.

How to Actually Get Started

1. Pick questions where customer value is high

Choose questions you can turn into real action, not just questions that are easy to answer.

• Who is likely to churn?
• What signals appear before a recurring failure happens?
• Which customers need what kind of support or offer?
• Can we reduce order failures or shipping delays proactively?

2. Document the meaning of the data each question needs

Review the metadata and dictionary for the relevant databases, and fill in the official data source, units, code values, date conventions, ownership, and the correct join method.

3. Build the semantic layer and Ontology

In the semantic layer, define the formulas and exclusion conditions for customer metrics, usage, and risk signals. In Ontology, define the relationships among customers, accounts, contracts, services, and usage activity. Build outward from the business area with the highest customer value rather than trying to cover the entire company at once.

4. Test judgment and execution on a small scope

Prepare 30–50 real business questions with known correct answers and measure accuracy. Start by having AI recommend the next action to a staff member, and automate only the workflows where effectiveness and safety have been confirmed.

5. Measure success by customer outcomes

Don't just track document-writing time or AI usage volume.

• Did customer problem-resolution time go down?
• Did you prevent outages and inconveniences ahead of time?
• Did churn or order failures decrease?
• Did the relevance of recommendations and customer satisfaction improve?
• Did wrong judgment calls and unnecessary outreach decrease?

AI's ultimate performance should be judged by the change it creates for customers — not by how many answers it generated.

Conclusion — Better Action, Not More Answers

Using AI to speed up writing, search, coding, and support is a good starting point, and it delivers real productivity gains. But if you stop there, AI stays a tool that does existing work faster.

The next step is to find the meaning of customers and business inside your company's data precisely, and connect that meaning to better judgment and execution.

A realistic path looks like this:

Establish DB metadata and a dictionary as the baseline. Build a semantic layer on top to unify official metrics and calculations, and build Ontology to connect business concepts and relationships across systems. Then carry that meaning system through to validated execution, so customers experience a real result.

What we should be aiming for isn't an AI that produces more answers. It's an AI that genuinely understands a customer's situation and helps take the right action at the right moment.

References

[1] E. Brynjolfsson, D. Li and L. R. Raymond, Generative AI at Work, NBER Working Paper 31161.

[2] GitHub, Research: quantifying GitHub Copilot's impact on developer productivity and happiness.

[3] Snowflake, Agentic Semantic Model Improvement: Elevating Text-to-SQL Performance, Cortex Analyst official documentation.

[4] M. Rumiantsau and I. Fokeev, Semantic Layers for Reliable LLM-Powered Data Analytics, arXiv preprint, 2026.

[5] Z. Lei et al., Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows, ICLR 2025.

Keep Reading

• Why AI Doesn't Understand Company Data
• Ontology
• Enterprise AI

This article first appeared on AI Map Ontology, where I write practical guides on Palantir Foundry, ontology-driven architecture, and enterprise AI.

The human role Palantir called FDE now shares its name with an agent inside AIP

The name is confusing on purpose

We've already covered what a human FDE (Forward Deployed Engineer) actually does in FDE vs. PI Consultant vs. Solution Architect. Starting in November 2025, Palantir gave the same name to a feature inside AIP. If your org has AIP enabled, you'll see "AI FDE" in the sidebar — and it's not a person, it's a conversational agent.

The name wasn't reused by accident. What a human FDE used to do — listen to requirements in natural language, connect data, build an ontology, wire up a screen — is exactly what this agent is now positioned to do through conversation. This piece covers what it actually does, how it's matured over eight months, what order you actually move through its nine development areas, and how far you should trust it — grounded in official docs, community know-how, real user feedback, and outside critique.

Let's get the name itself right first. The official documentation introduces it this way:[1]

"AI FDE, the AI-powered forward deployed engineer, is an interactive agent that operates Foundry for you through conversational commands."

So "AI" and "FDE" aren't two separate initials bolted together — it's the human role name FDE (Forward Deployed Engineer) with AI-powered in front of it. Spelled out, the accurate reading is "AI-powered Forward Deployed Engineer."

What AI FDE actually does

Per the official docs, AI FDE is "an interactive agent that operates Foundry for you through conversational commands."[1] The core idea is translating natural-language requests into Foundry operations, so you're not manually clicking through the platform for routine work. That covers running data transforms, managing code repositories, building and maintaining an ontology, and looking up documentation.[1]

It works as a closed loop: analyze intent and context → decide on the right operation → execute with native tools → explain the result.[1] Because the model executes an action, observes the outcome, and uses that feedback to decide the next step, it can carry out multi-step workflows. It supports Anthropic, OpenAI, Google, and xAI models, so you can plug in whatever LLM accounts your org already uses.

One design choice worth flagging: it starts with minimal context by default. The official docs frame this as guarding against "context pollution."[1] You expand what it can see by dragging in folders, datasets, or documentation yourself — it isn't handed everything up front. This ties directly into the "give it only the context and tools it needs" best practice covered below.

Eight months, beta to now

Four months from beta to GA is a fast turnaround. Since then, updates have been smaller — mostly navigation convenience and visualization.

What you can actually build — the nine modes

AI FDE isn't one giant do-everything agent. It switches between nine modes depending on the task, and each mode narrows the tools and access scope it activates.[6] Pick the wrong mode, or forget to switch, and you hit the "tools got silently deselected" problem covered further down — for no obvious reason.

Separately from the mode split, AI FDE distinguishes agent-level capabilities (switching modes, asking clarifying questions, drafting a plan for review, loading docs on demand, managing context) from domain-level capabilities (filesystem operations, Notepad document management, Solution Design diagrams, executing actions against ontology objects).[6]

The order you actually move through modes

Going from raw source connection to a finished application, you'll typically move through modes in roughly this order.

Exploration -> Data Connection -> Data Integration -> Ontology Editing -> Functions Editing -> OSDK React (Governance and Approval checks run alongside every step)

Step 1 - Investigate, then connect (Exploration to Data Connection) Start in Exploration mode to look at existing schemas and dataset structure. It's read-only, so you can survey "what's actually here" with zero risk of touching the platform. Once you've oriented yourself, move to Data Connection mode to define connectors for external databases or ERP systems (SAP ECC, etc.) and set Egress network policy.

Step 2 - Build the pipeline and the ontology (Data Integration to Ontology Editing) In Data Integration mode, build cleaning, deduplication, and join logic with Python Transforms or Pipeline Builder. Then switch to Ontology Editing mode to map that dataset onto Objects, Links, and Actions.

Step 3 - Business logic and the app (Functions Editing to OSDK React) Write the rules that run on top of your ontology in TypeScript or Python via Functions Editing mode, then move to OSDK React mode to build the app or widget that actually uses that ontology and those functions.

Run Governance mode alongside every stage rather than saving it for the end - checking permissions and markings as you go catches problems earlier than a single pass at the finish line.

Safeguards and the official best practices

Once an agent is editing your ontology and publishing functions directly, the first question is "what happens when it gets something wrong." The official docs name three safeguards.[1]

• Permission inheritance: every action "follows the user's existing permissions" - AI FDE never operates with broader access than the person using it.
• Tool and context control: you decide what tools it can use and what information it can see.
• Validate before merging: changes go through Foundry's branching first, run through Transform Preview, Function Preview, and CI checks, and only then get merged.

The official best-practices doc adds a few more operating principles:[7]

• Always verify generated resources before production - test transform logic against sample data, review the code
• Only provide the context and tools a task actually needs - unnecessary access hurts both performance and security
• Break complex work into smaller steps; validate the basic structure before adding complexity
• Use AIP Evals to measure function performance over repeated iterations
• Confirm any action that requires tool approval before it runs

Permission inheritance and branch-based validation are sound design choices. But that's the vendor's own description of how it's built to be safe - how much you can actually trust it in a live production environment is a separate question, which we come back to below.

Community know-how: the Operator Framing Convention

A GitHub community library, palantir-ai-fde-library, argues you should treat AI FDE as a "deployment command executor" rather than a chat assistant.[8] Vague requests increase output uncertainty, so pinning down exact parameters - an "operator command" style - produces more deterministic results. The library targets five personas (human FDEs, data engineers, ontology owners, app developers, platform admins) and was published the same day as GA, on March 12, 2026, with prompt templates covering minimum context, required tools, expected behavior, a verification checklist, and known failure modes.

Weak prompt (conversational) "Connect the SAP tables and build me a customer data pipeline."

Better prompt (Operator Framing) Target Component: Data Integration (Python Transform) Source Dataset: /Company/Raw/SAP_KNA1 Primary Key: KUNNR (Deduplication required) Destination: /Company/Cleaned/Customer_Master Expected Output: PySpark transformation script handling null values in 'NAME1'.

This lines up with the official "give it only the context it needs" guidance. Even complex migrations like SAP ECC to S/4HANA are documented as patterns in this library.

What real users have actually run into

The following comes from comments on "Getting Started with AI FDE," a demo (4.5K views) on Ontologize, an official Palantir partner channel, where Gena walks through building a data pipeline.[9] These are the friction points that don't show up in the official docs.

Tools silently deselect on mode switch: Switching to Exploration mode drops Workshop-related tools, so AI FDE says it "can't build this app." Workaround: right after switching modes, open the Tools menu and re-check what you actually need.

Long sessions slow down or stop loading: Sessions that run long eventually take forever to load, or stop loading entirely (users are still asking for a fix). Workaround: don't cram a large task into one session - save intermediate results to Notepad and continue in a fresh session.

Voice input auto-translates: Speaking in French still gets transcribed in English, with no way to turn auto-translation off. Workaround: use text input instead of voice when prompt accuracy in another language matters.

There's positive feedback too. One non-technical user said it let them "build my own app and actually get more done at work," and shared a context-management tip: write a summary to Notepad at the end of a session - which is exactly the workaround for the session-timeout problem above. Another user described hitting a format mismatch while building a clinical-trial visualization; AI FDE identified the problem and offered a fix.

The same channel has follow-up demos - "How an FDE Uses AI FDE to Author Ontology Functions" and "How an FDE Uses AI FDE: Building a Voice-Enabled OSDK Application" - showing Functions Editing and OSDK React mode in actual use.

AI FDE runs consecutive operations far faster than a human would - potentially dozens within minutes. The official best-practices doc warns this speed can expose bottlenecks in storage I/O or GPU capacity.[7] If you're planning high-frequency, parallel operations, check your platform's headroom first.

The skeptical view is worth reading too

A July 2026 Forbes piece rounding up criticism of Palantir's FDE model raises two points - aimed at the FDE model itself, not the AI FDE feature.[10]

Anaplan CEO Charlie Gottdiener argues the FDE approach is "effective for sales tactics or a quick proof-of-concept, but a problem long-term" - embedding engineers this deeply into a customer's operations creates lock-in, where the customer ends up paying indefinitely for maintenance and changes.

Manik Sharma of Kinaxis, a former Palantir executive, raises an execution concern: "putting 25-year-old engineers with the customer" creates problems, because they often lack the domain expertise (in his example, supply chain) needed on-site.

The same article cites a 2025 MIT Media Lab study finding that 95% of generative AI pilot projects fail to deliver real business value.[10] AI FDE has to avoid falling into exactly that trap - pilots that work, production that doesn't.

This critique targets the human FDE model, not AI FDE as a feature. But since AI FDE is explicitly trying to do what human FDEs used to do, through conversation, it's worth asking whether the same structural weaknesses - lock-in, thin domain judgment - carry over to the agent version.

If you're evaluating this

If you're actually considering rolling this out, this is a reasonable order to work through it.

1. Start with Exploration and Platform Q&A. Neither touches your ontology, so the risk is low. Use them to gauge answer quality first.
2. Anything that writes (Data Integration onward) goes through a branch, no exceptions. The official docs recommend it, and it's the minimum safeguard that keeps a mistake reversible.
3. Check the Tools menu right after every mode switch. This is exactly the real-user complaint above - check it before you burn time wondering why something "isn't working."
4. Write requests in Operator Framing style. Naming the target component, source, key, and destination instead of "please build me..." makes results noticeably more consistent, even within the same mode.
5. Don't expect it to replace ontology design decisions. AI FDE executes; it doesn't decide what should be an Object. Without that judgment already in place, it will just build the wrong thing quickly.

Where this leaves things

AI FDE is Palantir's attempt to move the work a human FDE used to do - embedded, customized, batch-style - into an agent organized around nine modes. The design choices (permission inheritance, branch-based validation) are sound, and four months from beta to GA is fast. But since the model this feature is built on - the human FDE role - has drawn real criticism around lock-in and thin domain expertise, the "just talk to it" pitch matters less than how disciplined you are about mode switching, Operator Framing, and the branch/permission safeguards in actual use.

FAQ

Q. Do I need a separate license to use AI FDE? No - it's a feature of AIP, activated by an admin on an AIP-enabled enrollment. It isn't sold separately.

Q. If it edits my ontology and gets something wrong, can I undo it? The official docs recommend making changes on a branch first, then running Transform Preview and CI checks before merging. That said, this is a recommended workflow, not an enforced safeguard - whether it's actually followed is on the operating team.

Q. What do I do when a session's context fills up? Only add the documents, datasets, and functions you actually need. For long-running work, write a summary to Notepad and start a fresh session, loading that Notepad back in as context - which also sidesteps the session-hanging issue users reported above.

Q. Is the Operator Framing Convention an official recommendation? No. It comes from an unofficial GitHub community library. It's worth following anyway because it lines up with the official guidance to provide only the context that's actually needed.

Q. Does the FDE-model criticism in this article apply to the AI FDE feature itself? Not directly. The critique quoted here targets the human FDE model - engineers embedded on-site doing custom work. But because AI FDE is moving that same working style into an agent, it's worth asking the same kind of question - lock-in, thin domain judgment - about the agent version too.

References

[1] Palantir, AI FDE - Overview, https://www.palantir.com/docs/foundry/ai-fde/overview, Foundry official documentation.

[2] Palantir, November 2025 - Announcements, https://www.palantir.com/docs/foundry/announcements/2025-11, Foundry official release notes.

[3] Palantir, March 2026 - Announcements, https://www.palantir.com/docs/foundry/announcements/2026-03, Foundry official release notes.

[4] Palantir, May 2026 - Announcements, https://www.palantir.com/docs/foundry/announcements/2026-05, Foundry official release notes.

[5] Palantir, July 2026 - Announcements, https://www.palantir.com/docs/foundry/announcements/2026-07, Foundry official release notes.

[6] Palantir, AI FDE - Modes and skills, https://www.palantir.com/docs/foundry/ai-fde/modes-and-skills, Foundry official documentation.

[7] Palantir, AI FDE - Best practices, https://www.palantir.com/docs/foundry/ai-fde/best-practices, Foundry official documentation.

[8] GitHub, palantir-ai-fde-library, https://github.com/s-andthat/palantir-ai-fde-library - community prompt library documenting the Operator Framing Convention.

[9] Ontologize, Getting Started with AI FDE, https://www.youtube.com/watch?v=Ta19YD794RY, YouTube - data pipeline build demo and real-user comments.

[10] Steve Banker, Palantir And Forward Deployed Engineering: What Should We Believe, https://www.forbes.com/sites/stevebanker/2026/07/10/palantir-and-forward-deployed-engineering-what-should-we-believe/, Forbes, 2026-07-10.

Keep reading

• FDE vs. PI Consultant vs. Solution Architect: The Real Difference - https://ontologyaimap.com/en/fde-vs-pi-consultant-vs-solution-architect-roles/
• Designing AI Agents and Workflows in AIP: FDE and Logic - https://ontologyaimap.com/en/designing-ai-agent-workflows-in-aip/
• Palantir Is Expensive. Here's Why We Use It Anyway - https://ontologyaimap.com/en/why-use-palantir/

This article first appeared on AI Map Ontology (https://ontologyaimap.com/en/), where I write practical guides on Palantir Foundry, ontology-driven architecture, and enterprise AI.