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 FDE posting puts the role at the intersection of engineering, product, and customer success.
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 organization started with two people and has grown to around 140 for that last-mile problem alone.
Vague requirements make the failure expensive later. PMI’s 2014 Pulse of the Profession found inaccurate requirements gathering a primary cause of project failure in 37% of organizations. NASA’s error-cost study found that fixing a requirements error in the operations phase cost 29x to more than 1,500x what it would have cost in the requirements phase. 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 describe the work as discovery and scoping, eval-driven validation, and production rollout on site - three phases that map cleanly to how agentic products should ship in the field:
| Phase | What happens | Why it matters |
|---|---|---|
| Discovery and scoping | Onsite work with the customer’s engineering and domain teams | 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 | Build and production rollout, on site - OpenAI’s postings ask for up to 50% travel | Own the go-live; don’t file a ticket and leave |
Palantir’s Forward Deployed Software Engineer postings ask for 25-50% travel, depending on team and location. Anthropic’s closest title, “Solutions Architect, Applied AI”, is a pre-sales advisory role. 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 FDE requirements - code, integrations, data pipelines, hands-on LLM and agent work, customer-facing delivery - line 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.