Already on Palantir? What Data Workers Adds Beneath Foundry, AIP and the Ontology
Palantir runs the business on the Ontology. Data Workers runs the Snowflake, Databricks, dbt and Airflow estate underneath it, at a fraction of the cost. Here is how they fit.
Most Palantir customers don't run their data platform in Foundry. They run it in Snowflake, Databricks or BigQuery, transform it with dbt, schedule it with Airflow, and point Foundry at the result through virtual tables. The Ontology sits on top and runs the business. Someone still has to run everything underneath it, and today that someone is a data engineering team working tickets by hand.
That's the job Data Workers does. Palantir runs the business on the Ontology. Data Workers runs the data platform underneath it, so the tables the Ontology reads stay correct, cheap and governed.
This guide covers what Palantir provides as of September 2026, where it stops, and what each of the four Data Workers products adds when you run it beneath Foundry. If you're weighing the Ontology itself against an open alternative, we've covered that separately in Palantir Ontology Open Source Alternative.
Key takeaways
- •Data Workers turns the estate under Foundry into an autonomous data platform. Cost optimization, migrations, incidents, governance and catalog upkeep for Snowflake, Databricks, BigQuery, dbt and Airflow run on their own, at whatever autonomy level you choose per domain.
- •Foundry stays where the business runs. The Ontology, Workshop apps, Actions and AIP are the right place for operational decisions. Data Workers doesn't replace them.
- •Palantir's agents act inside Foundry. AI FDE builds Foundry pipelines, and Ontology Actions change business state. We found no first-party agent that operates your warehouses, dbt models or Airflow DAGs.
- •We read the Ontology directly. Ontology MCP went GA in June 2026, so our agents use your object and action types as context, and AIP agents can call ours.
- •The cost difference is an order of magnitude. Palantir's public UK price list puts pilots at £50k–£500k. Our pilot is $7,500, and paid plans start at $1,000 a month with unlimited seats and no usage meter.
This guide compares what Palantir covers with what Data Workers adds. For the step-by-step path from a traditional data team to an autonomous data platform, read From Palantir to an autonomous data platform. For the leadership view, read Your decisions run on Palantir. Now make your data operations autonomous.
Six things you get beneath Foundry
1. A data platform that runs itself, not just a smarter operational layer. Palantir makes the business layer agentic. Data Workers makes the data layer underneath it autonomous. Governance, compliance, pipelines, catalog upkeep, cost and incidents run on their own across Snowflake, Databricks, BigQuery, dbt and Airflow, and your team moves up an autonomy ladder from observe-only to fully autonomous, one domain at a time.
2. One control plane for every warehouse Foundry reads from. Connect the platforms behind your virtual tables, plus dbt, Airflow and your BI tools. Nothing moves, and nothing is copied into Foundry. You get one context graph, one review inbox and one autonomy policy across all of them.
3. Warehouse spend cut underneath the Ontology. Palantir meters its own compute and AIP tokens. It doesn't optimize the Snowflake, Databricks or BigQuery bills underneath. The Cost Savings & Cleanup agent breaks those bills down by table, query, team and pipeline, finds unused tables, idle compute and duplicate pipelines, and archives only after checking dependencies. Our design target is a 25–40% cut in warehouse spend. That's a target we're engineering toward, not a billed average.
4. Migrations you approve instead of staffing. Moving the warehouse under Foundry, from Teradata or Oracle to Snowflake or Databricks for example, shouldn't mean rebuilding the Ontology. The Data Migration agent translates SQL and procedural logic, re-translates anything that fails validation, proves parity with row counts, checksums, statistical profiles and referential-integrity checks, and cuts over incrementally while the legacy system stays live. Your virtual tables point at verified data on day one of the new platform. Our target is 4–8 weeks for work that usually takes consultants 6–12 months.
5. Incidents fixed where Foundry's data comes from. When an object in a Workshop app goes stale, the cause is almost never in Foundry. It's a failed dbt model, a renamed source column or a stuck Airflow task. The Conductor traces it upstream, has the right agent fix it there, and confirms the virtual table's health check is green again.
6. Governance for the layer Foundry doesn't govern. Foundry's markings and row- and column-level policies are excellent inside Foundry. Access requests, classification and audit evidence for the warehouses themselves still need doing. Our Access, Identity and Security agents handle them through each platform's own permissions, with a receipt on every change.
Behind all six are 20+ specialist agents, one context graph across every platform, and the coding agent your team already uses (Claude Code, Codex or Cursor) as the way in. Spellbook is where you look: every asset, every change and every receipt, with one-click rollback.
One incident, four systems
Here's a scenario most Foundry customers on a modern warehouse will recognize (an illustration, not a customer case):
- •Overnight. An ERP source changes a unit-of-measure field. Fivetran lands it in Snowflake.
- •Early morning. The dbt model
inventory_positionsstill runs, but now mixes units. - •08:00. Foundry reads the model through a virtual table. The Inventory object type in a Workshop app shows supply that doesn't exist.
- •09:00. A planner asks AIP why a plant looks over-stocked, and an Action to reallocate stock is one click away.
| Step | What Palantir-native tooling sees | What Data Workers does |
|---|---|---|
| ERP field change, via Fivetran | Data Connection may pick up the new values. Nothing explains the change. | The Schema Evolution agent flags the semantic change and every downstream consumer, including the Foundry virtual table. |
| dbt model mixes units | Outside Foundry. We found no first-party dbt integration. | The Pipeline agent opens a PR that normalizes units, and the Change Review agent attaches the blast-radius report. |
| Ontology object shows wrong supply | Health checks cover freshness, schema and primary keys, not whether the numbers mean what they should. | The Conductor ties the Ontology symptom to the dbt root cause, and the owning team is told before anyone acts on it. |
| Planner is about to reallocate stock | AIP answers from the Ontology, which is wrong upstream. | The Conductor confirms the model and the virtual table are correct again, closes the receipt, and records the pattern. |
Palantir is where the decision gets made. Data Workers makes sure the data behind the decision is right.
What Palantir covers, as of September 2026
| Area | What Palantir ships | Status (Sept 2026) |
|---|---|---|
| Ontology | Object, link and action types; functions; Ontology SDK in Java, Python and TypeScript | GA |
| External agent access | Ontology MCP: object types, actions and query functions exposed as MCP tools, with controlled writes | GA (June 2026) |
| Builder agent | AI FDE: builds Foundry pipelines, edits the Ontology, writes functions and audits permissions, acting with the user's permissions | GA (March 2026) |
| AI apps | AIP Logic, AIP Chatbot Studio (formerly Agent Studio), AIP Analyst, AIP Automate | GA |
| AI quality | AIP Evals, including Pipeline Builder evaluation suites; AIP Evolve for optimizing AI workflows | GA / Beta |
| Builder MCP | Palantir MCP: IDEs and agents build and edit Foundry apps, types and transforms | GA (June 2026) |
| Warehouse access | Virtual tables and compute pushdown on Snowflake, Databricks and BigQuery | GA |
| Open formats | Iceberg tables with transactions and schema branching | GA (September 2026) |
| Governance | Markings, object and property security policies, branch approvals, decision lineage | GA |
| Partnerships | Databricks (March 2025), Snowflake (October 2025), Google Cloud (June 2026) | Announced |
That's a serious platform, and for operational decision-making on business objects nothing else comes close. Its strengths are the Ontology's write-back through governed Actions, security depth that regulated and defense buyers need, and an unusually complete loop for building and evaluating AI apps, as long as the work lives inside Foundry.
How Data Workers compares
Here's the side-by-side. We scored eight outcomes a data leader actually buys. On three of them Palantir is on home ground: operational apps and AI apps built on the Ontology, where it leads, and governed business context, where we're even because we read the Ontology directly over Ontology MCP. The other five are about the data platform underneath.
| Outcome | Data Workers | Palantir | Why we scored it this way |
|---|---|---|---|
| Operational apps on business objects | 3 | 9 | Foundry is built to change real business state: governed Actions, transactional webhooks, branching and approvals. We don't build operational apps. |
| AI apps built on the Ontology | 4 | 9 | AIP Logic, Chatbot Studio, AI FDE (GA March 2026), Evals and Evolve form a complete build loop inside Foundry. We ship data agents, not an AI app builder. |
| Governed business context for agents | 9 | 9 | Even. The Ontology is excellent context, and Ontology MCP (GA June 2026) lets our agents read object and action types directly. |
| Warehouses, dbt and Airflow run for you | 8 | 2 | AI FDE builds pipelines inside Foundry. We found no first-party dbt or Airflow integration, and no agent that operates your Snowflake, Databricks or BigQuery estate. |
| Incidents fixed where Foundry's data comes from | 8 | 3 | Foundry health checks can flag a stale virtual table. The fix lives in the warehouse or dbt model upstream, where Foundry's agents don't act. |
| Spend cut across every warehouse | 8 | 2 | Palantir meters AIP and Foundry compute and shows usage by project. It doesn't optimize the Snowflake, Databricks or BigQuery bills underneath. |
| Open core, free to leave | 9 | 3 | Our core is Apache 2.0, and paid plans have no notice period or exit fee. We found no standard export format for the semantics, actions and functions you build into Palantir's Ontology. |
| Affordable to start and to scale | 9 | 2 | Our pilot is $7,500 and paid plans start at $1,000 a month with unlimited seats. Palantir's public UK price list shows pilots at £50k–£500k and implementation at £150k per person per quarter. |
The scores measure scope (what each side covers), not answer quality, and they're our directional judgments, not benchmarks. We've shown the reasoning so you can argue with any line.
Palantir's agents stop at the Foundry edge
Every limit below comes from Palantir's own documentation or public filings. None of them is an oversight. Palantir is built to be the operating system for decisions, not the operations team for your warehouse.
1. The agents build and act inside Foundry
AI FDE is impressive. It builds Pipeline Builder and Python pipelines, edits the Ontology and audits permissions. But everything it builds lives in Foundry. Ontology Actions can reach external systems through webhooks, which is how Palantir writes back to an ERP or CRM. That's a hand-built integration per action, not an agent that operates your Snowflake account, your dbt project or your Airflow scheduler. We found no first-party dbt or Airflow integration.
2. Health checks see Foundry's view, not the warehouse's
Foundry can check a virtual table for freshness, schema changes and primary-key violations. That catches some breakages. It doesn't see the dbt model, the Fivetran sync or the Airflow task that produced the table, so it can tell you something is wrong but not fix it where it happened.
3. The Ontology is excellent, and it's Palantir's
Palantir exposes the Ontology through the OSDK, OpenAPI, Ontology MCP and, in beta, Ontology-as-code, and its data can live in Iceberg and Parquet. What we couldn't find is a standard export format for the semantics, actions and functions themselves. If you ever leave, the business logic you've built into the Ontology doesn't come with you in a standard form.
4. It's priced for transformation programs
Palantir's public UK G-Cloud price list shows discovery at £50k–£250k, pilots at £50k–£500k, and implementation at £150k per person per quarter. AIP tokens convert into Foundry compute-seconds. That's appropriate for the operational programs Foundry is built for. It's a heavy way to pay for running the data platform underneath.
The overlap, honestly
| Job to be done | Palantir-native | Data Workers | What we recommend |
|---|---|---|---|
| Operational apps and decisions on business objects | Ontology, Workshop, Actions | Not our job | Palantir |
| AI apps on business objects | AIP Logic, Chatbot Studio, AI FDE | Not our job | Palantir |
| Business context for agents | Ontology | Reads the Ontology over Ontology MCP, alongside warehouse, dbt and BI context | Both |
| Pipelines inside Foundry | Pipeline Builder, AI FDE | Not our job | Palantir |
| Pipelines in dbt and Airflow that feed Foundry | Not covered | Pipeline Building agent, Change Review agent | Data Workers |
| Incidents upstream of virtual tables | Health checks flag some symptoms | Autonomous Data-Conductor, detect → diagnose → fix → review → verify | Data Workers |
| Warehouse cost | Foundry usage by project | Cost Savings & Cleanup agent across every warehouse | Data Workers |
| Warehouse migration | Not covered | Data Migration agent with parity proofs | Data Workers |
| Access and security inside Foundry | Markings, row and column policies | Not our job | Palantir |
| Access and security in the warehouses | Not covered | Access & Governance, Identity and Security agents | Data Workers |
| Catalog of the whole estate | Foundry lineage covers Foundry's view | Spellbook Data Catalog across every platform | Data Workers |
The fastest first win: incidents that reach the Ontology
Start where a bad number costs the most: the tables behind your most-used object types. Data Workers maps every virtual table back to the dbt models, Airflow tasks and sources that feed it, watches them, and fixes breaks before they surface in a Workshop app. Each fix is approved at the level you set and recorded with a receipt. It's the quickest way to show the business that the Ontology can be trusted every morning.
What each Data Workers product adds beneath Foundry
Data Context Wizard: the Ontology plus everything under it
The Ontology describes the business: plants, orders, customers. Data Context Wizard describes the data layer that feeds it: which dbt model builds the table behind the Inventory object, which Snowflake role can read it, what changed last night, and who owns it. It reads your object and action types over Ontology MCP, so the two meet in one graph. Every fact carries its source, author, confidence and observation time, and nothing becomes authoritative without a person's approval.
Spellbook Data Catalog: a control plane for the platform, not the business
Foundry has lineage for what Foundry sees. Spellbook covers the whole estate beneath it, and it's where agent work is proposed, approved, rolled back and audited. A deep-wiki page for the Snowflake table behind a virtual table shows its sources, its dbt model, the Foundry object type that reads it and every change made to it. Spellbook is in preview today.
The Data-Agents Swarm: the team that runs the warehouse
AI FDE is a builder for Foundry. The Data-Agents Swarm is 20+ specialists for the platform underneath: Pipeline Building, Schema Evolution, Change Review, Quality Monitoring, Cost Savings & Cleanup, Data Migration, Access & Governance, Identity and Security among them. They're MCP-native, so Palantir's pro-code agents can call them as tools.
Autonomous Data-Conductor: from a wrong object to a fixed model
The Conductor owns the outcome. It traces a wrong Ontology object to its upstream cause, directs the right agents to fix it, scopes the blast radius, routes it for approval at the level you've set, and confirms the virtual table is right again. Every change leaves a signed receipt and can be reversed in one click.
What it costs
| Palantir (public UK G-Cloud list, 2024) | Data Workers | |
|---|---|---|
| Try it | Discovery £50k–£250k; pilot £50k–£500k | Pilot $7,500, one-time, with a forward-deployed engineer |
| Run it | Organization license from £3M of usage, or per-core pricing | Scale from $1,000 a month; Enterprise from $3,000 a month, billed annually |
| People | Implementation at £150k per person per quarter | Unlimited seats on every plan |
| Usage | AIP tokens and Foundry compute-seconds | No usage meter; no markup on model spend; bring your own model key |
| Leaving | No standard export format for Ontology logic | Apache 2.0 core; no notice period and no exit fee |
These aren't substitutes for each other, so this isn't a like-for-like price comparison. The point is that you don't need a Palantir-sized program to run the data platform under Palantir.
Autonomy guardrails and security
Palantir's governance inside Foundry is among the best in the industry: markings, row- and column-level policies, branch approvals and decision lineage. Data Workers brings the same discipline to the platform underneath:
- •Autonomy is set per domain, from L0 (manual) to L4 (fully autonomous). New deployments start observe-only.
- •Blast radius is scoped across platforms before any write, including the Foundry objects that read the affected tables.
- •Every change gets a signed receipt and one-click reversal.
- •No agent can approve or promote its own work. This is enforced in code.
- •Least privilege. Data Workers acts with the roles you grant it on each platform. It reads Foundry through Ontology MCP under the permissions you configure there.
How it fits together
There's no migration and nothing is copied into Foundry or out of it. You connect Data Workers to the warehouses behind your virtual tables, your dbt project and your orchestrator, and register it as an Ontology MCP client. Every agent starts observe-only. The first things you see are the upstream lineage and incident history for the tables your Ontology depends on.
When Palantir alone is enough
- •Your data platform lives inside Foundry. Pipelines in Pipeline Builder, data in Foundry datasets, with no Snowflake, Databricks or BigQuery underneath.
- •Your need is operational decisions on business objects, and your data engineering load is small.
Data Workers earns its place when Foundry sits on top of a warehouse you still have to run; when dbt, Airflow or source changes are behind the objects that go wrong; when warehouse spend or a migration is on the roadmap; or when you want the data platform to run itself with the same auditability you expect from Foundry.
FAQ
Does Data Workers replace Foundry or the Ontology? No. Foundry stays where the business runs. Data Workers runs the data platform underneath it and reads the Ontology as context.
Can Palantir's agents call Data Workers? Yes. Our agents are MCP-native, so Palantir's pro-code agents can use them as tools. We read the Ontology through Ontology MCP.
Is this an open-source alternative to the Palantir Ontology? Partly. Data Context Wizard is a governed knowledge graph of your data layer, and our core is Apache 2.0. If you're looking to replace the Ontology itself, read Palantir Ontology Open Source Alternative.
What happens if an agent gets something wrong? Every write is scoped before it runs and goes to review at whatever autonomy level you've set for that domain. It leaves a signed receipt and can be reversed in one click. No agent can approve its own work.
What does Data Workers store? Metadata and scrubbed facts about your data (definitions, lineage, owners, incident history), not copies of your tables. PII is scrubbed before anything is stored, tenants are isolated, and Enterprise can run in your own VPC or on-premise.
Sources for Palantir capabilities and pricing: Palantir documentation and monthly announcements current as of September 29, 2026, including Ontology MCP, AI FDE, Palantir MCP, virtual tables, action webhooks, AIP compute usage and interoperability; Palantir's UK G-Cloud 14 pricing document (May 2024); and the Databricks and Snowflake partnership announcements. If we've got something wrong, tell us and we'll fix it.