Workflow, Not Workers: Palantir CTO Reveals Why AI Fails to Scale Enterprise Productivity

Introduction: The Atomic Unit of Enterprise Is the Workflow

"What is the atomic unit of the enterprise? The presumption, as expressed through the product strategy you see from the labs, is that the atomic unit of the enterprise is the knowledge worker — if I can make every worker more productive, that's the ROI, and that's not actually true. The atomic unit of the enterprise is the workflow, you can make a single supply-chain analyst more productive and generate no incremental ROI, you have to make the entire supply-chain workflow measurably more productive to capture the value."

This quote from Palantir CTO Shyam Sankar in his interview with Ben Thompson on Stratechery (Oct 29, 2026) frames the article's core thesis: enterprise AI adoption is bottlenecked not by model intelligence but by the diffusion of that intelligence into workflows.

Two Flywheels: Model Intelligence vs. Business Productivity

The author identifies two distinct flywheels:

Model Intelligence Flywheel : R&D and compute investment → stronger models → more revenue/investment → next R&D cycle. Determines what machines can do.

Business Productivity Flywheel : Enterprises redesign workflows around AI → execute, feedback, evaluate, improve in real business → sustained operating results. Determines what enterprises continuously achieve .

The first flywheel spins fast and distributes via API. The second is embedded in each company's processes, systems, and organization — it cannot be bought off the shelf. The real bottleneck today is the second flywheel and the connection between them.

I. Why Stronger Models Don't Automatically Raise Productivity

Workflow: The True Landing Point of Productivity

Frontier labs (OpenAI, Anthropic) implicitly assume the atomic unit is the knowledge worker. Sankar counters: "The atomic unit of the enterprise is the workflow." A supply-chain analyst may become 10x faster, but if purchasing approval, inventory allocation, production scheduling, and delivery remain unchanged, the end-to-end chain stays stuck at the same bottleneck.

Enterprise productivity is systemic. Local efficiency gains, even 10x, yield limited overall returns if the key constraint persists.

Coding is an exception: a single engineer often embodies a relatively complete workflow ("cardinality collapse"), so AI coding shows apparent 10x gains. But coding is a tiny slice of the economy. In manufacturing, supply chain, finance, value realization spans multiple roles, systems, and decisions — explaining why broad AI adoption remains limited.

Three layers of AI value:

Task Efficiency : Is a single task done faster/better?

Workflow Productivity : Does the end-to-end process improve in throughput, cycle time, quality, cost?

Business Outcomes : Does it drive more revenue, profit, capacity, or previously impossible capabilities?

The critical question: where is business value actually created, what is the true bottleneck, and can AI change that bottleneck?

Top Line over Bottom Line: Redesigning Business Around Machine Intelligence

Sankar observed that clients aiming to cut headcount with AI rarely succeed. Successful adopters have bigger ambitions: "I want to use AI to lead my market," "I want to do things that were always too expensive."

Two reasons: (1) Cost-cutting is too short-term to drive the hard organizational redesign needed. (2) Human and machine intelligence operate differently in workflows; rational division of labor matters more than replacement. If the goal is "replace humans," AI must do 100% of what humans do — 98% fails because the remaining 2% blocks the loop.

Enterprises should leverage Model Capability Overhang — build workflows around what models can do, rather than forcing a binary human-vs-AI choice.

Key insight : Model capabilities determine which workflow designs are technically feasible; organizational and business design determine how much economic value those possibilities release.

II. How to Start the Enterprise Productivity Flywheel

Three sequential questions:

What problem are we really solving?

How is that problem expressed as objects and actions a system can operate on?

How are those actions reliably executed?

Palantir's FDE, Ontology, and Systems Engineering map to these three links.

FDE (Forward-Deployed Engineering): Get the Problem Right

Sankar: "FDE is first a product strategy, not a role." It applies when customer needs follow a power-law distribution — a few customers face the hardest version of a problem that others will eventually encounter. You go deep with those "future-living" customers, then generalize from Specific to General.

Engineers naturally hate one-off work and prefer reusable abstractions. But only by solving for the first, second, third customer do you accumulate enough surface area to see the right generalizable form. The hard judgment: at which layer of the stack should abstraction live? End-to-end solutions overfit to a single customer; you must decide what to generalize and what to leave configurable.

Great FDE talent is rare — two archetypes in unstable equilibrium:

MacGyver-type hackers : thrive on solving messy real-world problems (the "first 80%").

Artists : craft elegant, reusable systems (the "last 80%").

They disdain each other; the organization must hold them together.

Sankar criticizes "sparkling sales engineering" — sending smart engineers to customers without a mechanism to turn field pain into product. Hence FDE belongs to Product, not Go-to-Market .

For model companies (OpenAI, Anthropic), the model itself is their FDE. The core value is problem decomposition. As AI coding lowers implementation cost, the bottleneck shifts upstream: discovering, decomposing, and abstracting the right problem. "The cheaper software implementation gets, the more expensive 'building the right thing' becomes."

Ontology: Make Business Programmable for AI

Palantir views the enterprise as a complex state machine: orders, inventory, procurement, production — each state transition governed by business rules, system dependencies, permissions. Ontology models not just nouns (data) but Verbs — executable business actions.

Ontology makes the enterprise "programmable" — a harness for humans to operate the business. In the AI era, that harness must become usable by models.

Example: A supply-chain agent must know not only which materials are low, but whether it can adjust purchase orders, which actions need approval, and how execution updates business state. Understanding business vs. operating business requires state, actions, permissions.

Deployment is gradual: workflows start with humans, hand off to AI, return to humans. The state machine must be agnostic to initiator — governance rules and executable actions stay consistent whether a human or AI triggers them.

Focus shifts from "making models understand business" to "managing business state and execution processes."

AI coding (Codex, Claude Code) makes this layer more critical, not less. Without a governance layer, enterprises accumulate disconnected, throwaway apps — "AI slop." Ontology provides a governable constraint point: people can vibe-code freely, apps are cheap to run and discard, yet the enterprise operating system remains consistent.

Evolution: Upper applications become lighter and more customized; lower business state, execution interfaces, and governance must become more consistent.

Systems Engineering: Make AI Accountable for Real Work

When agents modify business state, call external systems, affect real outcomes, reliability is paramount. A capable model ≠ a working system. Model companies suffer "Model Blindness" — believing models will eventually solve everything. Enterprise AI must ask: what engineering must wrap the model to capture business value?

Systems engineering philosophy: incidents trigger postmortems that specify what to build, fix, change to prevent recurrence; risk drops through continuous engineering improvement.

Three layers for enterprise AI:

Model Capability : Does the model have the raw ability?

System Reliability : Can the full system execute stably and correctly? (tool failures, retries, state conflicts, exception recovery) — requires deterministic software, permission controls, monitoring.

Operational Accountability : Can execution and results be supervised, audited, corrected? Is responsibility clear?

Together they determine how much real work an enterprise can delegate to AI.

The flywheel turns: FDE finds and abstracts high-value problems → Ontology organizes state/actions into an AI-operable system → Systems Engineering ensures actions are reliable, controllable, auditable → model intelligence enters real business → each execution feeds the next round of system improvement → compounding enterprise-specific returns.

III. From One-Off Efficiency to Sustained Productivity Growth

Most AI apps today are simple: input → model → output. They improve only when the underlying model improves — no internal feedback/evaluation/improvement loop. They create value but lack their own productivity flywheel.

Alpha vs. Beta: Where Does Enterprise Differentiation Come From?

Traditional SaaS sells standardized workflows (Beta — industry baseline efficiency). AI-era differentiation (Alpha) comes from proprietary capabilities. IT departments gravitate to Beta (best practices, safe choices). Business units crave Alpha ("my strategy is hard to execute").

If enterprises merely rent intelligence via API from model providers, they feed the model's compounding knowledge while losing their own Alpha. Survival question: "What is my company's moat? If all enterprise intelligence ends up in model weights I don't control, what do I do?"

Answer: Retain your Alpha. As generic intelligence commoditizes, differentiated capability accumulates in daily operational decisions — procurement, production, pricing, customer service. These embed unique constraints, strategies, experience. The challenge: turn them into continuously accumulating system capabilities.

Operational Learning: Turning Business Data into Learning Signals

Enterprises need a continuous post-training pipeline: operational decisions generate data → monthly new checkpoint training → evaluation against all prior versions and historical decisions.

Palantir's auto-research project: no large post-training team needed; supply-chain or production planning decisions automatically train models in background, then surface "here's a model that outperforms your current one." Every model call becomes a trace collected and fed back — building the enterprise's own compounding loop.

Example: Electronic component quoting. Customers submit complex electrical engineering drawings — unseen by frontier models. The enterprise has 10-20 years of human-completed records: input specs → output BOM. Training a specialized model takes weeks; thereafter the enterprise quotes faster than competitors who must spend weeks deciphering the same specs.

This is RSI (Recursive Self-Improvement) in practice.

Crucial caveat : Raw operational data ≠ learning signals. A quote wins due to price, relationship, competitor stock-out, market noise. A schedule improves delivery but may not generalize. Without linking decisions to outcomes, the system reinforces wrong lessons.

Three conditions for data to become learning resources:

Observable : Business context, key decisions, execution process, actual outcomes are linked.

Evaluable : Can judge which outcomes represent genuine improvement, separating external noise and historical bias.

Reusable : Verified conclusions enter knowledge, rules, workflows, tools, or models and transfer to future tasks.

Bench-making: Enterprises Need Their Own Evaluation Systems

"Evaluable" means evaluating on your production scenarios, not public leaderboards. Model capabilities are "jagged" — high public scores don't guarantee performance on your tasks. The shift: from bench-maxxing to bench-making .

Strong recommendation: Build a real production evaluation system that comprehensively captures your problem distribution early. What are your standards? What do you care about? How do you trade latency, cost, performance? Moves focus from "latest coolest model" to "what actually matters to me, and how much did it improve?"

Three evaluation layers:

Model Evaluation : Did the model understand the task and meet output requirements?

Workflow Evaluation : Did the agent call tools correctly, handle exceptions, complete the process?

Business Outcome Evaluation : Did the system improve efficiency, quality, revenue, or other KPIs?

Supply-chain agent example: don't just measure forecast accuracy; check if purchase suggestions are executable, inventory turnover improved, delivery risk reduced. Only linking system performance to real business outcomes gives improvement direction.

Continuous learning doesn't always mean retraining. Some fixes: update knowledge, adjust rules, improve tool interfaces. Some need workflow redesign. Only when task, data, and economics align does dedicated model training make sense. Enterprise AI continuous learning is:

Business Execution → Observable Outcomes → Evaluation → System Improvement → Better Execution

This is the core mechanism of the Business Productivity Flywheel.

When Does Continuous Optimization Become Compounding?

Continuous optimization ≠ compounding. If each fix is scoped to a single scenario and the next problem requires starting from scratch, there's no accumulation.

Compounding requires net positive returns: new business value must exceed data governance, evaluation, training, and maintenance costs. Improvements must be reusable across scenarios (lowering future problem-solving cost) and deployed under controlled validation with monitoring to detect drift and enable rollback.

Borrowing from learning-rate concepts, the author proposes Learning Efficiency : how cheaply and quickly real business experience converts into verified, reusable system improvements. This may better capture an enterprise's sustained learning ability than data volume, parameter count, or training runs. When accumulated experience not only improves the current task but lowers future learning and delivery costs, the flywheel accelerates.

IV. How the Two Flywheels Reinforce Each Other

Model → Business: Capability Adoption

Each model advance brings new tasks into the technically feasible zone. But enterprises must still do workflow design, system integration, permission validation, production deployment. Realized value of a model upgrade depends on whether it can be turned into deployable, measurable business improvement at reasonable cost.

Enterprises need rapid absorption capability: evaluate new models on their own tasks, choose appropriate technical approaches, safely inject new capabilities into business flows. Model flywheel spins faster → Model Capability Overhang grows more visible.

Business → Learning: Operational Learning

Real business continuously generates new problems, experience, feedback → drives improvements in knowledge, rules, tools, workflows, specialized models. With proper authorization, data quality, training mechanisms, this can also feed broader model research.

Sankar's manufacturing insight: "Innovation is a byproduct of production. Once you stop making things, you lose the stimulus to innovate around them." Google's "Attention Is All You Need" originated from a team wanting 3% better Google Translate. Hard to imagine such a mundane start yielding such profound results.

Same logic in AI: Real deployment is both the source of productivity and the source of learning. If AI stays in demos and sandboxes, it loses the stimulus from real production environments.

Connection isn't automatic — data quality, permissions, feedback loops, evaluation capacity determine whether experience becomes next-round improvement.

What Really Matters: Conversion Efficiency Between Flywheels

More important than tracking model capability growth: how fast and effectively new intelligence enters real business, and whether enterprises can continuously turn execution experience into verified system improvements.

Former = Capability Adoption , latter = Operational Learning . Together they determine the conversion efficiency between model progress and business productivity — the core of Sankar's "Intelligence Diffusion" question: how to turn tokens into economic value faster and with better ROI?

Model companies can move up the application layer; enterprises can build and train specialized models. As agent capabilities rise, some FDE and business architect work may shift to models. The flywheel distinction lies in optimization objectives and learning mechanisms, not in which company must forever own which task.

Pragmatic enterprise strategy: fully leverage general LLM capabilities while retaining execution control, accountability, model choice, effective evaluation, and continuous learning for key business workflows — this is the practical meaning of "Own Your Intelligence."

Conclusion: From Model Progress to Sustained Productivity Growth

Sankar's interview pulls AI discussion back from leaderboards and launch events to workflows, factories, and operating results.

Model capability growth matters, but actual value creation depends on whether enterprises can redesign workflows, build reliable execution, and establish continuous learning. Palantir's FDE, Ontology, Systems Engineering, and post-training practices illustrate the second flywheel — but the underlying questions are universal for every team building enterprise AI.

In enterprise AI adoption, keep asking:

Which high-value workflow did we truly improve? Can the system execute reliably and produce measurable business outcomes? Can each real execution's experience be converted at reasonable cost into verified, reusable improvements for the next cycle?

These map to value creation, reliable execution, and continuous learning. Model progress provides new possibilities; business systems decide how possibilities are realized; continuous learning decides whether realized value keeps compounding.

"The model flywheel determines what machines can do; the business flywheel determines what enterprises can continuously achieve."

The long-term focus is whether the two can form an efficient, sustainable connection — letting model progress translate faster into business outcomes, and real business experience continuously drive the next round of improvement.

References

Ben Thompson, An Interview with Palantir CTO Shyam Sankar About the AI Religious War, Stratechery, Oct 29, 2026.