No PriorsNo Priors Ep. 25 | With Palantir's CTO Shyam Sankar
CHAPTERS
- 0:00 – 2:07
Shyam Sankar’s origin story and path to Silicon Valley
Shyam shares his early life in Nigeria, his family’s experiences fleeing violence, and resettling in the U.S. He describes growing up near the space program in Florida and how that shaped his excitement about technology and ambition.
- •Early childhood in Nigeria and family background in pharmaceutical manufacturing
- •Resettling in the U.S. as refugees and the perspective it created
- •Growing up in Florida during the space shuttle era
- •Early interest in computers and eventual move toward startups
- 2:07 – 2:50
Finding Palantir: mission pull, early networks, and motivation
Shyam explains how he first heard about Palantir through personal connections around Stanford and Peter Thiel’s network. He also describes the personal and historical factors (9/11, terrorism) that made Palantir’s mission feel worth the risk.
- •Work at Xoom and indirect exposure to Peter Thiel’s network
- •Connection via Joe Lonsdale’s circle and early “secretive” Palantir awareness
- •Personal motivation shaped by 9/11 and a family experience with terrorism
- •Choosing mission importance over certainty of success
- 2:50 – 4:46
From business hire to forward-deployed engineering: Palantir’s operating model
Shyam describes how his role evolved by doing whatever was needed—from building internal tools to aggressively QA’ing product. He introduces “forward-deployed engineering” as a hybrid of engineering, product, and customer success built around working backward from real customer problems.
- •Early scrappiness: internal systems, QA, and product testing
- •Forward-deployed engineering as a core Palantir innovation
- •Hybrid roles that combine PM, engineering, and customer outcomes
- •Working backward from customer problems vs. “shipping to spec”
- 4:46 – 5:49
Why government customers forced full-stack ownership and outcome focus
The conversation connects Palantir’s early government work to the need for unusually deep ownership across the entire delivery stack. Shyam explains that in complex, constrained environments you can’t rely on surrounding infrastructure to “just work,” so accountability must extend beyond a narrow software component.
- •Government mission contexts intensify outcome accountability
- •Early-era constraints: limited cloud primitives and dependencies
- •Need to own more of the vertical stack to ensure success
- •Ambition driven by real-world consequences and complexity
- 5:49 – 8:00
Product stack overview: Gotham, Foundry, and the ontology/digital-twin layer
Shyam breaks down Gotham as the decision layer for defense/intelligence and Foundry as the general-purpose data integration platform. He emphasizes Foundry’s ontology as a semantic model of “nouns and verbs” that enables simulation, counterfactuals, and operational decision-making—not just dashboards.
- •Gotham’s role in intelligence/defense decision workflows (e.g., kill chain)
- •Foundry as structured + unstructured data integration and transformation
- •Ontology as semantic layer modeling entities and actions (digital twin)
- •Operational pixels: write-back to transactional systems, orchestration, simulation
- 8:00 – 8:54
Expanding beyond defense: data integration as the ‘boring, unsolved’ core
Palantir began in defense/intelligence and expanded to commercial use cases later—somewhat reluctantly. Shyam argues that many valuable applications presuppose integrated data, and that data integration remains widely duct-taped and unsolved, enabling Palantir’s broader footprint.
- •Defense-first origin and later commercial expansion (around 2010–2011)
- •“Sexy mission” motivating engineers to solve ‘boring’ integration
- •Productizing integration as the unlock for many downstream apps
- •Examples: vaccine distribution and supply-chain crisis response
- 8:54 – 10:44
Apollo: autonomous delivery for air-gapped and sovereign deployments
Apollo is presented as Palantir’s deployment and operations platform built for the hardest environments—air-gapped systems, submarines, and constrained upgrade windows. Shyam explains Apollo as a successor to conventional CI/CD that models environments separately, orchestrates upgrades, and handles health checks and vulnerability-driven recall/blocks.
- •Motivation: modern microservices deployed without normal connectivity/CI paths
- •Separation of software vs. environment modeling; dependency management
- •Blue/green patterns, roll-forward/back, and automated health checks
- •Managing CVEs, vulnerability posture, and multi-environment SaaS complexity
- 10:44 – 12:19
AIP: bringing LLM experiences to private data via tools, not just chat
AIP is framed as a platform to build LLM-powered applications inside private networks on private data. Shyam emphasizes that LLMs need tools and structured grounding—AIP acts like a ‘tool factory’ so models can reliably drive real workflows (inventory allocation, claims decisions) rather than producing isolated text.
- •LLM experiences on private networks and sensitive enterprise data
- •“Application forge” approach: build AI-enabled apps, not only assistants
- •Tooling as the key: LLMs are strong/weak in specific ways and need tools
- •Fast ROI: copilots embedded in existing decision surfaces
- 12:19 – 13:47
Why Palantir invested: ontology as the missing layer for reliable LLMs
Shyam describes the late-year realization that LLMs were ‘waiting for’ an ontology-like representation to deliver enterprise value. He characterizes LLMs as a stochastic system that needs grounding, and argues ontology provides compression and contextual structure without needing to change the base model.
- •Decision to invest heavily around late Q4
- •Ontology provides business grounding and context-window compression
- •LLMs behave more like probabilistic statistics than deterministic code
- •Toolchain needed to manage ‘stochastic genie’ behavior
- 13:47 – 15:28
The ‘stochastic genie’ toolchain: evals, telemetry, and use-case calibration
The discussion turns practical: to productionize LLM-backed functions you need a dev-toolchain adapted for stochastic outputs. Shyam outlines eval-driven testing, heavy observability, and selecting workflows where upside is high and failure is safely a no-op.
- •Evals vs. unit tests: repeat execution to estimate confidence
- •Production telemetry, traces, and health checks over model behavior
- •Ongoing monitoring and test-writing against real traces
- •Choosing use cases: huge upside when correct, minimal harm when wrong
- 15:28 – 18:12
From chat to application-state changes: COA generation and copilots in practice
Shyam illustrates AIP with concrete examples: defense planning that generates courses of action from doctrinal operational plans, and commercial copilots that adjudicate warranty/quality claims. The key idea is moving from chat responses to structured outputs that ‘hydrate’ application state—maps, matrices, requisitions—so users approve actions rather than read text.
- •Defense example: automated COA generation from operational plans (O-plans)
- •Doctrine-heavy domains as fertile ground for AI-assisted workflow generation
- •Chat is limiting; goal is structured state changes (maps/resources/approvals)
- •Commercial example: clustering and analyzing auto warranty claims for early signals
- 18:12 – 20:08
Models commoditize; trust comes from ensembles, structure, and UI design
Elad challenges the ‘models are commoditized’ claim, and Shyam argues Palantir’s value is in deploying models into real experiences and building trust. He suggests ensembles of models and structured outputs (JSON/DSL) make consensus and disagreement measurable, pushing UI toward statistically honest decision support.
- •Value accrues to experience-building and trust, not owning a single model
- •Ensembles of ‘mad geniuses’ vs. one-model-to-rule-them-all
- •Structured outputs (DSL/JSON) enable parsing, validation, and comparison
- •UI should reflect probabilistic uncertainty and divergence thoughtfully
- 20:08 – 27:55
Future UI and integration: intent + app state, LLM-driven integration, and fewer screens
Shyam describes an interface future where user intent plus application state yields a new application state—often mediated by structured outputs rather than text. He argues LLMs will change systems integration by making API selection/parameterization easier, enabling true ‘single panes of glass’ and dramatically reducing the UI work that used to dominate feature development.
- •Core UI concept: intent + current state → new application state
- •Structured prompts returning DSL/JSON that manipulates the app
- •LLMs as integration accelerators (API calling and composition)
- •Reducing UI build cost by replacing complex interfaces with language
- 27:55 – 30:37
Operationalizing ‘agents’ with enterprise state machines and safe automation
Shyam pushes back on vague ‘agent’ narratives, arguing enterprises already have implicit/explicit state machines with real guardrails. He proposes starting with narrow authority over single transitions, building human-agent teams, and expanding automation incrementally—more like Tesla’s approach than all-or-nothing autonomy.
- •Agent skepticism: planning exoticism doesn’t match enterprise reality
- •Enterprises as state machines; agents need explicit authorities/guardrails
- •Start small: one state transition, then link transitions over time
- •Human-agent teaming as change-management and trust-building mechanism
- 30:37 – 39:45
Scaling adoption: internal dogfooding, multi-model exposure, and healthcare workflows
Shyam explains Palantir’s internal push to adopt LLMs to solve its own operational pain (e.g., incident response), building intuition about failure modes. He then discusses healthcare as a major business segment and distinguishes operational copilots (alerts to solutions) from clinical copilots (reducing documentation and workflow toil), tying both to staged scenarios and human approvals.
- •Internal mandate to experiment and ‘dogfood’ copilots for productivity
- •Working with multiple models (not just GPT-4) and comparing outputs/latency/tokens
- •Healthcare split: operational capacity/supply-demand vs. clinical toil reduction
- •Pattern shift: alert inbox → recommended solutions with staged edits and approval
