Palantir is the first vendor in this series that is not an infrastructure vendor at all, and reading its own documentation makes the inversion precise. Dell, HPE, VAST, Cisco, and the clouds build upward from silicon, storage, or a data center; Palantir builds downward from the decision. Its Architecture Center is explicit that the Ontology is designed to represent 'the complex, interconnected decisions of an enterprise, not simply the data.' Where Dell is strongest at Layer 0 and absent at Layer 2C, Palantir is structurally absent at Layer 0 and strongest at Layers 1A (governance), 2B (governed agent runtime), 2C (reasoning/orchestration), and 3 (value). It is the mirror image of every infrastructure vendor assessed so far.
Palantir's data and compute architecture is genuinely open, and that openness is exactly what makes the capture hard to see. The Multimodal Data Plane uses Apache Iceberg as its primary table format, registers Databricks / Snowflake / BigQuery data through Virtual Tables 'without needless data duplication,' pushes compute down to those same engines, stores data at rest in open formats (Iceberg/Parquet) reachable over REST/JDBC/S3, and supports being 'one participant in a wider' data/AI mesh — Palantir's own 'unwalled garden.' Every one of those openness claims is true. But openness at the data and access layers is not portability of the thing the enterprise actually builds. The test that matters is whether a vendor's opinions — its proprietary way of modeling, governing, and orchestrating — can be lifted out and operated elsewhere. Palantir's opinions are the Ontology, and they run only on Palantir.
The boundary, then, is not the data — it is the opinions plus the operating model. Even when data stays in Snowflake and compute pushes down to Databricks, the Ontology (objects, links, actions, and interaction-time security), the agent runtime, and the deployment control plane remain Palantir's, deployed on Palantir's hardened Kubernetes substrate (Rubix) and operated under Palantir's connection. The four-fold integration of data, logic, action, and security is the proprietary IP; the storage underneath is deliberately commoditized and open. The capture is Oracle-shaped: open at the access layer, captive at the layer of accumulated proprietary dependence — and like Oracle, the lift to leave compounds with every use case built, because every object model, action, agent, and workflow is Palantir-specific surface that would have to be rebuilt elsewhere.
Apollo is the most important find for the 4+1 model, and the documentation makes both its power and its limit exact. Apollo is a genuine constraint-solving orchestration engine: a Hub continuously evaluates every possible Plan for each Spoke, evaluates all constraints attached to each Plan (maintenance windows, product-dependency version ranges, suppression windows, artifact availability), and issues only Plans whose constraints are satisfied — across connected, disconnected, and air-gapped estates under FedRAMP High, IL5, and IL6. Its explicit 'propose-a-Plan-then-execute' paradigm, with a dependency-graph invalidation model and break-glass overrides, is the closest thing in the entire series to the multi-variable policy reasoning the working notes describe. The limit: Apollo's constraints govern software deployment and day-2 operations — versions, dependencies, time windows, artifact presence — not live per-inference placement of which model, which region, which cost tier at request time. Palantir has built the control-plane MECHANISM the 4+1 model wants; it is pointed at the platform lifecycle and at agent actions, adjacent to the Infrastructure-2C placement function rather than identical with it.
The DAPM crux cuts as sharply as it favors. Palantir hands the enterprise a real governance surface, a real governed agent runtime, and a real constraint-based control plane — but as a Ceded dependency operated under Palantir's judgment. The platform is not self-deployable; Palantir engineers deploy and manage it, Apollo holds a persistent connection back to Palantir for updates, monitoring, and orchestration, and Forward Deployed Engineering bridges the last mile. This places Palantir in the proprietary-captive cluster with Google, Oracle, and VAST — heavily Ceded — distinguished by a decoupled capture mechanism: where VAST couples (your data must enter its namespace, so the commitment is visible), Palantir decouples (your data stays open, so the commitment is invisible until you try to leave). The inverse-of-Dell shape holds end to end. Dell owns the floor and is Absent at the reasoning plane, so it says 'bring any Layer 2C' — and that 2C arrives Delegated and substitutable, leaving authority distributed. Palantir Cedes the floor and owns the reasoning plane, so it says 'bring any Layer 0' — and everything above the floor consolidates into one Ceded-and-operated authority. Same invitation, opposite consequence: a federated answer to 'who ties the control plane together' versus a unified one. Q1 2026 (revenue +85% YoY, 1,007 commercial customers, US commercial +133%, Rule of 40 at 145%) shows a growing number of enterprises accepting the unified trade.
Layer-by-layer status: Layer 0 (Not Palantir's Layer (By Design)), Layer 1A (Palantir Strength — Governance Authority, Open Storage), Layer 1B (Palantir Strength — Governed Retrieval), Layer 1C (Foundry Pipelines + Open Compute (MMDP)), Layer 2A (Ceded — Platform-Scoped Orchestration), Layer 2B (Palantir Strength — Governed Agent Runtime), Layer 2C (Ceded — Closest Productized Mechanism, Adjacent Target), Layer 3 (+1) (Palantir Strength — Where It Starts, Not Where It Ends).
Assessment framework: 4+1 Layer AI Infrastructure Model. Scoring model: Decision Authority Placement Model (DAPM) — Retained, Delegated, Ceded, or Absent. Published by The CTO Advisor LLC. Author: Keith Townsend. Date assessed: May 23, 2026. Version: v3.0 — Layer-by-Layer Pressure-Tested.
Raw compute, networking, and acceleration fabric
Palantir deploys onto customer or cloud infrastructure (AWS, Azure, GCP, OCI, on-prem, air-gapped). No proprietary Layer 0 assets; Rubix delivers identical operational characteristics regardless of provider.
Turnkey Palantir-on-NVIDIA appliance for sovereignty / latency use cases. Layer 0 authority is entirely NVIDIA's; Palantir contributes the software stack from Rubix upward.
Announced at AIPCon 9 (May 2026): a turnkey system combining NVIDIA Blackwell Ultra hardware with Palantir's full software suite, aimed at data-sovereignty and latency-sensitive deployments. This is the single place Palantir touches Layer 0 — and the silicon, interconnect, and acceleration are entirely NVIDIA's. It is the clearest market signal in the series of the control plane being assembled from both ends: the most application-down vendor (Palantir) paired with the most silicon-up vendor (NVIDIA) in one offering spanning Blackwell Ultra to the Ontology.
Palantir designs no chips, switches, or fabric. By the Rubix documentation it deploys with identical operational characteristics across AWS, Azure, Google Cloud, Oracle Cloud, or on-premises — consuming whatever Layer 0 exists beneath it.
Layer 0 is simply not Palantir's layer, and the documentation treats this as a feature rather than a gap. Rubix (the hardened Kubernetes substrate) is explicitly designed to 'abstract away the peculiarities of different environments and providers,' giving identical operational characteristics on AWS, Azure, GCP, OCI, and on-prem. Palantir's value is structurally indifferent to the silicon underneath. The contrast with the infrastructure vendors is total and clean: Dell's strength is Layer 0 and its gap is Layer 2C; Palantir's gap is Layer 0 and its strength is Layer 2C. The Sovereign AI OS partnership with NVIDIA is the exception that proves the rule — when Palantir needs a Layer 0 story (sovereignty, latency, turnkey on-prem), it borrows NVIDIA's Blackwell Ultra stack wholesale rather than building its own. For the 4+1 model this is significant: because Palantir floats above Layer 0, its governance and reasoning surfaces are the only ones in the series that are not anchored to a particular infrastructure vendor's hardware. That is both the source of its federation claim (it can sit atop Dell, HPE, VAST, or a hyperscaler equally) and the reason its lock-in lives entirely in the upper layers rather than the silicon.
Total at Layer 0, and irrelevant to the value proposition by design. Palantir inherits all silicon, networking, and acceleration judgment from the host environment. The consequence worth tracking: the enterprise's Layer 0 choice (and its Layer 0 DAPM position) is made with a different vendor (Dell, a hyperscaler, or NVIDIA via the Sovereign AI OS), and Palantir simply rides on top — so a Palantir adoption decision does not, by itself, resolve any Layer 0 authority question.
The Sovereign AI OS is the entry worth tracking across the whole series, because it is the first offering that explicitly fuses the top and bottom of the 4+1 stack into one SKU. If the control plane ends up being co-built by an application-down vendor and a silicon-up vendor meeting in the middle (working notes, Pattern 4 and Open Question #2), this partnership is the prototype.
Durable, governed data foundation — the Governance Catalog that Layer 2C queries
Models the enterprise's DECISIONS, not just its data: semantic 'nouns' (objects, properties, links) paired with kinetic 'verbs' (actions, automations) and the logic behind them (business rules, ML models, LLM-driven functions, multi-step orchestrations), all woven through a security layer. A documented 'digital twin' enabling read-write loops between humans and agents.
Reconciles granular role-, marking-, and purpose-based policies at the moment of interaction across data, logic, actions, and LLM calls — down to row/column level. Agents inherit security scopes from a human user or a project's permission structure, so agent governance equals employee governance. Cataloged in expressive audit logging.
Iceberg as primary table format; data at rest in open formats (Iceberg/Parquet, original CSV) over REST/JDBC/S3. Virtual Tables register Databricks/Snowflake/BigQuery data without duplication. The storage layer is deliberately open and commoditized — the 'unwalled garden.'
Metadata services expose mandatory (security/attribution/lineage) and discretionary (tags/enrichments) metadata across datasets, ontology elements, agents, models, and pipelines for connection to existing catalogs/MDM. Ontology elements are REST/JSON-accessible with bidirectional sync to external semantic tools; Palantir MCP enables agent-driven semantic interop.
Turns the Ontology into a programmatically queryable API gateway / operational bus across the enterprise — the queryable, action-bearing control surface the working notes call for, as opposed to a display-only catalog.
Every data query tied to full version history and the transformation logic that produced it; object types, actions, logic, and policy rules are versioned. Global Branching applies software-engineering change management ('version control for reality') to operational data and logic for both humans and agents.
The Ontology, its security system, lineage, and the MMDP open-data architecture are Palantir IP. NVIDIA contributes nothing to the governance layer.
This layer splits cleanly into two findings: storage (open) and governance (Palantir's, and very strong). Storage is deliberately open. The Multimodal Data Plane commits to Apache Iceberg as the primary table format; data at rest is stored in original/open formats (CSV, Iceberg, Parquet) and reachable through REST, JDBC, and S3-compatible interfaces. The Virtual Tables framework registers data from Databricks, Snowflake, and BigQuery 'without needless data duplication,' and Palantir explicitly frames itself as able to be 'one participant in a wider, more heterogenous enterprise architecture' — an 'unwalled garden.' This is a documented openness at the data layer — it engages Pattern 1 (the metadata boundary problem) head-on: Palantir's Interoperability documentation describes metadata services that expose mandatory metadata (security, attribution, lineage) and discretionary metadata (tags, enrichments) across datasets, ontology elements, agents, models, and pipelines for connection to existing catalogs and MDM tools, plus bidirectional semantic synchronization with external semantic models. Governance is where Palantir is genuinely one of the strongest in the series. The Ontology binds data, logic, action, and security into one model, and the security system reconciles role-, marking-, and purpose-based controls 'at the time of interaction, across tens of thousands of humans and agents,' down to row/column-level restrictions. Agents take security scopes that inherit from a human user or a project's permission structure — so an agent is governed exactly like the employee it acts for. This is the 'control surface,' not the 'checkbox,' that Pattern 2 asks for: governance metadata that is programmatically queryable (via the Ontology SDK / OSDK as an 'operational bus'), real-time (evaluated at interaction time), and policy-aware (purpose-based controls). The honest residual boundary: the queryable, action-bearing governance lives in the Ontology, which is Palantir's. You can keep your data in Snowflake; the decision graph that makes it operational — and the authority that governs it — is Palantir's. The five working-notes criteria are largely met (queryable, real-time, policy-aware, observable), and 'cross-platform' is met via virtual tables and metadata/semantic interop rather than only via ingestion.
Low for the governance logic itself — the Ontology Language/Engine/Toolchain, the interaction-time security system, and lineage are Palantir IP. The structural dependency is subtle: data need NOT enter Palantir's storage (open formats, virtual tables, pushdown), but to be GOVERNED and made operational by Palantir, it must be modeled in Palantir's Ontology and mediated by Palantir's security system. The enterprise can retain its storage substrate while ceding the decision-and-governance layer. Compared to Dell's MetadataIQ (indexes Dell storage in place, stays at Layer 1A), Palantir's governance reaches up into Layer 2C — but the authority that does the reaching is Palantir's.
The load-bearing concepts are the 'four-fold integration' (data + logic + action + security) and the Language/Engine/Toolchain decomposition: together they are why this is a governance authority rather than a catalog. The enterprise can keep its data substrate open (virtual tables, pushdown) while the decision graph that makes that data operational remains Palantir's.
Low-latency retrieval for RAG — vector/hybrid search, context windows
Agents retrieve governed objects (with links, logic, and security) rather than raw chunks; context is continuously integrated into the Ontology. Retrieval inherits interaction-time security automatically.
Integrated vectorization to produce/manage embeddings; extensible compute (multi-node Spark/Flink, single-node DuckDB/Polars, or BYO containerized engines); and a tool-services layer that functions as an evolving 'tool factory' for agents. Modular and model-agnostic.
Context-aware assistance across out-of-the-box applications, grounded in the Ontology to shorten time-to-value when exploring governed data.
Vectorization and retrieval are Ontology/AIP-native services on the Rubix compute mesh. GPU acceleration is inherited from the host Layer 0 when present, not architecturally required; embeddings can be produced by any registered model.
Palantir's retrieval story is distinctive and well-documented: rather than RAG-over-raw-text producing 'a slightly better search engine,' agents retrieve and reason over Ontology objects — governed business entities carrying their links, logic, and permissions. The AIP architecture lists 'vector, compute, tool services' as a first-class capability: integrated vectorization to produce and manage embeddings, plus an extensible compute framework. Context is continuously integrated into the Ontology rather than assembled ad hoc at query time, which raises retrieval quality and governance simultaneously — every retrieved object carries its security markings, so retrieval respects the same interaction-time policy as everything else. The trade-off mirrors Layer 1A: retrieval is rich and governed within the Ontology's semantic frame. Compared to VAST's InsightEngine (purpose-built vector retrieval native to the data platform with permission-inheriting vector rows) or Dell's Elastic-based hybrid search, Palantir's retrieval value is semantic and governed rather than infrastructural — it is less a raw vector-DB play and more 'retrieval over a permissioned decision graph.' Because embeddings can be generated by any registered model and data can sit in virtual tables, retrieval does not force a storage migration. The score here is strong on the basis of governed retrieval — permission-aware object retrieval is what Palantir's buyers come for — not on raw vector-search performance or scale, where the purpose-built players lead. VAST and Palantir are both strong at 1B for opposite reasons: VAST on retrieval performance native to the data plane, Palantir on retrieval governance native to the Ontology. Against the working-notes criterion of retrieval-quality observability feeding placement: Palantir partially supplies it because AIP Evals suites are automatically tracked against the functions and sub-agents that consume context, giving a governed record of how retrieval-dependent behavior shifts over time — closer to the 'observable' criterion than most infrastructure vendors, though still oriented to agent quality rather than to a Layer 2C placement engine optimizing recall@k against cost.
Low. Retrieval semantics, vectorization services, and the context-integration model are Palantir's. The enterprise inherits Palantir's judgment about how context is modeled, embedded, and surfaced — which is precisely the value, but also means retrieval behavior is defined inside Palantir's framework rather than configured against an open, swappable vector store the enterprise operates independently.
Because retrieved units are governed objects rather than text chunks, retrieval inherits the row/column/marking/purpose security of Layer 1A automatically. This is the same structural-security property VAST achieves via permission-inheriting vector rows, reached here through the Ontology's unified security model rather than a shared Element Store.
Move/transform data — ETL/ELT, lineage, cost-aware movement, KV cache tiering
Extensible multimodal connection/transformation across batch, streaming, and real-time replication (CDC) on any bundled runtime (Spark, Flink, DataFusion, Polars), with cohesive security, governance, and provenance tracking. Feeds the Ontology ('South of the Ontology').
Pushdown to Databricks/Snowflake; orchestration with external inference infra, Spark clusters, and on-prem HPC; Compute Modules import any containerized runtime/model/executable, securely orchestrated by Rubix. Pipelines can run where existing compute lives.
Proposed changes (human or agent) live on a branch; reviewed and merged. Versioning spans object types, actions, logic, and policy rules — software-engineering governance applied to operational data and logic.
Pipeline authoring, transformation, lineage, and the open compute framework are Foundry/MMDP IP. Acceleration, if any, comes from the host Layer 0.
Foundry is a mature data-operations platform — connection, transformation, pipeline authoring, and lineage feed the Ontology — and the MMDP documentation makes the compute side notably open. The 'any compute' architecture supports pushdown to cloud-native runtimes like Databricks and Snowflake, 'Bring Your Own Compute' via Compute Modules (any containerized runtime securely orchestrated by Rubix), and orchestration with external inference infrastructure and on-prem HPC. Pipelines can run where the data and existing compute investment already live, not only inside Palantir. The contrast with Dell's Layer 1C is instructive. Dell's most distinctive 1C capability is KV-cache-to-storage offload — an infrastructure-physics optimization with direct inference economics. Palantir has no equivalent, because it does not operate at the storage-physics layer; its movement is logical and operational rather than infrastructural. Where Dell solves 'move bytes between PowerScale and the GPU cluster efficiently,' Palantir solves 'transform and govern data into operational objects, wherever the bytes physically sit.' The governance overlay is the differentiator: Global Branching means a pipeline or logic change — proposed by a human or an agent — lands on a branch, is reviewed, and is merged, with the change versioned across object types, actions, logic, and policy. That makes data movement auditable and reversible at the operational layer, not just the file layer.
Low for pipeline, transformation, lineage, and the open compute framework (Palantir IP). The dependency is that the governed terminus is the Ontology: movement and transformation, however open the runtime, exist to populate and update Palantir's governed model. Pushdown to Snowflake/Databricks genuinely reduces substrate lock-in; the decision layer that consumes the result does not move.
Palantir's interoperability posture is open in both directions — open formats at rest and governed egress to external systems — which is a meaningfully stronger stance than the on-prem storage vendors, whose openness is mostly about ingest.
GPU scheduling, quotas, RBAC, fair-share scheduling, utilization optimization
Palantir's own hardened, autoscaling Kubernetes substrate that orchestrates the platform's workloads — secure-by-default networking, policy-driven node management, continuous cost optimization, FedRAMP High/IL5-6/CMMC. Real orchestration the enterprise consumes without configuring; platform-scoped, not a scheduler for the enterprise's separate fleet.
Apollo computes constraint-satisfied Plans; Rubix executes them via zero-downtime rollouts with automated rollback. Orchestration intelligence separated from execution mechanism — the bridge to the 2C control plane.
Lets a customer run a containerized workload on Rubix and inherit its placement, isolation, and cost optimization. A runtime convenience, not an exposed accelerator-fleet scheduler with quotas or fair-share the enterprise governs.
Rubix is Palantir's own hardened, autoscaling Kubernetes implementation. There is no Run:ai dependency; GPU primitives, when needed, are inherited from the host environment. Rubix runs identically across AWS, Azure, GCP, OCI, and on-prem.
Layer 2A is Ceded, not absent — and the distinction from Layer 0 is the key to scoring it correctly. At Layer 0 Palantir genuinely provides nothing; you bring the floor. At 2A, orchestration absolutely happens: the agents and applications the enterprise buys are scheduled, autoscaled, isolated, and cost-optimized on Rubix, Palantir's hardened Kubernetes substrate. The capability exists and Palantir controls it. What the enterprise does not get is governance authority over it — no exposed GPU-scheduling, quota, or fair-share surface its infrastructure teams or AI application models can configure. Capability exists, vendor controls it, enterprise consumes without authority: that is the textbook definition of Ceded. This matches how the clouds score at 2A. AWS, Google, and Azure all orchestrate customer workloads through managed, largely invisible scheduling that the enterprise cannot configure or override — and that scores as present-and-Ceded, not absent. Rubix is architecturally the same fact: real orchestration the customer consumes without holding the keys. Scoring Palantir's managed orchestration as absent while the clouds' managed orchestration is present-and-Ceded would treat the same architectural pattern two different ways. The strength is moderate, not strong: Rubix is real and capable, but it is platform-scoped (it orchestrates Palantir's workloads, not the enterprise's separate GPU fleet) and it is not a differentiator the buyer chooses Palantir for. Compute Modules lets a customer run a containerized workload on Rubix and inherit its placement, but it is a runtime convenience, not an accelerator-fleet scheduler the enterprise operates. If the enterprise runs a separate GPU cluster for its own training/inference, that cluster still needs its own scheduler (the cloud's, Run:ai, or Kubernetes) — Palantir orchestrates what runs on Palantir, not the wider estate. Against the inverse-of-Dell spine: Dell's 2A is a gap (the capability is needed and NVIDIA's Run:ai holds it); Palantir's 2A is Ceded (the capability exists, is real, and Palantir holds it). Both thin at 2A in the sense that neither hands the enterprise authority — but for opposite structural reasons.
Moderate and Ceded. The enterprise inherits Palantir's judgment about how its Palantir-run workloads are scheduled, scaled, isolated, and cost-optimized — node ephemerality, placement heuristics, workload distribution — without the ability to configure or override it. This is the same borrowed-judgment posture as the clouds' managed orchestration: you get the benefit of the vendor's operational opinion and you do not get to change it. It is bounded, though, because it governs only the Palantir footprint; the enterprise's separate fleet, if any, runs on its own scheduler under its own authority.
Rubix is genuine engineering, productized beyond Palantir's own software (offered to other software vendors for regulated-environment deployment via Palantir FedStart, and underpinning the Mission Manager government onboarding offering). The Rubix↔Apollo split is the architecturally notable detail and the bridge to 2C: Apollo computes the constraint-satisfied Plans, Rubix executes them via zero-downtime rollouts with automated rollback — orchestration intelligence separated from execution mechanism. For the 4+1 buyer, the honest framing is that this orchestration is real and Ceded: you benefit from it, you don't govern it, and it covers the Palantir footprint rather than your whole accelerator estate.
Model serving, agent execution, inference APIs, distributed inference
Stateful control loop over a stateless reasoning core, executing tools/memory under infrastructure- and platform-level guardrails plus developer-configured controls. Per-workload isolation; operational vs. application executions distinguished; every interaction authenticated, authorized, logged. Agents are governed identities, like employees.
Governed access to commercial and open LLMs plus customer/fine-tuned models on a level playing field, via Palantir-managed infra with no provider retention or retraining; regional endpoints where available; token-limit governance across use-cases. Models are swappable and Evals-comparable.
No-/low-/pro-code construction of LLM-driven functions and durable agent orchestrations on top of the Ontology, with tool access scoped by permission (data tools, logic tools, operational tools).
Evaluation suites operating directly against the Ontology: create test cases, debug/iterate agent definitions, compare performance across LLMs, examine execution variance. Automatically tracked against the functions and sub-agents they govern.
Monitoring of every Ontology-feeding data flow, every human/agent action, chained-execution traces, and token/resource consumption. Telemetry and log access are themselves governed by data markings.
AIP's Model Catalog offers commercial models (OpenAI, Anthropic, Google, xAI) and open models (Meta/Llama) on a level playing field with customer-registered, fine-tuned, and existing enterprise models, via Palantir-managed infrastructure that guarantees no provider data retention and no retraining on transmitted data. NVIDIA NIM can be one registered model source among many; none is privileged. Access can be governed with token limits across use-cases.
This is one of Palantir's two strongest layers and a direct contrast to Dell, which Cedes the entire runtime to NVIDIA (NemoClaw/OpenShell/Dynamo). The 'Securing Agents in Production' documentation defines an agent as 'a stateful control loop that repeatedly invokes a stateless reasoning core (a frontier language model), interprets its outputs, executes tools and memory options, and feeds the results back until a termination condition is met' — and then makes that loop the unit of governance. Agents run on Rubix with per-workload isolation; every interaction is authenticated, authorized, and logged; and crucially the runtime distinguishes operationally-privileged executions from application-driven executions operating under precisely governed permissions. The 'any model' philosophy makes the model a swappable component rather than the center of gravity — the Ontology is the center. This is the structural inverse of Google's model-integrated stack, where one model's (Gemini's) judgment pervades every layer; in Palantir the reasoning core is deliberately interchangeable and compared via Evals. The AIP agent lifecycle is a documented build/orchestrate/evaluate loop: no-/low-/pro-code construction (AIP Logic for low-code durable orchestrations, Code Workspaces for pro-code), with AIP Evals operating directly against the Ontology to create test cases, debug, compare performance ACROSS different LLMs, and examine variance across executions. Observability is end-to-end: every data flow into the Ontology, every action by a human or agent, the cascade of chained executions, and even token consumption are monitored — and log access is itself governed by data markings. The agent-as-governed-identity model is the decisive property: agents operate atop the same foundation as human users, abide by the same change management (Global Branching), and weave human-in-the-loop with autonomous operations. Specialized builder agents (AI FDE, AIP Analyst) can themselves construct pipelines, write logic, train models, and build ontologies — under the same governance. This is genuinely Palantir's IP, not a partner framework wrapped in packaging.
Low for the runtime, governance, isolation, and evaluation machinery — all Palantir IP. The reasoning core is explicitly borrowed but equally explicitly interchangeable (any model, no retention, compared via Evals). The enterprise inherits Palantir's judgment about HOW agents are isolated, permissioned, evaluated, observed, and audited; it retains choice over WHICH model reasons. That decoupling is the opposite of the hyperscaler model-integrated pattern and is, for many regulated buyers, the point.
The 2026 forward bet is 'Agentic AI Hives' — autonomous agent networks coordinating on complex problems (e.g., supply-chain disruptions) without human intervention: a shift from decision-support to decision-execution. Shared-Ontology memory plus uniform governance is what Palantir argues makes scaling from single agents to coordinated networks an engineering problem rather than an architectural rewrite. Karp's Q1 2026 framing — differentiating Palantir from model developers amid a 'thousandfold' token-cost decline — is precisely a claim that the durable value is this governed runtime/decision layer, not the model.
Policy-driven placement and resource coordination — the Autonomy Layer
Hub/Spoke topology; continuously evaluates possible Plans against their attached constraints (deployment safety, dependencies, timing, environment health) and issues only satisfied Plans. Automated rollback that always respects human-set holds; connected/disconnected/air-gapped under FedRAMP High/IL5/IL6. Governs platform lifecycle and day-2 ops — not live inference placement.
Reconciles granular role/marking/purpose security across data, logic, actions, and LLM calls for tens of thousands of humans and agents at the moment of interaction — the decision plane for what agents may do. Productized and shipping.
Agents as governed identities; tool calls and queries versioned and tied to Evals; chained-execution tracing; telemetry and log access governed by data markings. A feedback loop for detecting and constraining faulty agent reasoning.
Palantir engineers deploy and manage; Apollo holds an ongoing connection for updates, monitoring, and orchestration ('shared security model'). The reasoning plane is operated under Palantir's authority — the defining DAPM caveat for this layer.
All reasoning-plane logic — Ontology interaction-time security, Apollo's constraint solver, agent governance and observability — is Palantir IP.
Applying the working notes' 'Routing Is Not Reasoning' test, Palantir comes closer than any infrastructure vendor — and the answer has two halves plus a limit. (1) DECISION governance (Intelligence-2C): the Ontology's interaction-time security plus the AIP runtime constitute a genuine reasoning plane for WHICH agent may take WHICH action on WHICH object under WHICH policy, with role/marking/purpose controls reconciled at the moment of action across tens of thousands of humans and agents. Productized and shipping, and the most complete agent-action governance surface in the series alongside Google's. (2) ORCHESTRATION (the surprising part): Apollo is a real constraint-solving control plane. A Hub continuously evaluates every possible Plan for each Spoke, evaluates the constraints attached to each Plan, and issues only those whose constraints are satisfied — with automated rollback that always respects human-set holds, across connected, disconnected, and air-gapped estates under FedRAMP High / IL5 / IL6. Palantir's own framing — 'different from other control-loop systems' because it proposes a transparent Plan and executes only on satisfied constraints rather than acting silently — is almost verbatim the auditable, multi-variable policy reasoning the working notes say is missing. THE LIMIT (the crux for the 4+1 model): Apollo's constraints govern SOFTWARE DEPLOYMENT and day-2 OPERATIONS, not LIVE PER-INFERENCE PLACEMENT of which model serves which request, in which region, at which cost/latency/compliance tier. Palantir has built the control-plane MECHANISM the model wants, and the DECISION plane for agent actions — but the mechanism is pointed at the platform lifecycle and at agent governance, ADJACENT to the live inference-placement function rather than identical with it. No vendor in the series fully productizes that live-placement engine; Palantir is the closest on mechanism, Google the closest on the data→placement chain.
This is the heart of the assessment. Unlike Dell (no judgment to borrow — build custom 2C in 6–12 months, bring a partner, or operate without it), Palantir hands the enterprise a real reasoning plane — but as a fully Ceded, vendor-OPERATED dependency. The platform is not self-deployable: Palantir engineers deploy and manage it; Apollo maintains a persistent connection back to Palantir for updates, monitoring, and orchestration (Palantir's documented 'shared security model'); and Forward Deployed Engineering sustains it. So the judgment exercised by both the decision plane (Ontology security) and the orchestration plane (Apollo) is Palantir's, running inside Palantir's operating relationship. This is the same answer VAST and Google give — the vendor holds Layer 2C — but with a distinctive shape: open data substrate underneath, closed governance/decision authority above, vendor-operated throughout. Absent (Dell) is worse than Ceded (Palantir); but Ceded-AND-vendor-operated is a heavier governance position than Ceded-but-self-operated (e.g., software a customer runs themselves).
Maps directly onto the working notes. Open Question #1 (product or pattern?): Apollo is the series' strongest evidence that the control plane can be a PRODUCTIZED constraint engine, not merely a pattern. Open Question #2 (who builds it?): Palantir is the concrete realization of the 'governance platform / new category' candidate, and the option the Dell assessment named ('potentially Palantir Ontology'). Open Question #7 (does 2C unify Infrastructure-2C and Intelligence-2C?): Palantir unifies them organizationally — one vendor, one authority — but not functionally; agent-action governance and operational orchestration are strong, while live inference placement is the unaddressed third. The DAPM distinction the model surfaces is precise: Dell at 2C is ABSENT (no authority to cede); Palantir at 2C is CEDED-AND-OPERATED (authority exists, is productized, and is held and run by the vendor).
AI-powered business capabilities — business logic, workflow automation
Operational apps and workflows built directly on governed Ontology objects — object-oriented analytics, real-time app building, multimodal governance workflows, persona-tailored out-of-the-box applications, with AI infusion controlled and transparently assessed.
Agents propose and execute real business actions on Ontology objects under human-in-the-loop branching governance — the 'decision-execution' shift toward Agentic AI Hives.
Specialized agents that construct pipelines, write business logic, train models, build ontologies, and develop applications — operating atop the same foundation and governance (Global Branching, interaction-time security) as human builders.
Palantir's human delivery model bridges the last mile from data to operational reality. Value-accelerating, but it deepens the vendor-operated dependency rather than reducing it.
NVIDIA's role at Layer 3 is as one possible model/runtime source (NIM) under 'any model.' Business logic, workflows, and applications are Palantir-and-customer-owned and built on the Ontology.
Layer 3 is where every infrastructure vendor is weakest (partner ecosystems) and where Palantir is native — indeed it is where Palantir STARTS and reaches down from. Because the Ontology binds data, logic, action, and security, applications and agents are built directly against governed business objects: object-oriented analytics, real-time application building (Workshop), multimodal governance workflows, and out-of-the-box applications tailored to operational users, compliance teams, engineers, and analysts, all with the 'infusion of AI carefully controlled and transparently assessed, ensuring a smooth journey from augmentation to automation.' Agents propose and execute real actions on Ontology objects (reroute shipments, trigger purchase orders) under human-in-the-loop branching governance. The contrast with Dell's Layer 3 is the most illuminating in the series. Dell assembles independently-governed ISV agent populations (Palantir is itself one of Dell's named ISVs) with no cross-domain governance binding them on shared infrastructure. Palantir is one such population — but INTERNALLY it has exactly the cross-domain governance the Dell stack lacks: every app and agent shares the same Ontology, the same interaction-time security, the same Evals, the same Global Branching change control. The 4+1 tension this exposes: Palantir solves the multi-agent governance problem WITHIN its boundary; it does not solve it ACROSS an enterprise running Palantir AND ServiceNow AND a homegrown stack — which is the federated reality the working notes (Pattern 3) insist on. Palantir's answer to heterogeneity is MMDP openness at the data layer, not governance federation at the agent layer. Validated traction is the strongest at this layer in the entire series: Q1 2026 revenue +85% YoY to $1.633B, 1,007 commercial customers (+31%), US commercial +133%, Rule of 40 at 145%, with named production deployments (SAP reporting >99% validation accuracy and large cloud-migration reductions; GE Aerospace; Airbus; Stellantis). Analysts characterized AIP as 'an operational system for deploying agents with governance, cost attribution, and auditability, not a model wrapper' — a Layer 3/2C claim, not a Layer 0/1 one.
Distributed between Palantir and the customer, which is architecturally correct at Layer 3 — but unlike a neutral application platform, the value layer is inseparable from Palantir's governance, runtime, and operating model beneath it. You do not adopt Palantir's Layer 3 without adopting the Ontology, Rubix, Apollo, and the vendor-operated relationship. The value is real and the governance is real; both are Ceded together.
Forward Deployed Engineering is the human mechanism that bridges the 'last mile' from data to operational reality and is central to Palantir's traction — but it deepens the operating dependency rather than reducing it, reinforcing the Layer 2C 'vendor-operated' finding. The AIP architecture's 'enterprise automation' category (specialized builder agents like AI FDE and AIP Analyst constructing pipelines, logic, models, and ontologies under the same governance as humans) is the clearest expression of the augmentation→automation trajectory and of why the value layer cannot be cleanly separated from the layers beneath it.
Palantir is the first vendor in this series that is not an infrastructure vendor at all, and reading its own documentation makes the inversion precise. Dell, HPE, VAST, Cisco, and the clouds build upward from silicon, storage, or a data center; Palantir builds downward from the decision. Its Architecture Center is explicit that the Ontology is designed to represent 'the complex, interconnected decisions of an enterprise, not simply the data.' Where Dell is strongest at Layer 0 and absent at Layer 2C, Palantir is structurally absent at Layer 0 and strongest at Layers 1A (governance), 2B (governed agent runtime), 2C (reasoning/orchestration), and 3 (value). It is the mirror image of every infrastructure vendor assessed so far.
Palantir's data and compute architecture is genuinely open, and that openness is exactly what makes the capture hard to see. The Multimodal Data Plane uses Apache Iceberg as its primary table format, registers Databricks / Snowflake / BigQuery data through Virtual Tables 'without needless data duplication,' pushes compute down to those same engines, stores data at rest in open formats (Iceberg/Parquet) reachable over REST/JDBC/S3, and supports being 'one participant in a wider' data/AI mesh — Palantir's own 'unwalled garden.' Every one of those openness claims is true. But openness at the data and access layers is not portability of the thing the enterprise actually builds. The test that matters is whether a vendor's opinions — its proprietary way of modeling, governing, and orchestrating — can be lifted out and operated elsewhere. Palantir's opinions are the Ontology, and they run only on Palantir.
The boundary, then, is not the data — it is the opinions plus the operating model. Even when data stays in Snowflake and compute pushes down to Databricks, the Ontology (objects, links, actions, and interaction-time security), the agent runtime, and the deployment control plane remain Palantir's, deployed on Palantir's hardened Kubernetes substrate (Rubix) and operated under Palantir's connection. The four-fold integration of data, logic, action, and security is the proprietary IP; the storage underneath is deliberately commoditized and open. The capture is Oracle-shaped: open at the access layer, captive at the layer of accumulated proprietary dependence — and like Oracle, the lift to leave compounds with every use case built, because every object model, action, agent, and workflow is Palantir-specific surface that would have to be rebuilt elsewhere.
Apollo is the most important find for the 4+1 model, and the documentation makes both its power and its limit exact. Apollo is a genuine constraint-solving orchestration engine: a Hub continuously evaluates every possible Plan for each Spoke, evaluates all constraints attached to each Plan (maintenance windows, product-dependency version ranges, suppression windows, artifact availability), and issues only Plans whose constraints are satisfied — across connected, disconnected, and air-gapped estates under FedRAMP High, IL5, and IL6. Its explicit 'propose-a-Plan-then-execute' paradigm, with a dependency-graph invalidation model and break-glass overrides, is the closest thing in the entire series to the multi-variable policy reasoning the working notes describe. The limit: Apollo's constraints govern software deployment and day-2 operations — versions, dependencies, time windows, artifact presence — not live per-inference placement of which model, which region, which cost tier at request time. Palantir has built the control-plane MECHANISM the 4+1 model wants; it is pointed at the platform lifecycle and at agent actions, adjacent to the Infrastructure-2C placement function rather than identical with it.
The DAPM crux cuts as sharply as it favors. Palantir hands the enterprise a real governance surface, a real governed agent runtime, and a real constraint-based control plane — but as a Ceded dependency operated under Palantir's judgment. The platform is not self-deployable; Palantir engineers deploy and manage it, Apollo holds a persistent connection back to Palantir for updates, monitoring, and orchestration, and Forward Deployed Engineering bridges the last mile. This places Palantir in the proprietary-captive cluster with Google, Oracle, and VAST — heavily Ceded — distinguished by a decoupled capture mechanism: where VAST couples (your data must enter its namespace, so the commitment is visible), Palantir decouples (your data stays open, so the commitment is invisible until you try to leave). The inverse-of-Dell shape holds end to end. Dell owns the floor and is Absent at the reasoning plane, so it says 'bring any Layer 2C' — and that 2C arrives Delegated and substitutable, leaving authority distributed. Palantir Cedes the floor and owns the reasoning plane, so it says 'bring any Layer 0' — and everything above the floor consolidates into one Ceded-and-operated authority. Same invitation, opposite consequence: a federated answer to 'who ties the control plane together' versus a unified one. Q1 2026 (revenue +85% YoY, 1,007 commercial customers, US commercial +133%, Rule of 40 at 145%) shows a growing number of enterprises accepting the unified trade.