FDE vs AI
Engineer

Start with the honest part: the technical surface is nearly identical. Both roles ship retrieval over messy documents, agents that drive a multi-step workflow, tool schemas, guardrails, latency and cost budgets, and evals that decide whether any of it is good enough. Anthropic’s forward-deployed job description lists MCP servers, sub-agents and agent skills as deliverables¹⁰ — a list that would sit unchanged in an AI engineer JD.

So anyone telling you FDEs are “less technical AI people” is describing a pre-sales role, not this one. The split is not depth of AI knowledge. It is what the AI is embedded in.

Watch the names. Applied AI Engineer, Agent Engineer, Forward Deployed AI Engineer and AI Solutions Engineer all describe the same emerging job: an AI engineer who is pointed at a specific customer. Anthropic’s forward-deployed role sits under Applied AI.¹⁰ Sierra hires “Agent Engineers” whose day is building and tuning customer-specific agents.²⁸

The strategic read: the merged titles are where hiring is growing fastest and where candidate supply is thinnest, because they demand a combination — frontier-AI fluency plus enterprise delivery nerve — that few people have deliberately built. Postings for the family grew 729% year over year on one index.¹

If you take one thing from this page: negotiated evals.

An AI engineer usually gets to define correctness. You pick the benchmark, you curate the golden set, you decide the threshold. An FDE almost never does. The customer’s domain experts define correct, and they disagree with each other — two senior claims adjusters will label the same case differently, and both will be adamant. Turning that into a gate a contract can rest on is the highest-leverage thing an FDE does, and it is the most-cited hard skill across frontier-lab job descriptions.

The FDE’s structural advantage is pattern volume. Sit inside twenty enterprises and you accumulate a map of which problems recur, which are worth productising, and what customers will actually pay for. That is founder fuel, and it is why the exit list skews entrepreneurial. The AI engineer’s structural advantage is compounding depth in a field where depth is scarce and expensive.

Take the page’s recipe: two experts, 40 real cases, labelled independently. Say it is a claims queue with two labels, approve or deny. Expert A approves 24 cases and expert B approves 22. These counts are illustrative; the arithmetic is not.

Step 4 is the step most people skip. Two experts who approve most cases will agree often just by chance, so 70% raw is a kappa of only about 0.39: far from strong agreement, and no solid ceiling. Step 6 is where the rubric earns its keep. If the experts now agree on 18 of 20, you have shown that the task can be defined, and you have a human figure to set the gate against. An AI engineer usually skips steps 1 to 6 because they own the definition. For an FDE those steps are most of the job, and the result goes into the contract.

Here Time is where your hours go, Space is what builds up over a career, and Why is who the role suits. All of it comes from the page above.

Read top to bottom, each row spends more hours on the customer and fewer on the system. The middle three rows are where hiring is merging, so most real openings sit somewhere in rows 2 to 4.

• Defining correctness yourself at a customer

  The AI-engineer habit is to pick the benchmark and the threshold. Do that at a customer and the gate is yours, not theirs, so the first time it fails a case their expert cares about, they reject the whole thing. Their experts must agree to the rubric before it gates anything.

• Calling an offline metric success

  A deployment can pass every eval and still change nothing about how people work. For an FDE, a good eval only gets you permission to ship. Adoption is the result. Report both.

• Taking raw agreement as the ceiling

  With two labels and unbalanced classes, 70% agreement can be mostly luck, as step 4 above shows. Report agreement corrected for chance next to the raw figure before anyone negotiates a target from it.

• Finding out the deploy target last

  An air-gapped enclave cannot call a hosted model API. A VPC may block outbound traffic altogether. Ask where it will run in the first meeting, because the answer can rule out your model, your vector store and your observability stack.

• Skipping the job-shape questions

  In some roles travel is 25–50% by contract, and some drift into services work. Before you accept, ask for the share of time spent on code and the travel expectation in writing.

• One RAG system, two jobs

  The same retrieval stack ships as a product feature behind a flag, tuned against your own eval suite. It also ships into a customer’s VPC, gated by a rubric their reviewers signed. Same code, different person deciding “correct”.

• The eval question in interviews

  Both loops ask “how would you evaluate this?”. The AI-engineer answer names metrics and a golden set. The FDE answer adds who labels it, how you measure their agreement, and who signs off on the threshold.

• Reading a posting

  Words like travel, statement of work, stakeholders, on-prem and customer environment point to FDE work. Inference, serving, evaluation infrastructure and latency point to AI engineering. A posting with both is the merged role.

• Moving from AI engineer to FDE

  The technical half carries over. What to show is the customer half: a write-up of an eval you negotiated with people who disagreed, and something you deployed into an environment you did not control.