A Forward Deployed Engineer (FDE) embeds with the customer and makes the product work there - the last-mile deployment gap where frontier AI dies on messy data and workflows nobody wrote into the Statement of Work (SOW).
Shipping a strong model does not mean the buyer gets the outcome they paid for. Their stack rarely matches your playbook. That gap is why the role exists.
Definitions
Forward Deployed Engineer (FDE) - builds and troubleshoots from inside the client’s environment, not from a ticket queue. Rocketlane’s 2026 guide puts the role at the overlap of software engineering, product thinking, and customer consulting.
Last-mile deployment - adapting a shipped product to the customer’s real systems until the bought outcome lands. Product eng ships the capability; last-mile work keeps it alive after contact with the customer.
Requirements elicitation - the active slice of requirements gathering: pulling needs and constraints from users and domain experts (ISO/IEC/IEEE 29148). Field elicitation is that work in motion - it never stops onsite, because most enterprise blockers are discovered, not stated.
Why the last mile fails without embedding
Enterprise buyers pay for results. Config-only onboarding stalls on incomplete data, undocumented APIs, and “we’ve always done it this way” exceptions that blow up time-to-value.
Palantir invented the modern pattern in the early 2010s by seating engineers (Deltas / FDSEs - their field-deployment titles) inside strategic customers - government and bank deployments included - so builders could untangle pipelines no discovery call surfaces. AI labs copied it for frontier models. OpenAI’s FDE team grew from 2 to 10+ engineers in 2025 for that last-mile problem alone.
Vague requirements make the failure expensive later. PMI found inaccurate requirements gathering a primary cause of project failure in 37% of surveyed organizations. NASA data cited by Jama Software: fixing a requirements error late can cost 29x to 1,500x more than catching it during requirements work. Somebody has to catch those errors where the customer actually runs.
What the work looks like: scope, validate, deliver
Titles vary by company. OpenAI’s FDE postings spell out three phases that map cleanly to how agentic products should ship in the field:
| Phase | What happens | Why it matters |
|---|---|---|
| Early scoping | Days onsite whiteboarding with the customer | Surface real constraints (VPC, SSO, legacy systems) before you build the wrong thing |
| Validation | Build evals and quality metrics against the customer’s tasks | Demo success is not production success - see five metrics for an agent eval pipeline |
| Delivery | Multi-day customer site visits building the solution | Own the go-live; don’t file a ticket and leave |
Palantir embeds for weeks or months (travel often 25-50%), including airgapped facilities and assembly lines. Anthropic often uses a “Solutions Architect” title on Applied AI for similar enterprise advisory work. Scale AI’s FDE variants skew toward data infrastructure and evaluation frameworks. The title is noisy. The job is outcome ownership with code.
Scoping onsite is the same discipline as planning a build with measurable goals - replace adjectives (“respond quickly”) with numbers the customer can verify. Field elicitation is how you get those numbers when the SOW only has vibes.
FDE vs adjacent roles
| Role | Builds / extends product in customer env | Primary job |
|---|---|---|
| FDE | Yes - production code, integrations, edge cases | Own the customer outcome end-to-end |
| Customer Success Engineer | No - config and enablement | Guide within current product capabilities |
| Solutions Engineer / Architect | Limited - pre-sales architecture | Sell or advise on the vision |
| Classic Professional Services | Sometimes - project delivery within SOW | Manage timeline and configuration scope |
CSEs guide. SEs sell the vision. An FDE makes that vision run on the customer’s stack. If removing the person leaves only a ticket queue and a playbook, you did not staff an FDE.
Skills that transfer to agentic shipping
Rocketlane’s skill list for modern FDEs lines up with agentic engineering, not with pure LeetCode:
- Technical depth past config - code, APIs, data pipelines
- Spotting the real blocker when the customer cannot name it
- Product judgment - one-off customization vs real product gap
- AI fluency - what to automate vs what needs a human; field evals over vibes checks
That last point is the same distinction vibe coding vs agentic engineering makes: verify before you ship, not after. Ship an LLM feature without evals in the customer’s environment and you are vibe-deploying. Validate first. Deliver second.
Next move
Evaluating last-mile staffing? Map one stalled enterprise deal to the three phases above. Write the measurable outcome and the anti-goals - explicit non-requirements (plan and scope). Define the field evals (agent eval pipeline). Name who owns delivery with code onsite. For the atomic definition of the gap itself, see last-mile deployment.