Palantir CTO Shyam Sankar sat down with Ben Thompson for a Stratechery interview published October 29, 2026, titled "An Interview with Palantir CTO Shyam Sankar About the AI Religious War." The page lists the topics: diffusing intelligence, top line versus bottom line, safety and systems engineering, Palantir's AI lessons, alpha versus beta, model questions, forward-deployed engineering, Anthropic's battle with the US government, and AI religion.
I could read the opening sections, through the safety and systems-engineering discussion. The later sections, including forward-deployed engineering and the Anthropic discussion, were not in the text I could access, so I do not summarize them here. Everything below is Sankar's view as stated to Thompson, from a CTO whose company sells the integration layer he is praising. That conflict of interest is worth holding in mind throughout.
Sankar also appeared on CBS's Face the Nation on October 11 (transcript), where he argued the doomsayers have largely been wrong. For earlier coverage of his public positions, see our post on his Face the Nation remarks about the OpenAI Hugging Face hack.
TL;DR: the claims
| Claim | Sankar's argument | How to read it |
|---|---|---|
| Diffusion is the bottleneck | Industry over-invests in better models and under-invests in spreading value | Opinion, with an electricity analogy |
| The workflow is the unit of the enterprise | Making one worker faster yields no ROI unless the whole workflow improves | A framing; coding is his exception |
| Headcount-cutters fail | Customers aiming to reduce headcount or cost almost all failed at it | His customer observation, not a study |
| Ambitious customers win | Those aiming to dominate a market succeeded wildly | Same caveat |
| Labs lack systems engineering | Safety is treated as testing for failure, not designing the system | Criticism of labs; he sells such systems |
Is the industry solving the wrong bottleneck?
Thompson asked about Sankar's claim that the AI industry is over-investing intellectually in the supply of intelligence and under-investing in diffusion. Sankar's answer used electricity. Power producers generate electrons, but economic impact required others to build machine tools that ran on them, and eventually to redesign factories around having electrons. He sees a parallel: "we are very focused on how to make better models," and should keep doing so, but are "very under-indexed on how to accelerate the rate of diffusion."
He named the labs and "the entire market structure" as the audience. His reading of the incentives is that a lab doing fundamental research, making a more powerful model and seeing its valuation double is rewarded, with the assumption that value will diffuse eventually. His counter: there is a "license to operate in society" that depends on the benefits actually arriving. Asked why it matters, he said the aim is to use AI to make society better, and cited AlphaFold as impressive yet, in his words, with "zero drugs on the market" because of it. That is a checkable claim I did not verify, and he presented it as rhetoric.
This connects to a theme we have covered before: the gap between lab capability and enterprise return, discussed in our piece on the AI verification tax, where checking and redoing AI output eats the promised savings.
The workflow, not the worker
The most useful idea in the section is about the unit of analysis. Sankar said the labs' product strategy presumes "the atomic unit of the enterprise is the knowledge worker," so making every worker more productive is the return. "That's not actually true," he said: the unit is the workflow. A supply-chain analyst made more productive can generate no incremental ROI; the whole supply-chain workflow has to become measurably more productive to capture value.
He allowed an exception: roles where "the cardinality collapses," where the worker is the workflow, as in coding. There, he said, product-market fit is perfect and productivity can chase the unbounded. That is a small share of the real economy, in his telling.
An assembly line standing for redesigning a workflow around AI instead of speeding up one worker
For builders, the practical test is whether your AI project names a workflow with a measurable output (cycle time, error rate, throughput) or only a person to be assisted. It is the same logic behind our explainer on what a forward-deployed engineer does and OpenAI's own account of the deployment gap.
Why do the ambitious customers win?
This is the most quoted claim and the least verifiable. Sankar said that when he segments Palantir customers, "the ones who want to use AI to reduce headcount" and take costs out "almost all of them have failed at even achieving those goals," while those with ambition, such as "I want to use AI to dominate my market" or to do work beyond the efficient frontier, "succeeding wildly."
His explanations:
- A myopic goal like removing humans gives "insufficient stimulus to motivate you to do the hard things."
- Human and machine intelligence "aren't exactly the same." If you try to delete the human, the AI has to do everything the human does; "even if it only does 98%, you'll fail at the specific goal."
- The alternative is to build the workflow around what the AI can do rather than shoehorning it into the gap between human and AI.
He added that the effect is "very pronounced in the age of AI," with outcomes more binary than before, producing "a category of winners and a category of people who view this as something that's not quite working."
Caveats matter. This is one vendor's customer base, self-selected for Palantir's approach, with no published data. It also conveniently favors a vendor that sells workflow redesign. It is still a testable hypothesis for any team: compare projects framed as cost-out against those framed as new capability, and see which shipped.
"Who carries the burden of systems engineering?"
Sankar's third theme is aimed at the labs. A capable model, he said, is not a working system, and "lab blindness" is the idea that anything beyond the model matters. His example: a weekend article about language models communicating through timing differences in virtual machine CPU caches, which to him shows "a complete absence of a systems-engineering approach." The labs ask "can we test and find things that can go wrong," he said, instead of "what would we have to build around this so we could actually use it."
He pointed to what real companies do after incidents: publish a "Five Whys" retrospective documenting everything they will change so it cannot recur. He wants labs and users to do the same.
His historical comparison is Admiral Rickover's nuclear Navy against the Soviet fleet. In his telling, Soviet submariners were rested every six months in Sochi because radiation safety was treated as unsolvable, while Rickover designed to a standard "a hundred times more than what scientists thought was even needed." I did not verify those historical details; they are his illustration. He also cited the automobile: millions of deaths since 1899, answered by seatbelts, airbags and anti-lock brakes rather than by wringing hands.
Thompson pressed on the obvious point, whether Palantir and Microsoft benefit from framing safety as a wrapper problem. Sankar conceded "there's some self-interest there," but said he is "kind of gaslit by how little focus there is in the labs" and blamed an aesthetic in which needing anything beyond the model is a failure of the maximalist vision. He singled out Nvidia's released safety toolchains as a rare example.
This sits next to other recent debate about who owns agent safety, such as our coverage of the CSO argument that frontier labs skip security basics, and Altman's own view that sandboxing a far smarter model is an open problem, in our post on Altman's Cheeky Pint interview.
For agent teams applying the systems-engineering idea today, AgentBeam is the agent security platform from the explainx.ai team that stops AI agents before they take dangerous actions, a runtime checkpoint around the model.
The globalization aside
Early in the interview Sankar made a broader argument about industry: that "innovation is a consequence of productivity," so offshoring production cedes the stimulus for innovation, with Google's pre-transformer translation work as his example of prosaic goals leading to profound results. He also said wages adjusted for inflation have been flat since the 1971 break between GDP and wage growth, and that a thriving middle class means believing your children's future will be better. These are political-economy claims, not AI findings, and I did not check the statistics.
How to weigh the interview
- Source and incentives. Sankar is Palantir's CTO and author of a book on rebuilding the American industrial base. His commercial case rests on integration and workflow software.
- Empirical claims are anecdotal. The headcount-cutting failure rate has no published data behind it.
- The workflow framing is useful regardless. It gives a concrete project-scoping test.
- The safety critique is partly fair, partly self-serving. Labs do publish system cards and evals; whether that equals a systems-engineering culture is the point of dispute.
- Unread sections. Forward-deployed engineering and Anthropic's dispute with the US government are in the interview but not summarized here.
What builders can take from it
| Question to ask | Why |
|---|---|
| Which workflow does this project change, and how is it measured? | Sankar's unit-of-value test |
| Is the goal capability or headcount? | His observation favors capability goals |
| What is built around the model: permissions, checks, rollback? | The systems-engineering point |
| Do you run post-incident Five Whys on AI failures? | His example of mature practice |
| What does the 98% case cost? | A near-miss on full automation can still fail the goal |
Bottom line
The interview is best read as a vendor-informed argument for the integration layer: value comes from redesigning workflows, cost-cutting framings underperform, and safety is an engineering discipline rather than a model property. The ideas are testable and worth borrowing; the numbers behind them are Palantir's own observations and unpublished. For more on how he has defended his positions publicly, see our look at the Palantir CTO's claims versus the record and our post on tech and religion, which touches on the "religious war" framing in the title.
Related reading
- Palantir CTO on the OpenAI Hugging Face hack: claims vs the record
- Faith-AI Covenant: Anthropic and OpenAI consult religious leaders
- The AI verification tax and how to cut it
- What is a forward-deployed engineer
- OpenAI forward-deployed engineering and the deployment gap
- Frontier labs skip security basics, says a CSO
Quotes and claims are from the Stratechery interview as published October 29, 2026; later sections of the interview were not read.