What is a forward-deployed engineer?

What is a forward-deployed engineer?

The word doing the work in that definition is forward. It is borrowed from military logistics, where a forward-deployed unit is stationed in the theatre it operates in rather than at home base. The analogy is exact and it is the whole point of the role: some problems cannot be understood at a distance, and a specification written at head office about a process you have never watched will be wrong in ways nobody can predict from head office.

That dual mandate is the part most companies get wrong when they adopt the title, and it is worth being blunt about early: if the code and the learning stay with the customer, you do not have forward deployment. You have a consultancy with a software logo.

Where the role came from

Palantir’s early problem was that it sold a platform to institutions whose actual work was classified, idiosyncratic, or simply undocumented. There was no way to write requirements for an intelligence analyst’s workflow from a conference room in Palo Alto. So the company sent engineers to sit with analysts, watch what they did, and build against it — and then, critically, generalised the recurring parts into the platform. The pattern that emerged is that a large share of what looks like bespoke customer work turns out, after enough deployments, to be the product.

This is why the model keeps reappearing in categories with a particular shape: high-value, high-variance operations where the customer cannot articulate their own process precisely enough to be automated from a written brief. Defence and intelligence. Healthcare operations. Financial crime. And now, conspicuously, AI agents.

What a forward-deployed engineer actually does

The order matters, and the first item takes far longer than engineers expect. Most of the difficulty in a deployment is not technical. It is that the customer’s described process and their actual process are different documents, and only one of them is written down.

Process discovery

The deliverable of discovery is not a requirements document. It is a model of the decision the software has to make, including the cases the customer forgot to mention because they are handled by one person who has been there eleven years. The reliable technique is to watch real work in real time and interrupt constantly: why did you do that, what would you have done if the field were empty, who do you ask when you are not sure. The exceptions are the product.

Integration

In any operation older than about five years, the systems of record are partly undocumented and the person who built the integration layer has left. An FDE spends real time on credentials, rate limits, data that does not match its own schema, and staging environments that differ from production in ways nobody has written down. This work is unglamorous and it is where deployments actually slip.

Building the customer layer

This is production code: the integrations, the domain logic, the configuration, and — in agent deployments specifically — the evaluation suite that proves the thing works before it touches a real customer. It runs in production and the customer’s operation depends on it. If it were throwaway, the role would not need engineers.

Promotion

The discipline that separates forward deployment from consulting: after each deployment, decide what was genuinely customer-specific and what was the third time you have built the same thing. The second category gets promoted into the core product. Companies that skip this step end up with N customer codebases and a headcount problem that scales linearly with revenue.

Forward-deployed engineer vs adjacent roles

The economic difference hides in the fourth column. Professional services is a margin business you tolerate to close enterprise deals; its output is billable hours and its knowledge stays in the engagement. Forward deployment is an R&D function disguised as delivery: you accept services-like gross margins early, in exchange for product knowledge that no amount of user research would have surfaced, and you expect margin to improve as promotion does its work.

If margins are not improving deployment over deployment, the promotion step is not happening, and the model has quietly degenerated into the thing it was supposed to avoid.

Why AI agent companies need forward deployment

This is not a theory about where the market is going. It is a description of how the current leaders already operate. Sierra, which passed $100M in annual recurring revenue selling AI customer-service agents, has been characterised as running closer to a consulting engagement than a software subscription — it ships a managed implementation rather than a product you configure yourself. Decagon embeds forward-deployed engineers alongside agent product managers on its customer accounts and has written publicly about redefining the practice.

The reason is structural. A conventional SaaS product fails gracefully: a confusing feature costs the user a few minutes. An agent fails expensively — it tells a customer their replacement has shipped when it has not, or commits the company to a refund policy that does not exist. The cost of a wrong answer is what forces the deep process work, and the deep process work is what requires a person on site.

The three things only an embedded engineer learns

The middle one is the most consistently underestimated. Every organisation has an implicit map of which decisions require a human, and it almost never matches the org chart or the written policy. You discover it by proposing that the agent handle something and watching who flinches. That is not a conversation you can have over email in week one, and it is the conversation that determines whether the deployment reaches production.

The market gap this creates

Forward deployment is expensive, which is why the companies practising it price for enterprise. Reported entry points in AI customer service sit around $95K–$150K per year and above, which exceeds the entire annual technology budget of a support organisation running twelve to twenty-five agents. The result is a market split: enterprises get done-for-you delivery, and everyone else is handed a self-serve builder and wished luck.

That gap is the interesting part of the current market. The delivery model that demonstrably works is being withheld from most of the companies that need it, not because it cannot be done affordably, but because the incumbents’ cost structures are built around enterprise deal sizes.

The first thirty days on a deployment

The week-three instinct to build broadly is the one worth resisting hardest. A single workflow running end to end in production teaches you more than six workflows in staging, because only production surfaces the integration behaviour, the latency, the weird inputs, and the political question of who owns the outcome when it goes wrong.

Hiring and compensating forward-deployed engineers

What to screen for

The most predictive interview signal is how a candidate handles a problem where the requirements are deliberately incomplete. Strong FDE candidates start asking about the operation — who does this today, what happens when it fails, what does the person actually want. Weaker candidates start proposing architecture. Both are engineering instincts; only one survives contact with a customer.

The archetypes that fail

The purist is the most common and the most costly, because the instinct is a good one misapplied. Customer processes usually are inefficient. But the inefficiency is load-bearing more often than it looks, and an engineer who redesigns it in week two without understanding why it exists will produce a technically superior system that the organisation quietly refuses to use.

Compensation

Benchmark to a senior product engineer on the same ladder, not to a consulting or services band. Published salary averages for this title are unusually unreliable because companies apply it inconsistently — some use it for genuine embedded engineering, others for what is plainly solutions engineering — so an average across both is not measuring one job. Compare against the specific company’s engineering levels instead.

If the role carries meaningful travel or on-site expectations, price that explicitly rather than folding it into base. Ambiguity about it is a reliable source of attrition at month nine.

When you don’t need forward deployment

Three honest disqualifiers. If your customers all do the same thing, a good onboarding flow and documentation will outperform an engineer, because there is nothing to discover. If your contract value cannot absorb weeks of engineering time, the arithmetic does not work and no amount of process discipline fixes it. And if your product genuinely fails gracefully, the depth is not warranted — you are buying insurance against a risk you do not carry.

There is also a timing question. Forward deployment is most valuable early, when you do not yet know what the product is, and its value decays as the product converges. A company still sending engineers to every customer at scale has either chosen a services business deliberately — a legitimate choice — or has failed to promote what it learned. Those two look identical from outside and completely different on the P&L.

The test we would apply: if your fifth deployment in a segment does not take meaningfully less engineering time than your first, the model is not working as designed. Not because delivery should disappear, but because the whole argument for putting engineers in the room is that what they learn there stops being learned twice.