The FDE Playbook for AI Startups with Bob McGrew

We’re thrilled to be joined by Bob McGrew—early PayPal engineer, early Palantir exec, and former Chief Research Officer at OpenAI, where I helped lead ChatGPT, GPT‑4, and the O‑one reasoning model. Bob’s now exploring the future of AI and has an exciting new role with the U.S. Army we’ll get to. Bob, thanks for being here.

I’ve been eager to talk about the Forward Deployed Engineer model. It’s become the way AI agent startups organize. You were there when it started at Palantir. First, what is an FDE and why is it relevant now?

A Forward Deployed Engineer is a technical person embedded with the customer to bridge the gap between what our product does and what they actually need. At Palantir we learned this the hard way. We demoed to intel users, got told it was wrong, asked how to change it, and iterated. Unlike classic product‑market fit where you “find the one thing” then scale from a distance, our customers needed slightly different things. Shyam Sankar flipped the script: build a platform that can be customized on site. FDEs lay a gravel road to the outcome; the product team sees patterns and paves a highway that generalizes to the next five and ten customers.

Why engineers doing discovery instead of sales? Especially in defense, most would hire a seasoned government salesperson.

We tried that. It rarely meshed with our culture or succeeded. Sales‑led discovery tends to start near the product and stay superficial. FDE‑led discovery solves from the inside on one of the CEO’s top priorities, lands real value, then expands to bigger, sometimes non‑obvious problems once you see what’s actually possible.

Give us the playbook. How did the FDE model run inside Palantir?

Two core roles: Echo and Delta. Echo were embedded analysts and account owners who hunted the highest‑impact use case and made sure it mattered to leadership. Delta were deployed engineers—pain‑eaters who prototype fast, ship something that really works, and deploy. We’d set a near‑term leadership demo, prove progress, and, if it landed, roll out organization‑wide.

How did you hire for Echo and Delta? These aren’t typical roles.

Echo: deep domain plus heretic streak—people who know how it’s done and why that’s not good enough. Delta: rapid prototypers, not craftspeople obsessing over twelve‑year abstractions. Former founders often excel—each site feels like founding with real product leverage behind you.

Critics say this is just consulting with better branding. Why is that wrong?

It can devolve into consulting if you let it. The tell is unit economics over time. Early margins may be negative. As product generalizes and you earn the right to tackle bigger problems, cost per unit value drops and margins turn positive. That repeatable improvement is software, not pure services.

Where does product fit, and how did you avoid over‑specializing to one customer?

Product holds the vision: recognize the general problem hiding inside a bespoke request. A classic example was Palantir’s ontology. Instead of hard‑coding tables for “people,” “money,” and so on, we built a base that lets each deployment define objects and relationships. Hiring PMs who can think at that level of abstraction is hard. We’d bring FDEs from multiple customers into design to see three variations at once and converge on the right generalization.

Did that create tension between field teams who want speed and product teams who want clean abstractions?

Constantly—and that’s healthy. The field should hack the fastest gravel road. Product should pave the right highway across many customers. We’d mediate by putting multiple FDEs in the same room with product, mapping real workflows, and designing the shared solution together.

How do you stop it from drifting into pure build‑to‑spec consulting?

Aim at top‑five CEO priorities, not convenient asks from a mid‑level sponsor. You’re selling outcomes, not installation. If it’s not step‑function impact, do not do it.

Why is the FDE model suddenly everywhere with AI agent startups? Did that surprise you?

It did. My first advice was, do not do this unless you must. Palantir needed it because our market was many segments with heterogeneous workflows. AI agents face the same thing: there is no incumbent product and the category itself is new. You only discover the right thing from inside the enterprise. It’s doing things that do not scale—at scale.

Pricing is different if you sell outcomes. How should AI founders price, and how do you get enterprises to yes?

Expect larger, flexible contracts that ramp with value delivered—more like, we will own X outcome, and as volume and reliability grow, price scales. Early on, take on more risk because big enterprises assume nothing works. If any part is on‑prem, prepare to fight IT and policy. You need executive sponsorship on a top‑five priority to grant authority to operate, carve exceptions, and unblock integrations.

How long can you keep doing high‑touch work before you must abstract into product? What should we measure?

In classic PMF, you hold contract size steady and drive down effort. In FDE, you drive contract size up by delivering more valuable outcomes for this and future customers. Measure two things: one, value of outcomes you’re delivering, even if you cannot fully capture it yet; two, product leverage for FDEs—each subsequent deployment of the same outcome should take less effort, and your platform abstractions should unlock wholly new use cases. The FDE is also a core customer: build leverage for them. It is painful and judgment heavy. Sometimes you must push a hard product change top‑down; more often, the field is right and you have to earn adoption.

Engineers often resist demo‑driven development. Does it actually work here?

It works great if the product warrants it. We had one canonical demo—stopping a plot. Every new feature had to make that flow better and create desire. That forces end‑to‑end thinking, smoother transitions, and reveals user pain early, instead of after deployment.

This all sounds like gradient ascent in a huge space—so you need a learning company.

Exactly. Build a young, learning organization where success is not yet guaranteed. That pressure creates founders. Palantir produced many because even at scale it stayed in learning mode—lots of pain, constant discovery.

You’ve joined the U.S. Army Reserve. What are you doing there, and what applies from the FDE playbook?

I joined Detachment Two‑Zero‑One as a lieutenant colonel; these are my views, not the Army’s. We are officers advising on technology, with skin in the game—oath, training, fitness test and all. Army leadership knows it must transform from counterinsurgency to large‑scale, modern combat. They set clear priorities and gave us freedom to work problems on the ground and escalate when needed. It feels like running FDE inside the Army: align to top priorities, close the gap between leadership intent and legacy implementation, and help the organization move faster.

Where are the best opportunities for founders right now?

Capabilities are racing ahead—look at the jump from GPT‑four‑O in April twenty‑twenty‑four to O‑three in April twenty‑twenty‑five—yet adoption lags. The next five years will feel weirdly banal as capability outpaces integration. Massive opportunity sits in that gap: turn raw capability into reliable, adopted workflows. That takes human ingenuity and, yes, a lot of pain.

Feels like OpenAI is the home product team and startups are the FDEs driving adoption out in the field.

That’s a pretty good analogy—and it explains why the FDE model is back in force.

That’s all for today. Bob, thanks for joining us—super insightful. We’ll see you all next time.