A forward-deployed engineer (FDE) is an engineer who works inside the customer's problem rather than inside the product team's backlog. They sit with the people who will use the system, learn the workflow properly, and build the connective tissue that turns a general-purpose capability into something that fits one organisation's actual process.
The role was formalised at Palantir and has since been adopted, under various names — solutions engineer, deployment engineer, applied engineer — by most companies selling technology that cannot be dropped in unmodified. AI integration work has made the role suddenly central, for a specific structural reason.
Why AI projects need forward-deployed engineers
Because the hard part of an AI project is almost never the model.
The model is the commodity. Every competitor has access to the same frontier models through the same APIs, on similar terms. What differs — and what decides whether a deployment works — is everything around it: which data the system can see, how the workflow actually runs today, what "correct" means in this organisation, who checks the output, and what happens when it is wrong.
None of that is knowable from a requirements document. It is knowable by sitting with the team for a week. That is the FDE's job, and it is why AI integration consulting looks so different from classic software delivery: the specification is the deliverable, and it can only be produced from inside.
| Traditional systems integration | AI integration | |
|---|---|---|
| Requirements | Knowable up front; the system is deterministic | Discovered by observing where the model fails on real inputs |
| Definition of done | The feature works | The output is right often enough, and wrong safely |
| Main risk | Scope and schedule | Quality on the long tail, and user trust after the first bad output |
| Testing | Assertions pass or fail | An evaluation set with a score, and a threshold someone had to choose |
| Biggest cost | Engineering time | Evaluation, review, and the workflow redesign around the model |
What does a forward-deployed engineer actually do?
Learn the workflow before touching the stack
The first week produces no code. It produces an accurate description of how the work is done today — including the parts nobody documented: the spreadsheet that bridges two systems, the person who eyeballs exceptions on Friday, the rule that exists because of an incident in 2021.
AI deployments fail on exactly these details. A summarisation tool that ignores the reviewer's actual acceptance criteria produces summaries nobody uses; an extraction pipeline that does not know which fields are legally load-bearing will be equally confident about all of them.
Find the narrowest valuable slice
The instinct is to automate the whole process. The FDE instinct is to find the one step where the model is reliably better than the status quo and ship that first — with the humans still in every other step.
This is not timidity. It is how you get an evaluation set. A narrow slice in production generates real inputs, real failures and real user judgements, which are the only materials from which a broader deployment can be built. Teams that skip this stage end up tuning against imagined inputs.
Build the evaluation harness before the feature
The single most consequential thing an FDE brings to an AI project is the insistence that "good" be defined numerically before the build starts. That means a set of real inputs with expected outputs, a way to run them, and a threshold someone with authority has agreed to.
Without it, every subsequent conversation is aesthetic. Prompt changes get argued from anecdote, model upgrades are gambles, and nobody can say whether last week's change helped. With it, the project becomes ordinary engineering.
An AI deployment without an evaluation set is not a project; it is a demo with a deployment date attached.
Design the failure path, not just the happy path
Every model is wrong sometimes. The design question is what the wrongness costs and who catches it. FDEs work this explicitly:
- What is the cost asymmetry? A false positive and a false negative rarely cost the same, and the threshold should reflect that rather than defaulting to whatever maximises accuracy.
- Who reviews, and with what information? A reviewer shown a confident answer with no provenance will approve it. A reviewer shown the source passage will catch the error.
- How does a user report a bad output? If the answer is "email someone", the feedback loop does not exist and the system will not improve.
- What is the fallback? Degrading to the previous manual process must be possible on the day the model provider has an outage.
Hand it over so it survives
An FDE engagement that ends with a system only the FDE understands has failed. The exit criteria are boring and non-negotiable: the evaluation set is in the customer's repository, someone on the customer's team has changed a prompt and watched the score move, the runbook exists, and the cost model is documented.
How AI integration consulting differs from a software SOW
Three structural differences change how these engagements should be scoped and priced.
- The specification emerges from the work. You cannot write a fixed-scope statement of work for something whose requirements are discovered by observing failures. Phase the engagement instead: a time-boxed discovery producing an evaluation set and a costed plan, then a build phase scoped against what discovery found.
- Quality is a threshold, not a binary. "Done" must be written into the contract as a number on an agreed evaluation set. Engagements that omit this end in a dispute where both parties are sincere and neither can be shown wrong.
- Running cost is part of the design. An architecture that is elegant and costs more per outcome than the manual process it replaces is not a solution. Cost modelling belongs in the design phase, not the invoice — see costing an AI feature before you build it.
What to look for when hiring for this work
- Can they explain the customer's business back to you? An FDE who talks only about the stack has not done the first part of the job.
- Do they ask what "wrong" costs? The strongest early signal. Engineers who ask this build systems that survive their first bad output.
- Do they propose the narrow slice, or the platform? A proposal to rebuild the workflow before anything is in production is a proposal to learn nothing for six months.
- Do they bring an evaluation plan unprompted? This separates people who have shipped AI systems from people who have demonstrated them.
- Can they say no to the customer? Forward-deployed work creates enormous pressure to agree with whoever is in the room. An FDE who cannot push back becomes an expensive way to build the wrong thing quickly.
A workable engagement shape
| Phase | Duration | Exit criterion |
|---|---|---|
| 1. Discovery | 1–2 weeks | Documented current-state workflow, the narrow slice named, cost asymmetry agreed |
| 2. Evaluation baseline | 1–2 weeks | An evaluation set of real inputs with agreed expected outputs, and a baseline score |
| 3. Narrow build | 3–6 weeks | The slice in production for a limited user group, above the agreed threshold |
| 4. Broaden | Ongoing | Each extension gated on the evaluation set, with cost per outcome tracked |
| 5. Handover | 1 week | Customer team has independently changed a prompt and moved the score |
Phases 1 and 2 are the ones customers try to compress, and they are the ones that determine whether phases 3 to 5 are engineering or guesswork. An FDE's most valuable contribution is often simply refusing to skip them — and being able to show, with a number, what skipping them costs.
The output of phase 1 is a scoping report: options, costs, and the unknowns that have to be retired before the estimate can tighten.
Frequently asked questions
What is a forward-deployed engineer?
A forward-deployed engineer is an engineer embedded with the customer rather than with the product team — learning the workflow first-hand, then building the integration and configuration that turns a general-purpose capability into something that fits one organisation's actual process. The role was formalised at Palantir and now appears under several names, including solutions engineer, deployment engineer and applied engineer.
Why can't AI integration be scoped as a fixed-price project?
Because the requirements are discovered rather than specified. You learn what the system must handle by running it against real inputs and watching where it fails, which by definition happens after work begins. The workable alternative is a phased engagement: a time-boxed discovery phase that produces an evaluation set and a costed plan, then a build phase scoped against what discovery actually found.
What should be in the contract for an AI integration engagement?
A numeric definition of done: a named evaluation set, an agreed metric, and a threshold. Engagements that leave quality as a qualitative judgement end in disputes where both parties are sincere and neither can be shown wrong. The contract should also state who owns the evaluation set afterwards — it is the most durable asset the engagement produces.