Palantir DevCon 5: The 5 Launches That Actually Matter

Palantir held DevCon 5 in March 2026. Several sessions, a range of product launches, and some genuinely interesting demos.

We watched all of it and distilled what matters.

Here are our five key takeaways — and what each one means if you're building on the Foundry stack.

1. AI FDE — The Agent That Builds Agents

The Agentic Forward Deployed Engineer (AI FDE) went from "useful assistant" to something closer to an engineering teammate. The developer still oversees everything, but the manual work shifts dramatically.

AI FDE now runs a full eval-driven development loop: it reads your ontology, explores your data, writes AIP Logic functions, generates evaluation suites, runs them, identifies failures, debugs, and iterates. The developer watches, steers, and approves — but doesn't build from scratch anymore.

The capabilities worth knowing about:

• Exploration — Queries the ontology, reads regulatory docs, finds data patterns automatically
• Logic Creation — Builds AIP Logic functions with ontology context baked in
• Eval-Driven Development — Writes test suites, runs them, debugs failures, iterates until passing
• Feedback Ingestion — Reads user corrections from the ontology, synthesizes them into new test cases, and self-improves

In the demo, the team started with no logic function — just raw data and a manual process. They dragged the workflow into AI FDE. It built an agent, wrote evals (90% failing), debugged and refined, and got to 90% passing. Then they pointed it at real user feedback from production and it improved again.

The part that stuck with us: AI FDE then built a secondary agent whose job is to ask users clarifying questions — essentially teaching humans to give better feedback. Each feedback cycle improves the agent, which improves the feedback quality, which improves the next iteration.

2. Orchestrator — Workflows That Wait for Weeks

Most agent frameworks assume conversations last minutes. Enterprise processes don't work that way — insurance claims, procurement approvals, compliance reviews all involve waiting for humans, emails, and external systems. Sometimes for weeks.

Orchestrator is a new durable execution runtime built on the ontology, and it handles four things that matter:

• Await Conditions — Execution suspends until an ontology condition is met. No polling. No Kafka queues. Just await objectCondition().
• Cost-Efficient — Auto-shutdown after 5 minutes idle. While waiting for a human to upload a document, it costs nothing.
• Durable State — Checkpointed to the ontology. If anything fails, the workflow resumes where it left off. No restart.
• Agent Teaming — One agent's ontology writes trigger another agent's await condition. Coordination through structured data, not chat.

The demo walked through a medical payer pre-authorization workflow: the agent evaluates insurance criteria, realizes a document is missing, requests it from a human, and pauses. Compute scales to zero. Three days later the human uploads the document. The agent picks up exactly where it stopped, evaluates, drafts a letter to the insurance company, and waits for a reply.

No state machines. No message queues. One durable execution replaces an entire integration stack.

3. Hivemind — Agent Swarms That Plan and Execute

Hivemind takes a different approach from AI FDE and Orchestrator. Where those handle building and running, Hivemind focuses on strategic planning — and connects the output directly to execution.

It works in stages:

1. Problem Framing — Requirements, constraints, and risks get identified
2. Idea Generation — Multiple specialist agents create solution proposals in parallel
3. Critique Teams — Dynamically generated "skeptic" agents challenge each proposal and force refinement (v1 → v2 → v3)
4. Plan Compilation — The refined plan compiles into the ontology with phases, objectives, and timelines
5. Execution Handoff — Auto-generates coding tasks for AI FDE to build

The interesting design choice: none of these agents are pre-built templates. Hivemind generates them on the fly with custom prompts tailored to the specific problem. The agents can also write and run code in a secure sandbox for quantitative analysis.

Everything gets written to the ontology — fully traceable, auditable, and available for future runs. Commander feedback is stored and injected into subsequent planning cycles, so the system gets sharper over time.

Plans compile into the ontology for real-world execution. They don't end up as a PDF on someone's desktop.

4. Ontology Transactions — Read-After-Write, Finally

This is the least exciting-sounding announcement and probably the one developers will appreciate most.

Before this update, ontology functions couldn't read their own uncommitted edits within the same execution. Create an object and immediately query it? Nothing back. This forced everyone into awkward workarounds — batching all edits and returning them at the end of a function.

Ontology Transactions introduce a Writeable Client with full read-after-write consistency:

• Read-After-Write — Query the ontology mid-function and see your own uncommitted edits
• Writeable Client — Create, update, and delete objects inline
• Multi-Action Composition — Combine creates, updates, and AIP Logic calls in one atomic function
• Atomic Rollback — If the function throws, every edit reverts cleanly

Any function that needs to create something, query it, enrich it, and then create something else referencing it — that's now a single clean function instead of a chain of workarounds.

5. Foundry CLI — Local-First Development

Palantir rethought the developer experience. The new Foundry CLI gives you a local-first setup that runs entirely on your laptop:

• One Command — create-repo generates a full project (ontology + Python/TypeScript functions + React/Vite app) in 8 seconds
• Embedded Ontology — Runs locally. No Foundry connection needed for development
• Hot Reloading — Changes to ontology, functions, or app reflected instantly
• Type-Safe Propagation — Schema changes trigger SDK regeneration. TypeScript catches breaks immediately

The demo flow was simple: create-repo, wait 8 seconds, get a running project. Change a function — auto-recompile, app updates. Delete an ontology property — the SDK regenerates, TypeScript shows squiggly lines in your React code. You can deploy with confidence because the type system caught breaking changes locally.

For teams scaling their Foundry implementation, this cuts setup-to-shipping time from days to minutes.

Tying It Together

The teams that wire these together first will compound faster than the ones that adopt them individually.

We've been building on Palantir Foundry since day one. If you want to see what "weeks not quarters" looks like on the DevCon 5 stack — let's talk.