A forward deployed engineer (FDE) is a customer-facing engineer who helps make a technology work inside a customer's actual operation. In an AI project, that can mean understanding a workflow, connecting the relevant systems, evaluating the output and making the result maintainable.
The title alone does not define a standard job. Companies divide responsibilities differently. OpenAI describes hands-on deployment work alongside customers; Palantir distinguishes customer-specific technical outcomes from its broader product-engineering remit. Those descriptions establish what the role can involve, not how fast the whole job market is growing.
What an FDE Does That a Demo Does Not Show
A demonstration asks whether an approach can work. Deployment asks whether the right people can use it repeatedly, with current information, appropriate access and a way to handle failure. Our AI product-workflow article explains why a prototype does not establish customer demand or production readiness.
Consider a tuition centre evaluating an internal assistant for staff questions about class changes. A demo can answer from a few uploaded documents. The operational problem is harder: which policy is current, which classes it covers, who may see it, and what happens when the answer is missing? This is an illustrative project, not a deployment or result we are claiming.
Follow One Workflow Through the System
First define the task narrowly: help an authorised staff member find the applicable class-change policy and its source. That is different from letting an assistant change a student's booking. Keeping the first scope read-only avoids treating an answer as permission to act.
Next, identify the approved documents, their owners and update process. Connecting a folder is insufficient if it contains conflicting policies or exposes material the staff member should not see. The engineer and the centre's policy owner need to resolve those conditions together.
One possible implementation retrieves relevant passages before generating an answer, commonly called retrieval-augmented generation (RAG). Retrieval supplies context; it does not guarantee that the selected passage is current or that the answer follows it. The system still needs access checks, source handling and evaluation.
Evaluate the Work, Not the Presentation
Prepare representative questions with answers checked by the policy owner. Include a normal class change, an outdated document, a question outside the policy and a document the user cannot access. Check the returned answer, supporting source and escalation behaviour.
For example, a question about an unconfirmed exception should reach the responsible person rather than produce an invented permission. Record the expected behaviour before testing, then keep the failures and decisions. A fluent answer or a model benchmark cannot replace these workflow-specific checks.
After a controlled pilot, assess the work in use: correct answers, inappropriate disclosures, escalation, staff effort and maintenance. Define acceptable limits with the business before expanding access. No single accuracy percentage establishes that every deployment is safe or useful.
Make the Handoff and Product Feedback Explicit
The centre needs to know who updates policies, reviews recurring failures, manages access and handles outages. A working prototype without those owners leaves an unfinished service. The handoff should include the evaluation set, known limits and a route back to a human.
Some deployment problems are specific to that centre. Others may reveal a missing capability that several customers need. Feeding the second group back to the product team helps distinguish reusable improvements from a growing collection of one-off customisations.
Where the Role Overlaps Other Teams
Product engineers generally build and maintain shared capabilities. Product managers help decide which customer problems and product priorities deserve work. Sales engineers, implementation partners and customer-success teams may also help with discovery, integration and adoption. These are overlapping responsibilities, not fixed boundaries that apply to every company.
For a small business, the practical question is who can own the integration and its operation. A supported existing feature may need configuration rather than a dedicated FDE engagement. A novel workflow crossing data, permissions and product limitations needs clearer engineering responsibility. Choose the work required before choosing the job title.
Frequently Asked Questions
Is an FDE a Software Engineer?
Usually the role includes hands-on engineering, with a stronger customer-deployment focus. The actual balance of coding, integration, discovery and support depends on the employer and project.
Was the FDE Role Invented for Generative AI?
No. Customer-facing forward deployed engineering predates the recent generative-AI wave. AI introduces particular evaluation and integration problems; it does not make the underlying role entirely new.
Does Every Business Using AI Need an FDE?
No. Start with the workflow and the gap in existing capabilities. A straightforward supported setup may not need this role; an uncertain deployment needs an accountable technical owner, whatever that person's title.