FDE Engineer

FDE Engineer: the job behind production AI delivery

An FDE Engineer, or Forward Deployed Engineer, works where a customer's operating problem meets the hard edge of production software. The job is not to arrive with a generic demo, write a slide deck, and disappear. An FDE Engineer stays close to the people doing the work, turns an unclear request into a bounded system, helps build it, tests its behaviour, and supports rollout until the workflow actually changes.

That makes the role demanding in a useful way. A good FDE Engineer needs enough engineering depth to spot a brittle integration, enough product judgement to reject a weak use case, and enough customer context to notice when a technically correct system will still fail in practice. The person does not own every line of code or every stakeholder relationship. They do own the connection between the delivery decisions and the customer result.

For AI projects, that connection is especially important. A model can produce a fluent answer while retrieving the wrong policy, leaking the wrong context, or sending a user into a dead end. An FDE Engineer treats permissions, evals, human escalation, cost, latency, observability, and adoption as parts of one system.

What an FDE Engineer actually owns

The title changes from company to company. The work is easier to understand by following the delivery loop. An FDE Engineer commonly owns the decisions that move a customer problem through discovery, scope, implementation, evaluation, and adoption.

Find the workflow worth changing

An FDE Engineer begins with real work, not a model choice. Who is losing time? What information is missing at the moment of decision? Which exception causes the most rework? A support team may ask for an assistant, but the useful first question is whether agents need faster retrieval, better case routing, a draft reply, or a clearer escalation path. Each answer produces a different system and a different risk profile.

The FDE Engineer talks to users, a business owner, engineers, data owners, and security partners. They record what happens today, which source is authoritative, which actions must remain human, and how the team will know the release helped. A small, observable problem is usually a better first deployment than a broad promise to "use AI everywhere."

Turn ambiguity into a delivery brief

After discovery, an FDE Engineer writes down the first useful boundary. The brief should name the user, trigger, input, output, data boundary, success measure, non-goals, fallback, and release scope. This is not paperwork for its own sake. It lets engineers and customer teams decide whether they are solving the same problem before implementation gets expensive.

For example, an FDE Engineer might limit an initial knowledge workflow to one regional support group, approved policy sources, questions in one language, and responses that cite the source. The team can then measure time-to-answer, escalation rate, and source quality. If the system misses the mark, the FDE Engineer can identify why instead of arguing from anecdote.

Build the whole useful slice

An FDE Engineer needs hands-on technical credibility. Depending on the team, that may mean writing a full-stack prototype, reviewing the production implementation, defining an integration contract, pairing with platform engineers, or debugging an incident at the customer site. The work can include retrieval, structured output, tool calls, APIs, identity, permissions, queues, background jobs, logging, and front-end interaction design.

The FDE Engineer does not need to be the world's narrowest specialist in every layer. They do need to ask the questions that protect delivery: What happens when the source data is stale? Can this user invoke that tool? What fails visibly, and what fails silently? How can we recover? What is the cost per completed workflow? If nobody can answer those questions, the prototype is not ready to become a customer dependency.

Evaluate behaviour before users depend on it

Evals are part of the FDE Engineer job, not an optional research exercise. Start with representative work: common cases, annoying edge cases, data gaps, policy conflicts, and examples that should go to a person. Label the desired outcome. Then test changes against that set before widening access.

An FDE Engineer does not need a single magic score. A useful evaluation combines task quality with operational evidence. For a document workflow, that could mean field accuracy, correct abstention, review rate, processing time, and the number of downstream corrections. For a knowledge assistant, it could mean citation quality, unsupported-answer rate, and the share of conversations that reach a useful next step.

Release, observe, and make the system stick

Production rollout starts with a narrow audience, clear support ownership, and a path to turn the system off or route work to a person. The FDE Engineer watches behaviour after release. Are people using the system? Are they working around it? Did a queue move faster, or did errors merely move downstream? The answers often require a second pass at scope, UX, training, or source data.

This is where the role differs from a one-off implementation. An FDE Engineer keeps responsibility for the customer outcome long enough to learn whether the delivery changed the work. The lessons should become a reusable playbook, test suite, integration pattern, or product request rather than staying inside one account.

How OpenAI describes FDE work

OpenAI's current Forward Deployed Engineer role description describes an FDE Engineer as leading complex production deployments with strategic customers. It explicitly covers discovery, technical scoping, system design, building, rollout, customer adoption, code contribution, and reusable field patterns. It also ties success to production adoption, workflow impact, and eval-driven feedback.

That is a useful first-party reference, not a universal job specification. A startup may give an FDE Engineer a very broad build role. A large enterprise team may split implementation across platform, security, data, and application specialists. Read the job description closely. The shared thread is practical: the FDE Engineer is expected to move a customer problem into dependable use, not stop at a compelling proof of concept.

FDE Engineer compared with adjacent roles

Role	Primary centre of gravity	What changes in FDE work
Software engineer	Product and platform capabilities	An FDE Engineer adds direct responsibility for discovery, rollout, and proof of customer impact.
Solutions architect	Design, technical guidance, stakeholder alignment	An FDE Engineer is usually closer to the implementation, evals, production issues, and adoption loop.
Product manager	Problem framing, priorities, business outcome	An FDE Engineer brings enough technical depth to turn the delivery choices into a working system.
Customer success or implementation	Adoption, enablement, account outcomes	An FDE Engineer can change the system itself when the workflow needs a technical fix.

The borders are not rigid. Strong teams collaborate across all four. The FDE Engineer role is most valuable when no one else is consistently joining the user's workflow, the technical system, and the launch evidence.

The skills an FDE Engineer needs

Engineering fundamentals still matter

An FDE Engineer should be comfortable reading and writing production code, tracing an API flow, modelling data, reviewing an architecture, and diagnosing failures. Python, TypeScript, JavaScript, SQL, cloud deployment, APIs, and observability are common tools because customer systems need integrations, not isolated notebooks. The exact stack varies. The ability to make sound technical trade-offs does not.

Customer discovery is a technical skill

An FDE Engineer does not need to become a sales person. They do need to learn how to turn a vague request into an observable workflow. Ask users to show the last real case. Ask where they stop, what they copy between systems, who checks the result, and what they do when information is missing. Those details are often more useful than a list of requested features.

AI delivery requires evaluation judgement

For AI systems, an FDE Engineer should understand retrieval quality, structured output, tool permissions, model limits, prompt injection, latency, token cost, human review, and failure handling. The point is not to use a model for every step. The point is to decide which parts should be deterministic, which parts can be probabilistic, and what evidence makes the result safe enough for the workflow.

Clear writing keeps delivery moving

An FDE Engineer writes short documents that teams can act on: a problem statement, scope, decision log, integration contract, evaluation plan, rollout checklist, and incident summary. Clear writing is not a soft extra. It prevents a customer conversation from becoming a week of conflicting implementation assumptions.

A practical path to become an FDE Engineer

You can transition into FDE Engineer work without abandoning your engineering base. Build the missing evidence in the order that real delivery demands.

1. Pick a real workflow

Choose a process with a named user and a concrete cost of delay. It can be internal. A support queue, research handoff, sales-engineering request, document review, or approval process all work if somebody genuinely performs the task. Do not start with a feature list. Write down the moment of friction and what a better outcome would look like.

2. Write the scope before the prototype

Create a one-page brief with users, job-to-be-done, inputs, outputs, sources, permissions, success measure, non-goals, failure path, and the smallest release group. This is the habit that turns a capable engineer into someone who can operate as an FDE Engineer under ambiguity.

3. Build one complete slice

Make the narrow workflow work end to end. Use real or carefully anonymised inputs. Add authentication, source handling, logs, errors, and a visible fallback. A tiny deployment that can be observed is more persuasive than a polished interface connected to fake data.

4. Create an evaluation set

Collect examples from the workflow. Include easy requests, likely failures, stale data, missing data, and cases that should be refused or escalated. Define what good, acceptable, and unsafe look like. An FDE Engineer portfolio becomes credible when it shows how the author learned from failure, not only a success screenshot.

5. Release to a small group and record the evidence

Ask a few users to use the system in their normal work. Track behaviour, correction rate, completion time, and qualitative feedback. Write down what changed next and why. If access to real users is impossible, be direct about the limitation and use a realistic, documented simulation rather than inventing business results.

What to put in an FDE Engineer portfolio

A hiring manager should be able to see your reasoning in a few minutes. Each FDE Engineer case study should include:

• The workflow and the people affected.
• The delivery brief, including non-goals and constraints.
• A system diagram showing data, permissions, models, tools, and human review.
• The evaluation cases, failure categories, and quality bar.
• The rollout plan, monitoring signals, and fallback.
• The outcome evidence, plus what you changed after observing use.

Code is still important. A repository without context is hard to assess, though. An FDE Engineer portfolio shows why a design choice was made, how it was tested, and what happened when it met real work.

Questions to ask in an FDE Engineer interview

The same questions help you assess whether a role is genuine field engineering or a vague catch-all title. Ask how the team chooses the first customer problem, who owns production reliability after launch, how evaluation is done, how travel and customer embedding work, which engineers build the system, and how field feedback changes the product. Ask for an example of a deployment that was narrowed, delayed, or rolled back. The answer reveals more than a generic promise of "customer obsession."

FDE Engineer FAQ

Does an FDE Engineer have to code every day?

Usually, an FDE Engineer needs to be able to contribute to code and make credible technical decisions. The daily balance varies. Some FDE Engineer roles are deeply hands-on; others lead the architecture and unblock a customer team while specialists own parts of implementation. In either case, the role requires enough depth to judge quality, risk, and delivery speed.

Can a backend or front-end engineer become an FDE Engineer?

Yes. Backend engineers often bring integration, reliability, and data strengths. Front-end engineers often bring workflow and usability judgement. To become an FDE Engineer, add discovery, scope writing, evaluation, rollout, and outcome evidence to those strengths. The transition is about widening responsibility, not discarding your speciality.

Is an FDE Engineer a consultant?

An FDE Engineer may use consulting skills, but the role goes further when it includes direct implementation and sustained production responsibility. A useful test is whether the FDE Engineer stays involved after the first release and can change the technical system when adoption or reliability exposes a problem.

How do I start if I have no customer access?

Start with a workflow inside your own team, volunteer organisation, or community. Be transparent about the setting. An FDE Engineer case study can still show discovery notes, a scoped build, evals, a release plan, and observed use without pretending to have enterprise-scale data.

Start with one honest delivery loop

The fastest way to prepare for an FDE Engineer role is to finish one small deployment that a real person can use. Build less. Observe more. Keep the evidence. Then repeat with a harder workflow.

Use the AI FDE learning path to practise discovery, scoping, prototyping, evaluation, productionisation, and adoption. The AI FDE online exam can help identify which field-delivery decisions deserve another round of practice.

Is this an official OpenAI or employer certification?

No. AI FDE is an independent learning and certification community. It is not operated by, endorsed by, or presented as an official credential from OpenAI, Anthropic, Palantir, or another employer. Certificates from this site record completion of this community's published assessment standard and should be paired with real project evidence.