What a Forward Deployed Engineer Actually Does

"Forward Deployed Engineer" sounds like a job title invented by a marketing team, and for a while I treated it that way too. Then I spent a few years shipping AI systems directly into customer environments — voice agents, LLM pipelines, MCP servers, automation workflows — and realized the title describes something real and specific: an engineer whose desk is inside the customer's problem.

Palantir coined the term, but the AI wave is what made it a mainstream role. Here's what the job actually is, stripped of the mystique.

The one-sentence version

A Forward Deployed Engineer takes a powerful, general-purpose product — usually an AI platform — and turns it into a working solution inside one specific customer's messy, real-world environment. You own that journey end to end: discovery, architecture, build, deployment, and the awkward middle part where the customer's ops team decides whether they trust the thing.

A product engineer builds the platform. An FDE builds with the platform, in the field, where all the assumptions break.

Half engineer, half field operator

The split is real, and both halves are load-bearing.

The engineer half is genuine build work. Not configuration, not "light scripting" — real systems engineering. In my case that has meant NestJS backends serving real-time interactions across 40,000+ locations, WebRTC voice pipelines gluing together Deepgram, ElevenLabs, and Claude, MCP servers exposing customer systems to agents, and n8n orchestration for approval workflows that a compliance team could sign off on. If you can't build production software, you can't do this job. Full stop.

The field operator half is everything a product engineer never has to do:

Sitting in a discovery call and noticing that the workflow the VP described is not the workflow their team actually runs.
Translating "we want AI" into a spec with inputs, outputs, and failure behavior.
Demoing to a skeptical room and handling the person whose job the agent appears to threaten.
Navigating the customer's security review, their VPN, their ancient internal API with no docs.
Being the human the customer calls when something breaks at a bad time — and having the standing to say "that's not a bug, that's the workflow we agreed to change in v2."

Most engineers are strong on one half. The role exists because customers need someone strong on both, in the same person, in the same meeting.

What "owning the deployment end-to-end" means in practice

The phrase gets thrown around, so let me make it concrete. On a typical engagement I own:

Discovery — finding the real workflow under the stated one. This is a craft of its own; I wrote a separate post on running discovery for AI agent deployments.
Scoping — cutting the customer's wishlist down to a v1 that can ship in weeks and prove value, then defending that cut.
The proof-of-concept — a demo real enough to close the deal without being a maintenance liability. (More on that here.)
The build — the actual pipelines, agents, integrations, and glue. This is where the production-agent fundamentals — tool design, evals, latency budgets — earn their keep.
Deployment and hardening — their cloud or yours, their auth, their data residency requirements, their change-management process.
Adoption — training the ops team, watching real usage, fixing the gap between how you designed it and how they use it.
The relationship — staying the trusted technical advisor after go-live, because the second and third projects come from trust built on the first.

No handoffs. If step 6 fails, steps 1–5 were wasted, and it's still your problem.

Why AI companies need FDEs right now

Traditional SaaS didn't need this role at scale. You bought Salesforce, an admin configured it, done. AI products are different in three ways that make the FDE role structurally necessary:

The product is a capability, not a solution. An LLM platform, an agent framework, a voice stack — these are engines, not cars. Every customer needs nontrivial engineering to turn the capability into a system that does their work. Somebody has to do that engineering, and it can't be the customer (they don't have the AI expertise yet) and it can't be the core product team (they'd never ship the platform).

The gap between demo and production is enormous. Anyone can make an agent look magical for five minutes. Making it survive real users, real data, real latency budgets, and a real security review is where deals are actually won or lost. That gap is precisely the FDE's territory.

The field is where product truth lives. Every deployment surfaces what the platform is missing. FDEs are the highest-bandwidth channel between customers and the roadmap — not filtered through sales notes, but as engineers who personally hit the missing feature at 11pm before a go-live. At Ôdasie, patterns my team kept rebuilding across client deployments turned directly into reusable internal tooling. That loop is the whole point.

A week in the life

To make it less abstract, a composite week from mine:

Monday: discovery call with a new client's ops team. The stated requirement is "an AI agent that answers customer emails." Two hours of questions later, the real requirement is a triage-and-draft system with human approval, because their compliance rules never allowed full automation in the first place.
Tuesday–Wednesday: heads-down build. Extending an MCP server to expose their order system to the agent, writing evals from twenty real (anonymized) tickets, wiring the approval step into their existing n8n flow.
Thursday: demo to the buying committee. Live, on their data, with one carefully chosen hard case to show the agent escalating instead of guessing — because showing the failure behavior builds more trust than showing the happy path.
Friday: security questionnaire, a call with their infra lead about data residency, and a blunt internal note to our product team about the missing audit-log feature that came up twice this week.

Engineer in the morning, field operator in the afternoon, most days.

The skills that actually matter

If you're evaluating whether you'd be good at this, the honest checklist:

You can ship production systems alone. Backend, integration, deployment, debugging in an environment you don't control. The customer's environment will not have your tooling.
You're fluent in the AI stack, not just curious about it. Agent loops, tool design, evals, prompt behavior under load, model selection, cost. Customers can smell the difference between someone who has shipped agents and someone who has read about them.
You can run a room. Discovery, demos, hard conversations about scope. If a meeting with fifteen skeptical stakeholders drains you into uselessness, the field half will grind you down.
You default to ownership. Nobody assigns you tickets. You see the deployment, you see what's between it and success, and you go do that.
You can say no gracefully. Half the job is protecting the customer from their own wishlist. (That deserves its own post too.)

Notice what's not on the list: sales instinct. FDEs are adjacent to sales and often decisive in deals, but the credibility comes from being unmistakably an engineer. The moment you sound like a salesperson, you lose the thing that makes you valuable in the room.

The takeaway

A Forward Deployed Engineer is what you get when you take a strong production engineer and make them responsible for one customer's outcome instead of one component's code. The AI wave made the role essential because AI products ship as capabilities, and someone has to close the distance between capability and outcome — inside the customer's environment, on the customer's data, with the customer watching.

It's the most leveraged engineering role I've worked in: every deployment compounds into product insight, customer trust, and the next deal. If you like building and you like the field, there has never been a better time to do both at once.

Related reading