The phrase "forward-deployed engineer" is having a moment because Palantir and OpenAI use it in job ads. The pattern itself is older than either company. It's a field engineer who sits inside the customer's building until the system actually works. Not until it ships, until it works. The thing that's new is that AI products created enough integration mess to make this role obviously necessary again.
I've spent the last year doing this work, sometimes labeled this way, sometimes labeled something else. Here's what I've learned about the shape of the job.
The role, plainly stated
You take a piece of software that works in a demo and you make it work in the customer's actual environment, against their actual data, with their actual constraints. You don't write a spec and throw it over the wall. You sit at their table. You watch their workflow. You break things in their staging environment. You fix them. You leave when the product is loaded into someone's daily routine, not when the contract closes.
The traditional definitions split this into three jobs: solutions engineer, customer success, and integration consultant. In practice, those splits exist for billing reasons. The actual work is one continuous loop, and the loop only closes when the customer's behavior changes.
Why the role exists now (more than it did five years ago)
LLM products collapsed the distance between a working demo and a useful production system in a strange way. The demo became cheaper to produce than ever. The production system became harder, because the surface area of "what this thing is supposed to do" exploded. Every customer wants a slightly different slice of the same model.
A traditional SaaS product handled this with feature flags and config. An LLM product handles it with prompts, retrieval indexes, evals, and tool-calling schemas, most of which can't be specified in advance because the customer doesn't know what they want until they see the thing failing on their own documents.
Someone has to be in the room when it fails. That's the job.
What it isn't
It's not sales engineering, because the deal is already closed when you arrive. It's not customer success, because you write code, not playbooks. It's not consulting, because you stay long enough to own the outcome. It's not a machine-learning engineer role, because you spend more time on plumbing than on models.
The cleanest way to describe it: a contractor who joins the customer's product team for ninety days and is judged on whether the product gets adopted.
The actual workflow
A representative week:
- One or two days at the customer site or on calls with their team. Watching, asking questions, capturing edge cases.
- One or two days writing glue code, adapters, prompt revisions, retrieval tuning, eval suites against their data.
- One day cleaning up something the vendor product can't yet do, and writing the ticket that proposes the fix upstream.
- A standing hour with the vendor's product team explaining what the customer keeps tripping on.
The most underrated part is the last bullet. The vendor side learns more from one forward-deployed engineer than from a year of customer interviews, because the FDE has skin in the game. They're not summarizing. They're making bets on what to fix next and watching whether those bets work.
Who hires for this
Companies that sell a product that almost works for the customer out of the box, but where the gap is too narrow for a separate integration partner and too wide for the customer's own team to bridge. AI-native startups are the most obvious example. Government modernization vendors are another. Anyone who sells into regulated industries falls into this pattern eventually.
If the gap is wide enough that the customer should hire integrators, you don't need an FDE. You need a partner channel. If the gap is narrow enough that the customer can self-serve, you don't need an FDE either. The role lives in the middle band.
Why I picked this lane
Two reasons, both honest.
First, I'm not the strongest pure researcher in any of the domains I work in. I'm not going to publish a paper that moves the model frontier. But I can sit in a room with a Kazakhstani oil and gas contractor or a Sakha regional ministry and figure out what their existing software cannot do, then build the thing that closes the gap. That's a different skill, and it's underpriced right now.
Second, the work compounds in a way pure development doesn't. Every customer engagement teaches you something about how AI products fail in the real world. That knowledge is portable. After a year of it, you can walk into a new domain and predict where the seams will be before the customer tells you.
The honest cost
This work breaks the standard career narrative. You don't ship a single product. You ship pieces of many products. Your GitHub graph won't tell the story of what you did. Your resume reads like a list of seemingly-unrelated client projects.
If you need a clean career arc, promotion paths, title progression inside a single org, this isn't the lane. If you need the work to be visible from the outside, this isn't the lane either. The thing you build is mostly invisible: it lives inside someone else's product, attributed to someone else's team.
The compensation for that invisibility is that the work is real. People actually use what you ship. That, after a few years of building things nobody opened, is worth more than I expected it to be.
If you're considering this lane: the easiest entry is to find an AI product you genuinely use and reach out to their team offering to help one specific customer they're stuck on. Most early-stage companies will say yes within a week.