The Forward Deployed Engineer Playbook

Job postings for one AI role are up 729% in a year. AWS put a billion dollars into building a department for it. OpenAI's internal team for it grew from two people to thirty-nine in twelve months.

The role is called forward deployed engineer. Most people have never heard of it, because the job isn't to build AI. It's to figure out which parts of a business AI should even touch.

That distinction is the whole game. MIT looked at 300 AI projects last year. Ninety-five percent produced no measurable return. Not because the models were bad. Because nobody examined the process before bolting AI onto it.

Here's the compressed version of how the FDE teams at OpenAI, Anthropic, and Palantir actually do this work, plus how to run the same playbook yourself.

Every task has three possible owners, and mixing them up is the whole failure mode

Any process breaks into three kinds of steps: work a fixed rule can handle, work that needs a person's judgment, and work a model can judge instead. The FDE's actual skill is sorting which step belongs to which owner, not prompting.

Get the sort wrong and it looks fine right up until it doesn't. One company put an agent on refund requests. It read each ticket, checked it against policy, rejected the ones that failed. Technically correct, every time. Weeks later the company was losing customers it had kept for years. The FDE sat with the person who used to do the job and found an unwritten rule: if a purchase was on a company card, approve it without further review, because those accounts spend monthly and a fight over one refund costs the relationship. Nobody had ever written that down. It just lived in one person's head.

That check became a fixed rule ahead of the model, not a training example for it. Undocumented judgment calls are the most common thing AI systems miss, because the people who make them don't think of it as a decision. It's just how the job's done.

People can't tell you what they need. Watch them work instead.

Ask someone to describe their job and they'll describe the version they've already imagined, not the one they actually run. This is why interviews are a weak way to scope an AI project.

Palantir lost a year to this. A migration to a new file format stalled because one engineer insisted the new format was worse, and nobody could figure out why, until someone watched her work instead of asking her. She checked data quality by double-clicking files open, and the new format had nothing to double-click. The fix wasn't a policy memo. It was building her a way to open the new files the same way she'd always opened the old ones. She approved the migration two days later.

Automate volume, not the impressive-looking task

The temptation is to point AI at the hardest, most interesting problem in the business. That's backwards. The right target is whatever a person does fifty or a hundred times a day, because automating something done once saves nobody anything.

A business's support history already contains this answer. Hand it to a model and it'll tell you where the repetition lives. OpenAI did exactly this at one of the world's largest banks, going after a single task thousands of advisors handled daily. Ninety-eight percent of those advisors ended up using what got built.

Build on top of what already exists. Don't ask anyone to migrate.

An agent is only as useful as the systems it can reach. If a team runs everything through Notion, the answer isn't a new system with Notion's data copied over. It's connecting the agent to Notion directly and leaving everyone's workflow alone.

This matters more with AI than it ever did with regular software, because the resistance to migration is real and expensive. One of Vasumaan Moza's clients had spent five million dollars and five years getting onto their finance system. Moving off it was never on the table. The entire project became getting everything else in the business to talk to that system instead.

Keep the number of steps. Change what happens inside them.

If someone's run an eleven-step process for years and you hand them a one-step version, they'll quietly stop using it. Not because the new version is wrong, but because the old one let them check their own work as they went, and the new one asks them to trust an answer that appeared from nowhere.

The fix is counterintuitive if you're optimizing for elegance: leave the steps visible. Let the model do the work inside each one, but don't collapse eleven steps into one. People need to see the process they already trust, even after you've replaced what's happening underneath it.

Trust is the expensive part, and it isn't optional

At that same bank, the technical build took six to eight weeks. Getting advisors to actually rely on it took another four months of pilots. That ratio isn't a rounding error. It's roughly the real cost structure of this work: building is fast, trust is slow, and skipping the second part is why pilots die quietly instead of failing loudly.

If a process has run the same way for a year, changing it has to earn its way in, whether you're rolling it out to five people or five thousand.

Design for the thousand ways it fails, not the one way it works

A model gives a slightly different answer every time, even to the same question. Testing it five times and calling it done will miss exactly the failures that matter, because those are the rare ones.

The actual method: pull real examples from the process where the right answer is already known, run the system against all of them, count what it gets wrong, then fix those specific misses. Duller than building the thing in the first place. Probably why it gets skipped.

If you can't put a dollar figure on it, it didn't happen

Cursor once had a customer complain that an agent was costing him two thousand dollars a day. The agent's job was picking which engineer to dispatch to fix broken equipment. When Cursor asked what it cost him to send the wrong engineer, the answer was higher than two thousand a day. He'd only ever looked at the cost column, never the column it was replacing.

Every deployment needs a number attached: money brought in, cost taken out, or risk made smaller. Nothing else counts as a result, no matter how smooth the demo looks.

Run this yourself in one afternoon

You don't need a title to run this playbook. Sit next to whoever does the most repetitive job at a business you can walk into, for one hour, and write down every step in the order it actually happens. Ask why each step exists. If nobody has a real answer, that step is probably a workaround someone invented years ago and never wrote down.

Then sort every step through the three lanes above, fixed rule, human judgment, model judgment, weighted by what it costs to get wrong. What comes out the other end is called an audit, and businesses genuinely pay for it. Vasumaan Moza starts every project he runs with one, before a single line of anything gets built.

A caveat on the numbers

Take the 729% figure with a pinch of salt. Job-posting growth off a near-zero base looks explosive by definition. And "no measurable return" in the MIT study depends entirely on how each company chose to measure return in the first place. The mechanism this piece describes holds regardless of the exact multiplier: process before tooling, judgment sorted by lane, trust budgeted separately from building. Treat the pattern as something that usually applies, not a law that always does.

What actually changed

None of this is new advice. Watch the work, sort the steps, keep the shape people trust, prove it in dollars. What changed is that AI made the cost of skipping these steps show up fast enough for companies to notice, and made the payoff for doing them properly show up just as fast.

The job title is new. The job itself is just paying attention before you build anything.

---

Source: "They Just Taught How To Become A Forward Deployed Engineer". Figures and stories drawn from talks AI Labs compiled from OpenAI, Anthropic, Palantir, and Vasumaan Moza.