Forward Deployed Engineering Is Discovery, Not Delivery

Summary

Forward deployed engineering has become the default answer to almost every hard question in AI go-to-market. Job postings for the title are up several hundred percent, and every seed-stage AI startup now has one open. What's strange is that this was, until recently, a thing you got criticized for — a sign you didn't have a real product with real margins. Nothing about the underlying economics has changed. What changed is the nature of what's being deployed.

The reason FDEs are proliferating at a scale never seen before is simple: AI is fundamentally about adding a non-deterministic, rapidly changing system to workflows that have largely never been automated before. That looks very little like implementing traditional software.

The shift

Traditional software is deterministic. Once implemented, it works the same way for every customer. Implementation was relatively uniform across similar organizations, and the system wasn't regularly upgraded in fundamental ways. You installed, configured, integrated, and trained. Then it ran.

AI agents are different on nearly every dimension:

• The customer's business process has to change to work with agents. The workflow itself is being invented, not automated.
• Heavy customization is necessary. Agents must be adapted to the customer's end-state process, not the other way around.
• Evals must be run constantly. There is no standard certification suite. Each deployment invents its own.
• The models themselves are changing. Updates need continuous incorporation — this is not a go-live event.
• The harness and broader system evolve from customer feedback. The product and the deployment co-evolve.

"If you're building an AI agent for accounting in 2026, there is no established workflow, because literally nobody has ever used one of these. Nobody knows what the user journey looks like — not you, and not your customer either."

As AI capabilities improve, this work does not disappear. Enterprises respond by throwing increasingly complex processes at agents. The last mile is irreducible — it just shifts to higher-value work.

This is real work for customers, systems integrators, and applied AI vendors alike. Great time to be an FDE.

The discovery mechanism

The original argument for forward deployed engineers was never about service revenue. It was about discovery. FDEs eat pain and excrete product. The pain customers experience in the field is input to the platform. Every bespoke deployment yields primitives that make the next one easier.

That's the pattern: FDEs absorb unstructured customer reality and return product primitives. Pain goes in. Product comes out.

Palantir demonstrated this pattern at scale. In the mid-2000s, deploying Gotham into the CIA and Army intelligence units meant deeply bespoke work — building to answer one intelligence question for one unit. For most of two decades, the mainstream view was that Palantir was a glorified consultancy rather than a real technology company. That view was based on a true observation: a lot of their engineers spent a lot of time sitting with customers.

But Palantir encoded the problems they saw as platform primitives — the ontology, object models, permissioning, workflow engines, provenance tracking. Those primitives became Foundry. Foundry became the thing you could sell commercially. Apollo and AIP followed the same path. None of that would have existed without engineers eating pain in the field first. The pain was the input to the product, not a cost of sale.

As Foundry matured, standardized deployments dramatically reduced the need for custom work. Gross margins climbed into the 80s, and Palantir shifted from an FDE-led motion toward account-based selling. Many of those FDEs migrated into core engineering. They also famously turned down contracts where the customer just wanted Accenture with better software. The FDE team wasn't the business model. It was the way to build the right product.

The trap

Keeping FDEs in the field after the discovery phase is complete lets you avoid every hard product decision. You never have to choose which customer request wins, where the configuration surface ends, or what the product actually does. Nobody has to say no. The customer is delighted. It feels free.

But it isn't free. It means cost to serve never declines, margins stay capped, growth is bounded by hiring, and the product atrophies. The test is simple: do your FDEs eat pain and excrete product, or do they eat pain and excrete more pain? If every deployment is as expensive as the last one, you're not discovering. You're absorbing.

Some companies choose a deliberately different path. Instead of an FDE-led motion, they commit to a product-driven approach — owning the build while giving the customer the keys. The tradeoffs are real: it means not hacking something together in the field when that would be faster, and turning escalations into requirements instead of patches. But when it works, the payoff compounds. Two-thirds of deployment work may become autonomous. Launches shrink from months to days, even for the largest organizations.

The choice comes down to a single question: is the last mile irreducible, or just unbuilt?

Why it matters

FDEs are real and not going away for AI any time soon. The structural reasons — non-deterministic systems, invented workflows, continuous model evolution — are durable. But the distinction between FDE as discovery mechanism and FDE as delivery crutch is the difference between building a product company and building a services business.

The best companies will use the FDE phase to discover what needs to exist in the product, then build it. The rest will confuse a growing headcount of field engineers with product-market fit.

What to do

• Go forward-deployed early. The workflow doesn't exist yet. You need to be in the room.
• After every deployment, ask: what product primitives came out of this? If the answer is none, you're in delivery mode.
• Pull FDEs out once the user journeys are known. This will be uncomfortable because keeping them is easier in every sprint.
• Plan for permanent FDE presence in AI — but seasonal, not structural. As models improve and agents take on more complex work, FDEs shift to harder problems rather than disappearing.
• Distinguish FDE from implementation. Building an integration into a customer's ticketing system is real, necessary work, but it's execution against a known spec — not discovery of an unknown one. Bundling the two under one title is how companies convince themselves a growing services org is a product investment.
• Watch for the signal that models thin the implementation layer. What required an FDE last year may be a product feature this year. Don't let headcount lag the architecture.
• Ask yourself honestly: are your FDEs discovering something, or absorbing something? And what got built into the product the last time one of them came back? FDEs eat pain and excrete product. If yours are eating pain and excreting more pain, you don't have an FDE team. You have a services business.