Companies · July 4, 2026
Palantir and the Control Plane for Enterprise AI
Drafting an email does not require frontier intelligence, yet enterprise AI spend has concentrated at the top of the capability curve while the true cost of a token stayed hidden. As that subsidy ends and cognition commoditises, this note argues that value moves from the model endpoint to the layer that governs how models act inside the enterprise — the ground Palantir's AIP and Ontology already occupy.
Drafting an email does not require frontier intelligence. Neither does tagging a support ticket, extracting line items from a clean invoice, formatting a customer note, or summarising a routine meeting transcript. Much of enterprise AI does not need a model that can do PhD-level mathematics. Yet AI spend has so far concentrated near the top of the capability curve, partly because the true marginal cost was hidden. The labs subsidised usage to gain market share, subscription bundles flattened consumption into a fixed monthly fee, and internal "tokenmaxxing" leaderboards rewarded employees for using as many tokens as possible as quickly as possible. That may have been a useful phase. It pushed people to experiment and helped companies discover where AI could matter. But the subsidy period is ending.
Anthropic's Fable 5 lists at $10 per million input tokens and $50 per million output tokens, making it the most expensive generally available model Anthropic has priced. Run through an agent harness over a large codebase or a long research task, with context replayed across dozens of turns and sub-agents fanned out in parallel, a single session can easily reach $1,000. Fable is also no longer fully buried inside the subscription bundle. Developers who were effectively consuming up to $14,000 of API-equivalent tokens on a $200 monthly plan now have to confront API pricing directly.
The model leads the benchmarks that matter and has shown capabilities previous systems did not have, both in published results and in our own use. Anthropic's Chinese competitors and the stronger open-weight families offer useful intelligence at a fraction of the cost. They still lag the frontier on the hardest tasks, but they dominate the cost-capability frontier for work that does not require the top tier.
Alex Karp gave this its name on Palantir's fourth-quarter 2025 earnings call. He called it commodity cognition. For any fixed level of capability, the price of cognition is falling quickly. Frontier models will still matter, especially for the hardest reasoning, coding, research, and agentic workflows. But enterprise AI will not standardise on one model. It will run as a heterogeneous fleet: frontier models, cheaper hosted models, open weights, specialised domain models, local deployments, and sovereign stacks.
Once that happens, model choice becomes part of production architecture. The system has to decide which model can use which data, under which authority, and how the result is written back into the system of record.
Palantir's claim is that AIP and the Ontology already sit at that layer. AIP runs the models and agents. The Ontology gives them the governed enterprise state to operate against.
This note argues that as cognition commoditises, value moves from the model endpoint to the system that governs how models act inside the enterprise.
Concentration risk and the case for a plural stack
Anthropic released Fable 5 on 9 June 2026. Three days later, access was suspended under a US Department of Commerce export-control directive. The directive applied to foreign nationals, but Anthropic said the practical effect was a global suspension because it could not verify nationality in real time across its customer base. Fable later returned after the controls were lifted, but the episode still mattered. A frontier model had been pulled for reasons that had nothing to do with customer demand or model performance. In a more contested regulatory and geopolitical environment, Fable is unlikely to be the last frontier model whose access changes for policy reasons. Standardising on the single strongest closed model maximises performance and, at the same time, the probability of a sudden cutoff.
The cloud transition is an example where companies already account for this, though for a narrower reason. Firms running critical infrastructure do not single-source a cloud provider, because an outage or a contractual break at one vendor cannot be allowed to take down the business, so they architect for failover. AI embedded in mission-critical process will inherit this requirement. A second model covers outage, deprecation, sudden repricing, vendor policy changes, and political interruption.
Through the first half of 2026, models post-trained on proprietary expert data in a narrow domain began to beat general-purpose frontier models on that domain at a fraction of the cost. Bridgewater's AIA Labs, with Thinking Machines, fine-tuned a model to replicate investor judgment across six information-filtering tasks and reached 84.7 percent average accuracy against frontier baselines that stalled in the mid-to-high seventies, at roughly fourteen times lower cost per task. They call the result differentiated intelligence: an organisation's proprietary expert-labelled data as a structural moat a general model cannot cross with scale alone. In law, Harvey post-trained the open-weight GLM-5.1 on its Legal Agent Benchmark and lifted it past both GPT-5.5 and Anthropic's Opus 4.8 on rubric pass rate, the first trained model in the industry to clear that mark. In both cases, the companies chose open-weight models.
Closed-model fine-tuning exists as well, but the attraction of open source is control. Open weights let the customer own more of the training loop, evaluation process, deployment environment, and unit economics. That matters when the model is being shaped around proprietary expert data rather than used as a generic endpoint. Kimi, Qwen, GLM, DeepSeek, and Nvidia's Nemotron are becoming recurring base models for that kind of domain-specific system.
Chinese open-weight models raise an obvious security objection, but the risk depends on how they are used. A hosted API or consumer app can expose prompts and outputs to the vendor's infrastructure and privacy policy. Running the weights on trusted infrastructure, however, is different. A company can deploy GLM, Qwen, or DeepSeek in its own cloud environment, on-premises, or air-gapped where required. American cloud providers also serve several of these models directly; Amazon Bedrock hosts DeepSeek, Qwen, GLM, and Kimi while keeping inference inside AWS and stating that customer inputs and outputs are not shared with the model developer or used for training. That removes the simple data-transfer concern. It leaves the harder questions: weight-level trust, political optics, embedded behaviour, and the regulatory sensitivity that keeps Chinese weights out of defence and intelligence work for now.
Artificial Analysis Intelligence Index v4.1
Claude Fable 5with fallbackClaude Opus 4.8
GPT-5.5Claude Sonnet 5
GLM-5.2
Gemini 3.5 FlashGemini 3.1 Pro
Qwen3.7 Max
MiniMax-M3
DeepSeek V4 Pro
Kimi K2.6The current trend favours smaller, post-trained, domain-specific models for tasks that can be verified cleanly. The advantage they have can also compound: a model tied to a proprietary workflow turns each completed task into new labelled data for the next training round. The main counterargument would be that a future frontier model could become so capable that specialisation stops mattering. But enterprises do not buy the most capable model in the abstract. They buy the model that clears the required accuracy at the lowest cost. As frontier capability rises, the top tier keeps the hardest tasks, while more high-volume, verifiable work moves to specialised models that are already good enough.
The enterprise ends up running both: closed and open, foreign and domestic, general and specialised. Something has to decide which model runs on which data, under which authorisation, and how the outputs are reconciled into one record. That is the work of a control plane.
What routing is, and where it stops
Routing is the natural first implementation of a multi-model stack. A classifier reads the prompt, sends easy tasks to a cheaper model and harder tasks to a stronger one, and lowers the blended cost. It does not need to understand the enterprise, which is why it can be sold as a metered gateway or an out-of-the-box optimisation layer. For high-volume, legible traffic like classification, extraction, formatting, retrieval, and simple summarisation, it works well.
The ceiling appears when the difficulty of the task is not immediately legible. Routing is a prediction made before the work begins, but the hard part of the task is often not visible in the prompt. "Summarise this contract" can mean a routine summary or a legally sensitive edge case, depending on the clauses, counterparties, amendments, jurisdiction, and business context inside the document. On homogeneous work, the prediction is clean. On heterogeneous, high-context work, it degrades because the prompt is an incomplete representation of the task.
That degradation is hard to correct because models have limited introspection into their own limits. Given a task above its capability threshold, a weaker model rarely fails cleanly. It usually returns a fluent, confident, wrong answer. The ability to recognise that a task is too hard often requires the same capability the model was missing in the first place. A model that could reliably identify its own hard-task failures would already possess part of the competence needed to handle them. The escalation signal the router wants is therefore the signal the cheap model is least likely to provide.
Verification and escalation can patch this, but the economics are challenging. You pay for the cheap attempt, then pay again for the stronger model, often with a cold re-read of the same context because the strong model cannot inherit the weaker model's KV cache. When hard cases are rare the retry tax is tolerable, but for common tasks the rerouting costs can stack up quickly.
Portable KV cache may reduce this penalty over time, but it does not remove the architectural problem. Prefix caching works when the same model sees the same context. Cache reuse across adapters is plausible when models share a base. Cross-model KV transfer between unrelated models is still research-grade and depends on projections, selective recomputation, or assumptions a generic enterprise router cannot rely on. Heterogeneous fleets still need task state to live outside the model.
Naive routers also learn little at inference time. Their instructions are usually defined in context, so the same document type can keep producing the same mistake. One invoice may be a clean export, another a scanned ledger with missing fields and unusual line-item logic. Without the enterprise's process history, the router has no record of what worked last time. The useful signal for routing sits in the state: what happened last time with this document type, this counterparty, this system, this user, this approval path, this exception class.
Routing is useful for legible, high-volume tasks where difficulty can be read at the door. It reaches its limits on illegible, high-value tasks, because the relevant decision requires information the prompt usually does not carry: what the task touches, who may see it, what authority the model has, what process it sits inside, and how its output must be reconciled into the system of record.
For these tasks, the workflow decides which model to use. The system must carry state across handoffs, enforce permissions at each step, and write outputs back into one governed record. That operating layer is where the durable value sits.
Ontology as a control plane
Palantir describes its Artificial Intelligence Platform as providing unified access to open-source, self-hosted, and commercial large language models, and as turning an organisation's data, actions, and processes into objects and tools that both humans and model-driven agents can use. Read past the marketing cadence and that is a precise description of a control plane. It sells the layer that binds any model to a live operating state of the enterprise and mediates what that model is allowed to see and do.
The combination of AIP and the Ontology is what makes Palantir distinctive in enterprise AI. Ontology is a live model of how the organisation works: its objects, relationships, permissions, actions, functions, and process logic. AIP is the execution layer built against that model. It gives models and agents access to workflows, tools, evaluations, and approved actions inside the business.
Consider a routing decision in a regulated enterprise. It is rarely whether a query is hard or easy. It is about knowing which data the task touches, whether that data can leave the perimeter, which user or agent is authorised to act on it, whether the action changes a governed record, and whether the workflow requires human approval before anything is committed. Those constraints usually do not appear in the prompt. They sit in the data lineage, the object model, the permission structure, and the process state of the enterprise. This is where Palantir's stack differs from a gateway router. A router can classify a request and select a model endpoint. AIP, when bound to the Ontology, can make model selection part of the workflow itself.
This also reframes the cache-tax problem. If switching models mid-stream destroys the cache, the architecture should not depend on mid-stream switching. Portable KV cache may reduce the penalty over time, but heterogeneous model fleets still need task state outside the model. The work should be decomposed into stages, with model assignment decided at the stage boundary. One model may classify the document, another may extract fields, another may handle the exception, and another may generate the customer-facing response. The system function that matters is preserving task state across handoffs, enforcing permissions at each step, and reconciling the outputs into the system of record.
AIP provides the environment where models, agents, workflows, tools, and evaluations run. The Ontology provides the governed enterprise state those systems operate against. Together, they allow model choice to be determined by the workflow, the data, the user, the action, and the required audit trail, rather than by a prompt-level estimate of task difficulty.
This is why we believe the routing market is directionally right but structurally too thin. Enterprises will need model selection, because intelligence is fragmenting across frontier models, open weights, specialised models, local deployments, and hosted APIs. The question is where that selection is controlled. In production, every company will need a control plane for model choice, data access, permissions, workflow state, and write-back into the system of record.
The deployment gap
In Q1, Palantir reported $1.63bn of revenue, up 85% year over year. US revenue grew 104% to $1.28bn. Adjusted free cash flow was $925m at a 57% margin, and the Rule of 40 score reached 145%. Management also raised full-year 2026 revenue guidance to $7.650bn to $7.662bn, implying roughly 71% growth.
US commercial revenue grew 133% to $595m. US government revenue grew 84% to $687m. Commercial is accelerating faster, but government remains the larger US segment. This note focuses on the commercial business because that is where the control-plane thesis is most visible. Palantir is not a pure enterprise AI software company. Defence modernisation and government automation are strong businesses in their own right, and they reinforce the commercial opportunity. Each deployment adds product surface area, implementation knowledge, security patterns, and workflow logic that can be reused elsewhere.
Enterprise AI adoption is still mostly stuck between experimentation and production. MIT's NANDA report found that despite $30–40bn of enterprise investment into generative AI, 95% of organisations in its dataset were getting zero return. More than 80% had explored or piloted tools like ChatGPT and Copilot, and nearly 40% reported deployment, but only 5% of enterprise-grade custom or vendor-sold systems had reached production. The report's diagnosis was not that the models were too weak. It was that most systems failed to retain feedback, adapt to context, or align with day-to-day operations.
The enterprise deployment gap
The hyperscalers are now building their own versions of Palantir's delivery model. AWS announced a $1bn Forward Deployed Engineering organisation in late June, built to embed thousands of engineers with customers and co-develop agentic AI systems in production. Microsoft followed with Microsoft Frontier Company, backed by a $2.5bn commitment and 6,000 engineers and industry specialists focused on enterprise AI deployment. Google Cloud is hiring Forward Deployed Engineers in Applied AI whose role is to take conversational prototypes into production-ready systems. ServiceNow and Accenture have launched a Forward Deployed Engineering programme for agentic AI across the enterprise.
Karp's recent comments should be read against that backdrop. His attack on token-based AI consumption is not just a complaint about pricing. It is a claim about where enterprise value is created. If a company pays for tokens that do not change a workflow, update a record, reduce labour, or improve a decision, the spend is mostly theatre. Palantir's argument is that value appears only when AI is bound to the institution's data, permissions, processes, and actions.
If every major platform company now needs embedded engineering teams to make AI work inside customers, the scarce capability is the ability to translate messy operational reality into software, permissions, workflows, evaluations, and governed actions. Palantir has spent two decades building an organisation and product stack around that problem. The open question is whether AIP and the Ontology let it turn a services-heavy deployment motion into reusable software faster than the hyperscalers can learn the workflow layer.
The current phase of enterprise AI is the move from pilots to production. Agents cannot remain generic assistants outside the business. They have to classify documents, check exceptions, draft functions, update workflows, prepare decisions, and participate in the coordination loops where work actually happens. Palantir's DevCon 5 announcements point directly at this shift. AI FDE, MINDKIT, Orchestrator, and Ontology Foundations are aimed at putting agents into production workflows with the permissions, evaluations, security controls, and business context required to act safely.
