Palantir's 13th Employee: The Model Is a Stochastic Genie. Ontology Is the Stake That Tethers It

Palantir has spent two decades building a data-driven application platform that governments, militaries, and some of the world's largest companies use for analytics and operational decisions. On this episode of *No Priors*, Sarah Guo and Elad Gil talk with Shyam Sankar, the company's CTO, first business hire, and the person who built its famous forward deployed engineering force. He has been at Palantir for nearly twenty years, previously as COO, and says he has never been more excited about the work than he is now, with the new AIP platform.

The first three years of his life were in Nigeria, where his father built the continent's first pharmaceutical manufacturing plant; until then, the drugs were imported. The family fled violence and resettled in the United States as refugees, which left him, he says, with a lasting sense of the counterfactual. He grew up in Florida in a moment when the whole school filed into the courtyard to watch a shuttle launch, and Saturday mornings at 6 a.m. could begin with double sonic booms. He is still waiting for commercial space to bring that age back. In 2003 he reached Silicon Valley and joined Xoom, the international money-transfer company founded by Kevin Hartz, with Peter Thiel as a seed investor.

After three years he joined Palantir as the 13th employee, the first person on the business side. The company was small and secretive; he heard about it because Thiel had also invested in Xoom, and a friend had been Joe Lonsdale's freshman roommate at Stanford. The pull was personal. His uncle was a victim of terrorism, and he himself was in New York on September 11. "I would rather fail on working on a problem this important than do anything else."

The common thread in his roles, he says, is doing what needs doing. Before there was a product, the first business hire wrote a candidate-management system and served as an aggressive QA tester. The contribution that stuck was forward deployed engineering. It came from an observation CEO Alex Karp liked to make: maybe French restaurants are good because the wait staff is part of the kitchen, with real context on the food. Palantir's version is that the people in the field with customers should be computer scientists who know what the product does today, what it needs to do, and under what conditions it will work. The hybrid role is product management, customer success, and engineering in one person. That is the team Sankar first built.

The method forces you to work backwards from the customer's problem instead of forwards from the technology. The accountability question is blunt: did I make this customer's life better today, and can I do better tomorrow? Specs and yesterday's ambition do not count. Government work is motivational in its own right, he says; you try to walk as many miles in their shoes as possible, and the job is defined by how they are doing. There is also a harder calculation. Early on, delivering an outcome depended on an entire stack going right, and AWS did not exist yet. If you only built your slice of software, anything underneath could kill the delivery. A company that wanted to survive had to be ambitious about what it would own.

Before AIP, Palantir had three platforms. Gotham is the flagship government product for intelligence and defense, integrating and modeling data to drive enterprise decisions. In defense that means the kill chain: how you go from targets to effects on those targets. Intelligence has a different structure, tracking and gaining context on the things in the world you are responsible for understanding. Conceptually Gotham sits high in the stack and depends on Foundry, the general-purpose data-integration platform. Foundry handles structured and unstructured data, treats data like code, and drives it into an ontology: a semantic layer that models not only the nouns of the enterprise, the concepts, but the verbs, the actions.

The buzzword is digital twin, which Sankar treats as a conceptual model of the business that can actually change decisions, not a dashboard that only offers visibility. If you want to allocate inventory, the platform has to write back to SAP, read and write the transactional systems, and orchestrate the enterprise. Foundry lets customers squint at the company as a web of decisions and ask counterfactuals: what happens if I do this? The same platform ran COVID vaccine distribution in the United States and the United Kingdom, and it is what commercial companies used when supply-chain equilibrium vanished and modeling the alternatives became crucial.

The company was founded to serve intelligence and defense, and it expanded almost reluctantly; the first commercial customer arrived around 2010 or 2011. "It took something as sexy as James Bond," Sankar says, "to motivate engineers to work on a problem as boring as data integration." The popular view is that integration is boring and solved. His view is that it is boring and highly unsolved, and that people are duct-taping it together wherever they go. Productizing that problem is what opened the market.

Apollo was built first for Palantir itself. Customers sit in air-gapped environments; there is no CI/CD path you can see to the target. The software is 550 microservices, each releasing multiple times a day, and they must upgrade independently. A submarine only wants to upgrade on certain windows; some networks are not on the internet. Apollo is what they call a successor to CI/CD: autonomous software delivery and deployment. You model the software and the environments separately, then hand dependencies to Apollo for blue-green patterns, health checks, roll-forward and roll-back, and CVE-driven recalls or blocks. The same system now matters for sovereign SaaS in Europe and for SaaS vendors asked to deploy inside a thousand customer VPCs.

AIP is a core set of technologies for bringing LLM-powered experiences onto a private network and private data. Sankar calls it an application forge. Large language models need tools, not merely plugins: customers need a tool factory, because the model will not know orbital simulation, weaponeering, or a 30-day inventory forecast on its own, and with the right tool it can do those things well. Foundry's groundwork is why customers can stand up copilots inside existing decision surfaces, allocating inventory or adjudicating auto claims, in weeks. The company decided to make a serious LLM bet in the fourth quarter of 2022. What excited them was not the models in isolation. It felt as if the models had been waiting for ontology. Twenty years of thinking about dynamic ontologies, why they matter to humans, had produced a semantic layer that compresses an enormous amount of information into the context window and makes LLM-backed functions reliable.

Engineers, he says, keep modeling the systems like calculus. When it works it is magic; when it does not, it falls off a cliff. The honest posture is to admit you have a stochastic genie and to build a toolchain that presupposes that. Evals replace the unit-test instinct: how many times does an LLM-backed function need to run before you trust it? Telemetry and production traces matter, including unit tests against traces as a health check. Use cases need calibration. The best ones are those where the model getting it right is massive upside and getting it wrong is a no-op. Ontology is one of the things that grounds the genie in the business's reality without having to change the model itself.

Guo had just been listening to an AIP demo day. Palantir's view is that the models themselves are increasingly commoditized and available in open source. Sankar's picture is slightly deranged mad geniuses: you would not ask only one expert, and you want a configuration of them. Gil says he wants an ensemble of mad geniuses; Sankar agrees, and adds that model companies will have a hard time here because they need one model to rule them all. Enterprises making high-consequence decisions need integration. If the output is chat, you can still look for agreement and disagreement. If the output is JSON or a DSL, you can parse consensus and divergence in a structured way, which is treating the system as statistics, and the UI has to be designed that way too. That morning he had watched a copilot for a major automaker clustering warranty-claim text, tracing supplier subcomponents, and looking for early signs of recalls, to drive down the cost of quality.

The example he walks through is in Hawaii: automated course-of-action generation from a Department of Defense O-plan. Those documents are full of doctrine, phases of a potential conflict, key risks and assumptions. One mission is a non-combatant evacuation, how to get civilians out of a city if conflict starts. The plan already specifies resource types, phases, timing, risks. The user does not want a paragraph back. They type something like "generate a course of action for this evacuation," and what they get is a map with resourcing, a resource matrix, and the requisition of the necessary resources. They hit a button, say yes, and the plan comes to life.

That is the interaction he wants. Chat, he argues, is a massively limiting interface; at the limit, prompts are for developers. He admits the world is messier: prompts leak to users, users sometimes want to chat, and many people start there because of ChatGPT. The ideal is an application state plus a user intent, merged into a new application state. The return should be JSON or a DSL that manipulates the app, not an answer in prose. Pushed to the extreme, he asks why have a UI at all. If the data APIs and the ontology are well modeled, the LLM can generate a lot of the end-user experience. After a hack months earlier, an engineer built in a couple of hours a feature that had been scoped at two months and two people, simply because so much of the work was UI. Replace the UI with language and the equation changes. Every team, he suggests, should ask which interfaces they no longer have to build.

Guo points at the moat around SAP, Workday, and similar systems: six months of implementation and integration. Sankar adds two observations. Berkeley's Gorilla paper showed that a fine-tuned LLM can reliably say which API to call with which parameters, which implies that system integration, and a true single pane of glass, become newly feasible. And a note he had just seen, perhaps dramatized, had Boeing and the Navy fighting over data rights on the F-18 Hornet. Imagine a world where the government holds an F-18 production-design LLM, delivered with the first aircraft, so maintenance, swapping a component, and reintegration, knowledge that used to live in scarce experts, become queryable. The enterprise analog is swapping out Workday: what breaks, what does it touch, how do you do it. That, he thinks, gets a lot easier.

The technical problem he wants to invest in is conceptual: remember that it is a stochastic genie. That means a robust eval IDE, copilots on probation, and a way for users to develop trust. He is less interested in the canonical data scientist fine-tuning a model, or even in developers as the only persona. He wants the head of maintenance at an institution, someone who knows the work, does not need every knob exposed, and can get a whole team to generate Q&A pairs. The building blocks exist; the unsolved work is a smooth, trustworthy workflow for putting a copilot into production that affects users' lives, with more defensibility than traditional code requires. Palantir has to do the education in the product and with customers. Internally, engineers get their hands around the genie by playing with it. Many customers cannot see past chatbots, and the most sophisticated ones are scared of trusting textual output on high-consequence decisions. The reframe is that the model should manipulate the application layer, inside the customer's state machine, and that the outputs can be validated there.

He almost cannot use the word "agent," because the connotation has become that the agent must invent its own plan, with planning as the exotic feature. An enterprise already has an implicit or explicit state machine. An agent that just comes up with a plan will not meet reality. An agent that has context on part of the state machine, knows its authorities and the guardrails on which states it may touch, and starts with authority over one state transition, that can be chained into real automation. Each transition already has a human owner, so human-agent teams appear naturally, and individual contributors get promoted into managers of agents. That is safe from a change-management perspective, it generates the logs you need to trust the system, and it is closer to Tesla adding a little more self-driving every day than to Cruise's all-or-nothing bet.

Getting engineers the feel for the technology became an organizational mandate, Sankar's push and, he says, an obvious consequence of forward-deployed culture: dogfood everything; if it does not work for us, why would it work for anyone else. They built a copilot for their own incident-response process. They also cannot count on GPT-4 in classified environments, so the internal ChatGPT is not one model. It runs several at once. Engineers compare outputs, latency, and token counts, and inductively map what each model is good for.

CEO Alex Karp has said Palantir is aiming for the entire market share of AI. Sankar's gloss is that the pre-work is done: protect the data, bring LLMs onto private networks, deploy them operationally. He remembers the last cycle, when everyone had a data innovation lab; they are now calling it a generative AI innovation lab, and the structure is the same. His advice is that the use cases have not changed. Last year's most important business problems are still this year's. Put the new technology on those problems, on the digital twin and the decision web you already invested in. No decision is independent; upstream choices constrain what can happen downstream. Connecting those decisions actually simplifies what you ask the LLM to solve, and you can deploy incrementally, which is the compounding loop. Value, he thinks, will accrete to whoever owns the application layer. Palantir intends to go after that hard.

Healthcare is roughly a third of the business and one of the fastest-growing parts, spanning the NHS in the UK, multiple U.S. hospital systems, and a ten-year partnership with Cleveland Clinic. Sankar splits it into operations and clinical care, which will adopt at different speeds. Operations looks like running any institution: supply, demand, labor. The archetypal pattern across industries is an alert inbox. The state machine throws exceptions, humans drown, they prioritize, they deal with what they can. AIP's promise is to surface solutions instead of alerts: a recommendation and a staged scenario, like a Git branch of edits, that a human can approve or reject. Without that scenario primitive, every customer has to rebuild it. On the clinical side he does not want the LLM deciding what to do for the patient. That is the doctor's domain. The goal is toil, the records and workflows nurses and doctors cannot get to, turned into something that takes maybe 400 milliseconds, so the picture at the point of care is more complete.

He draws a dichotomy between operational and analytical workflows. In claims processing, the operational move is a recommended action a human can evaluate. A manager looking down at the same machine asks a different question: what is wrong with my state machine, where is the cycle, with no magic button to press. The sort function changes. Today you ask whether an alert is worth a human's time. If the LLM can process every alert into a staged set of actions, you prioritize not on the severity of the alert but on the possible consequences of the solution, and you are much more likely to get through the queue.