Boards everywhere are waiting for Opus 6 and GPT-7 so they can finally switch on AI across the whole company in one go. By the time those models arrive, it will be too late. The companies that win will already have 20 agents running in production on last year's model, and the people who built them will be forward deployed engineers.
If you want the definition of the role first, start with our explainer on what a forward deployed engineer is. This post is about why your company needs them.
Everyone is waiting for the next model
Every few months a new model tops the benchmarks, and someone in the leadership team asks whether the company has adopted it yet. Behind the question sits an assumption: the next model will do it all out of the box, so anything built now is wasted effort.
For most operational work, that assumption is wrong. A model from a year or two ago can already read an invoice, match it to a purchase order, pick the right general ledger code, and draft the email to a vendor about a missing PO. The labs are racing to solve week-long coding tasks and maths research. On matching an invoice, progress went flat a while ago.
Models won't save you
When an agent gets something wrong in production, the model is rarely the cause. Daniel Kornum of Varick worked through an accounts payable example: 30,000 invoices a month, and an agent that disagreed with the team on 1,800 of them. In his breakdown, about 100 of those came down to the model, or 0.3% of invoices. The rest came from things no model could see:
- A vendor agreed a new way of invoicing by email two years ago.
- Partial deliveries and credit notes were never written into the process documentation.
- The same vendor sat in the system twice, or the goods receipt had not been entered yet.
- The real payment terms lived in one clerk's head.
His figures are a worked example, not a client result, and he describes the same pattern in deal desk quotes and onboarding packs. A newer model fixes none of it. Someone has to sit with the team, find the missing context, write down the exceptions, clean the data, and engineer all of it into the agent. That work is the same whether you run this year's model or last year's.
That someone is a forward deployed engineer
Kevin Bai has built this function more than once. He worked at Palantir, was the first forward deployed engineer at Rippling, where the team grew to about 25 in a year, and now works on Anthropic's applied AI team. His definition is short: an FDE is a customer-facing software engineer. You would hire them onto your engineering team, and you would also trust them in front of a customer.
The job is to go into the business, learn how the work actually gets done, and build the solution there. A good FDE spends the first weeks finding out where the misses come from, long before anyone argues about which model to run.
Palantir proved it pays
Palantir sold a platform, Foundry, that organised a company's data and let it build applications on top. Its buyers included oil and gas majors, whose pipelines carry hydrocarbons, not data. They could see their data was tidier. They could not see what that did for the business, and they did not have the engineers to build on it.
So Palantir stopped selling the software on its own. It sent engineers with it, and the customer bought an outcome, such as more shelf placement or faster sales. Bai describes it as the design partnership early startups use to find product-market fit, run at enterprise scale.
The numbers he gave on stage, by his own "last I checked": among public software companies selling to the Fortune 500, Palantir's average contract was about $4 million a year. ServiceNow was next at about $1.2 million, then Workday at about $600,000. He said no other public software company passed $500,000.
Why this now applies to your company
Bai's view is that AI has changed the software business itself. Nearly every platform is now agentic, so nearly every platform is customisable, so most buyers no longer know what the product actually does. If success depends on the customer working out the setup alone, the rollout stalls.
Now look at your own company. Your finance and operations teams are the non-technical buyer, and agentic AI is the technical product. That is the corner Palantir built forward deployed engineering for. Waiting for a model that makes the corner disappear will not work, because the hard part was never the model.
What makes an FDE team work
Bai warns about one failure mode above the rest. If each engineer builds every solution from scratch, you have a dev shop, and the maintenance bill grows with every workflow until it eats the budget or the engineers quit. FDEs need a platform to build on: shared building blocks, such as the data layer and the approval flow, that each new workflow reuses.
- Work specific to one team stays with that team. Anything that repeats moves into the platform.
- Put at least two engineers on each workflow so the knowledge never sits with one person.
- Pin the model version for each workflow and test new models against your own cases, not public benchmarks. Upgrade when a new model fixes real misses, or matches the score for less.
- Treat the FDEs as scouts. What they find in the field tells you what to build next.
The competitor to watch
Plenty of leaders worry about a rival getting the newest model first. The rival to worry about has 20 workflows in production on last year's model, built by engineers who sat with the teams doing the work, while everyone else is still comparing benchmarks.