What an FDE Actually Does

You have probably heard the job title by now. Forward Deployed Engineer — FDE for short — is the role that every AI company is suddenly hiring for, and the one that the Palantir alumni you know keep insisting predates the current fashion by a decade.

This course assumes you can read code and have built at least one thing with an LLM API. If you have not used Claude Code or a similar agent, our Claude Code Masterclass is the fastest way to get fluent before starting here — but it is not a prerequisite, and the foundations chapters in this course are written for someone starting cold.

This lesson is about what an FDE actually does on a working day, because every later chapter is a particular craft of that job and the shape of the job itself is the thing worth getting right first.

The one sentence version

An FDE owns a customer outcome end to end, inside the customer's codebase and on top of the employer's platform, starting from the moment the contract is signed and ending when the thing runs in production and keeps running.

Every word in that sentence is doing work. Owns — the FDE is the single throat to choke, not a consultant handing off a deck. Customer — somebody paid for this, which changes what "done" means. Outcome — not a feature, not a demo, a measurable business result. End to end — discovery, scoping, build, rollout, iteration. Inside the customer's codebase — their stack, their data, their constraints, not a sandbox. On top of the employer's platform — Anthropic's API, OpenAI's API, Palantir's Foundry, Databricks' Mosaic. After the contract — not a sales call.

What that looks like

A representative day is the wrong teaching unit for this role, because the work is lumpy — one day is a workshop with four stakeholders, the next is a tracing session in production. A representative engagement is closer.

an eight-week engagement

1. WhyWeek one — discovery. You are on a video call with a general counsel's office at a mid-size law firm. The ask is 'can we use your model to automate contract review'. The real question is which three paragraphs of a contract the senior lawyers want flagged, and under what conditions a flag is a false alarm.

2. >You typed: What does the current process look like when the paralegal flags something?

3. Output: A senior partner reads the flag and either confirms it or marks it a false positive. 60% of flags are false positives.

4. WhyYou now have the only metric that matters. Not accuracy. Not throughput. Precision on partner-confirmed flags, with the current 40% floor as the thing to beat.

5. >You typed: What would 'good enough to ship' look like to the partner who signs off?

6. Output: Precision over 85%, recall over 90% on a set we hand-label.

7. WhyWeek two — prototype. You build a small retrieval pipeline and a first-pass judge rubric. You spend most of the week on the rubric, not the pipeline, because the rubric is the thing the customer will argue about and the pipeline is the thing you will swap three times.

8. WhyWeek three to five — evals. The customer hand-labels 300 contracts. You discover the rubric disagrees with itself on two categories. You rewrite the rubric. The recall number improves but partner trust does not, because partners can now see which clauses it missed and the misses are the exact ones they would have flagged.

9. >You typed: I think we are measuring the wrong thing. Let me show you a set of five misses.

10. WhyWeek six — rollout. You deploy to a pilot team of four lawyers. You wire an evaluation harness that scores each production response against a daily-rotated seed set, and a Slack channel that pings you when the rolling precision drops.

11. WhyWeek eight — the alarm fires. A new category of contract has entered the pipeline and the agent is confident and wrong. You pull the traces, add examples to the eval set, tune the retrieval, redeploy.

Count the hours that went into the moving parts. The pipeline is maybe five days of real engineering. Everything else is the shape of the problem and the instruments that will say whether it is solved. That is what the job is.

The loop, as an FDE lives it

1. Step 1

   Discover

   Find the outcome the customer is actually trying to buy. The asked-for feature is almost never the right description of it.

2. Step 2

   Scope

   Agree what 'done' measures against, what you will not do, and the three commitments you need from the customer to build.

3. Step 3

   Build

   A prototype, honestly scoped. The code is the smallest artifact of this phase; the rubric and the first eval set are the ones you will keep.

4. Step 4

   Evaluate

   A set that the customer helped curate and a judge they trust. Regressions block releases; passing regressions do not force one.

5. Step 5

   Deploy

   Into their stack, with their auth and their data residency and their on-call. The deploy is the beginning of the interesting part, not the end of it.

6. Step 6

   Iterate

   Real inputs reveal failure modes no eval set anticipated. The eval set grows from them. The loop runs again.

If the loop looks heavy on measurement, that is on purpose. The single thing that separates an FDE engagement that ships from one that stalls is whether the eval suite was treated as the deliverable from week two, or as a nice-to-have that someone would get to after the demo landed well.

What the role is not

A few confusions worth clearing up now, because each one gets its own short chapter later and the shorthand is useful immediately.

It is not a sales engineer in a hoodie. A sales engineer owns the demo that closes the contract. An FDE starts after the contract. The jobs touch but they do not overlap.

It is not a research engineer at a customer site. The platform is what it is; the FDE's job is to use it, not to fine-tune a new model for each customer. When fine-tuning is the right answer it is a specific, scoped decision, not a default.

It is not a consultant. A consultant produces a deck. An FDE ships code into the customer's repository, writes the runbook their on-call will use, and is paged when it breaks at three in the morning.

It is not a generalist SWE on secondment. The LLM-shaped parts of the work — evals, judge rubrics, retrieval behaviour, agent control flow — are specific crafts with their own failure modes, and most of the course is about those.

What to take away

An FDE owns a customer outcome end to end after the contract is signed, working on top of the employer's AI platform inside the customer's stack. The build is a small fraction of the hours. The scoping and the evaluation are most of the job, because they are what forces an ambiguous customer problem into a shape that can be shipped. The role is not a sales engineer, a researcher, a consultant or a general SWE; it has specific instruments, and the rest of this course teaches them.

Next: who is actually hiring for this role in 2026, and what their job descriptions ask for in their own words.