Source: https://oguzerol.com/en/forward-deployed-ai-engineer-guide/ # What Is a Forward Deployed AI Engineer, and What Do They Do? [Oğuz Erol](https://oguzerol.com/en/about-me/) | 13 min read | Published: 31 October 2026 ## Key takeaways - An FDE learns the business need with users and takes a technical role in developing the solution and putting it into real use. - The work goes beyond prompts: data, code, integration, evaluation, access and operational responsibilities need to be addressed together. - The scope varies by company. Some teams work closely with product and research; others focus on application or infrastructure delivery. - In my custom application work, I consider the process, user roles and data connections together. **A Forward Deployed AI Engineer is a technical role focused on bringing AI into a business’s working environment.** They learn the process with the people doing the work, connect the relevant data and systems, develop the solution and evaluate how it performs in everyday use. The usual abbreviation is **FDE**. Responsibilities vary with the company, product and customer need. A model producing a good answer and an employee completing a task are different achievements. FDE work addresses that gap: finding the right record, preserving permissions, checking the outcome and making the solution usable by the team. I’m Oğuz Erol. The connection to my work is how I consider processes, user roles and data connections together when developing [custom web applications for businesses](https://oguzerol.com/en/custom-web-apps-for-your-team/). This guide first explains the role, then shows how the approach could apply to a practical task. ## What does the FDE name mean? **“Forward deployed” describes working close to the customer or the team doing the work.** It means more than deploying software to a server. “Forward Deployed Engineer” is the broader title, while “Forward Deployed AI Engineer” makes the AI focus explicit. “FDSE” stands for the software-focused “Forward Deployed Software Engineer”. Palantir’s FDSE posting combines working alongside customers, building custom applications and technical ownership from an idea through to deployment. It shows how the role can extend beyond making recommendations. It does not establish identical responsibilities at every company using the title. [Palantir’s role description](https://jobs.lever.co/palantir/dab396d4-2f14-4796-aac0-0d82883dccf0) The “customer” need not always be an external buyer. A finance or operations team inside the organisation could be the user. To understand a role, look beyond the title to whose problem it addresses and where technical delivery ends. ## What does an FDE do? **They turn an uncertain need into technical work with a defined scope and a way to check the result.** “Let’s use AI to speed up reporting” is not an application specification until the team understands which records to compare and who retains each decision. An FDE’s responsibilities can include: 1. **Understand the work:** Observe how an employee completes a record, where they wait and how they handle exceptions. 2. **Establish data and access:** Identify the authoritative information, permitted reads and writes, and the owner of each connection. 3. **Choose the first scope:** Agree on the task, exclusions and acceptance conditions. 4. **Build the solution:** Code the required interface, services, data flows, model calls and integrations. 5. **Verify behaviour:** Test missing, incorrect, repeated and unauthorised inputs alongside ordinary records. 6. **Put it into use:** Establish monitoring, failure handling, cost visibility and ongoing responsibility. 7. **Carry the learning forward:** Turn a useful approach into a reusable component, product improvement or next development step. This sequence is my synthesis of the roles reviewed, not a claim that all companies follow one procedure. Databricks’ AI FDE posting describes developing and bringing customers’ GenAI applications into production within professional services engagements. [Databricks AI FDE posting](https://www.databricks.com/company/careers/professional-services-operations/ai-engineer--forward-deployed-engineering-ai-fde-8546367002) ## What could a working day and its deliverables look like? **A day can move between working with users and writing code.** Watching an employee resolve a pending record, fixing an API failure, checking example outputs and trying the design with the team could all belong to the same task. This is an illustrative day, not a standard schedule. | Work | A possible concrete deliverable | | --- | --- | | Learning the process | A workflow showing inputs, decisions, owners and exceptions. | | Design | A data model, integration boundaries and acceptance criteria for the first version. | | Development | A working screen, service, integration or model-powered component. | | Evaluation | Representative test records tracking expected outcomes and failures. | | Rollout | Access roles, monitoring, rollback and usage notes. | | Handover | A clear record of who owns the code, accounts and maintenance work. | Not every project needs these deliverables in the same form. The point is to have more than a presentation or screenshot. The team should be able to explain how the system selects the right record, what it does when it fails and who continues the work. ## Why does putting the solution in users’ hands matter? **Actual use exposes gaps that a design on paper may miss.** An application may extract data correctly while leaving an employee confused by its correction screen. An answer may be accurate against a document that is no longer current. Changing the model’s reply alone will not solve either problem. OpenAI’s own FDE model emphasises learning in production and feeding findings back to Product and Research. The same page distinguishes its FDEs from professional services, describing work with implementation partners on problems at the frontier of existing AI capabilities. That is **OpenAI’s organisational choice**, not a universal description of FDEs or independent developers. [OpenAI’s FDE model](https://openai.com/business/forward-deployed-engineering/) Useful feedback is more specific than “the user liked it”. Where did work stop? Was data missing, access incorrect or the model inadequate? Is the fix unique to one customer, or could it benefit other product users? These questions connect a local correction to shared product development. ## How is FDE different from AI engineering, consulting or prompt engineering? **The difference is usually the centre of responsibility, rather than a firm boundary between professions.** Consultants can write code, AI engineers can work with customers, and product teams can own production delivery. | Role | Typical focus | Where it overlaps with, or differs from, FDE | | --- | --- | --- | | Software engineer | Developing products and systems. | Resolving incomplete requirements in a customer environment can be more prominent in FDE work. | | AI engineer | AI applications, evaluation and infrastructure. | An FDE may also own user discovery and adoption in the customer environment. | | Prompt engineer | Model instructions and output behaviour. | An FDE’s scope can extend to data, interfaces, permissions, integrations and operations. | | Solutions architect / engineer | Solution fit, architecture and the technical relationship. | Production-code ownership and specialist depth vary with the employer. | | Implementation consultant | Adapting processes and putting solutions into use. | Technical delivery can overlap; the label alone does not establish how much coding is involved. | Together’s inference-focused FDE posting, concerned with running models, describes a deep-domain specialist working alongside a solutions architect, rather than replacing one. The same FDE title can point towards applications in one company and model-serving infrastructure in another. [Together’s role description](https://job-boards.greenhouse.io/togetherai/jobs/5131941007) When assessing a job or engagement, ask who writes the code, puts it into use, makes decisions with the customer and operates it afterwards. Those answers explain more than the title. ## Which skills need to work together? **Software development and business problem-solving need to reinforce each other.** APIs, SQL, data modelling, authentication and failure handling sit beneath the AI layer. Using a model does not remove those requirements. Structured output, source-grounded answers, tool calls and evaluation may matter on the AI side. Evaluation checks whether the system performs the intended task on representative records. A few successful answers are insufficient; the team also needs to understand where and why it fails. Scale’s posting treats evaluation datasets, regression checks, monitoring and human oversight as production engineering work. [Scale’s engineering scope](https://scale.com/careers/4694861005) Technical decisions must also be understandable to users. When a manager asks why an integration is waiting, the answer needs to explain the dependency and business impact, rather than simply name a tool. In [RAG applications](https://oguzerol.com/en/what-is-rag-ai-that-answers-from-your-documents/), which support answers with retrieved documents, source freshness and user permissions also need to be designed together. ## Example: turning purchasing records into a working workflow **The following is a design that could be developed, not a completed customer case or a claimed result.** Imagine a company keeping purchase orders, delivery records and invoices in different places. Accounting manually works out which document belongs to which order. ### First understand the work and what the records mean The first question is not which model to use. Who opens the purchase order, how are partial deliveries recorded, and who can accept an invoice discrepancy? An employee walks through a representative record from beginning to end. Missing deliveries, returns and document corrections may require separate paths. Record the starting position: where work waits, which fields are re-entered and which differences need investigation. Do not present an unmeasured time-saving percentage as the target. The first scope could be limited to finding discrepancies and presenting them to an authorised person. ### Separate AI, rules and human decisions AI could extract an invoice’s date, amount and description as draft fields. Software applies the defined calculation and duplicate-checking rules. An uncertain match goes for review instead of being finalised automatically. An authorised employee sees the document beside the source record and accepts or corrects the result. Data could come from a permitted API or, initially, an uploaded file; these are different connection arrangements. The available option must be verified. Screens show fields according to the employee’s role. Approval does not automatically confer authority to initiate a payment.  An illustrative purchasing workflow, not a customer result or a ready-made integration. ### Test with the employee and verify delivery What happens when the same invoice arrives again? Could a connection failure lose an approved operation? Can a user see an order they are not authorised to access? Testing includes these questions. The employee completes the task in the application, and the team reviews the sticking points and corrections. The deliverable is more than a screen displaying extracted fields. It includes the discrepancy list, review record, permitted writes, change history and a clear owner for failures. Official accounting entries or bank operations require separate scope. The team that will maintain the system also needs to be identified. This is where the approach connects with my custom application services: I can bring records, user roles and approvals together around a working process. ## When does the FDE approach make sense, and when is it unnecessary? **The approach becomes more useful when there is uncertainty, integration work and a need to learn alongside users.** A meaningful business problem, people who understand the process and accessible data also matter. - People repeatedly move information manually between systems. - An initial prototype works, but has not become part of daily work. - Exceptions make a single rule or standard product insufficient. - Learning from use is expected to improve a shared product or reusable solution. By contrast, a setting in existing software may solve the problem without a new application. Conventional software or an available integration may be enough for a simple task with clear inputs and outputs. Calling every custom development project FDE does not explain its scope more accurately. If the data is inaccessible or no user owns the process, address that first. A technical team building an application does not take over the business’s decisions and adoption responsibilities. Building the system and establishing its use need to be planned together. ## What does LinkedIn’s FDE demand figure tell us? **There is an official indication that the role is visible in hiring.** On 29 September 2026, LinkedIn reported a 226% increase in demand for forward-deployed specialists over the preceding year. The metric’s geographic scope and calculation are not fully detailed, so I do not use it as a Turkish vacancy-growth rate, search volume or job guarantee. [LinkedIn’s announcement](https://news.linkedin.com/2026/hiring-assistant-2) This figure alone does not determine which working model a business should choose. Continuing product development may call for an internal team; a defined need may suit a project engagement. Required technical ownership matters more than a fashionable title. ## Frequently Asked Questions ### Are FDE and FDA the same abbreviation? FDE is the usual abbreviation here: Forward Deployed Engineer. AI-focused work may also use AI FDE. Those terms are a useful starting point for research, but the actual responsibilities still need to be read. ### Does an FDE only advise customers? Many roles include building the application and bringing it into real use. Boundaries between consulting, product and engineering vary by company. Establish which code and technical deliverables are expected alongside the conversations. ### What is the main difference between an FDE and someone writing prompts? A prompt is an instruction directing model behaviour. An FDE’s scope may also include the data behind that behaviour, the user interface, the checks applied and the connections to other systems. A good prompt alone does not replace those deliverables. ### Does every FDE train models? No. Some roles integrate existing models into applications; others specialise more deeply in inference or model adaptation. A training requirement comes from the particular role, not the shared title. ### Does every project need an AI agent? No. A simpler application may be sufficient when the steps and decision rules are known. AI can handle a bounded task such as extracting document fields or preparing a draft. Each step need not become an independently deciding agent. ### Does “forward deployed” mean working at a customer’s office every day? The title alone does not specify that. Close work with users and customers is expected, but office, remote and travel arrangements differ. Regardless of physical location, access to the people doing the work and opportunities to test with them are important. ### Does the work end at launch? Use can expose failures, data changes and new needs. Ownership of maintenance, monitoring, corrections and handover should be explicit. There is no universal rule that an FDE personally owns these indefinitely. ### Why does human approval matter in an FDE project? A suggestion and a hard-to-reverse action carry different consequences. Payments, critical deletion and firm customer commitments need suitable authority and checks. Place human approval according to the possible failures and acceptance conditions of the task. ### How is success measured? Define the current position and intended task first. Appropriate measures might include completion time, repeated data entry, failure types or resolved exceptions, compared under consistent conditions. A plausible model answer alone does not prove a better business outcome. ### Does a company have to hire an FDE? No. Continuing product and customer delivery may need a team; a particular task may suit a project or shared responsibilities with an existing team. Technical ownership, access, user involvement and ongoing responsibility need to be clear in the chosen arrangement. ## Connecting the approach to your own work If a task is split across Excel, a CRM and customer communications, start by identifying where it begins, its decisions and who owns it. As Oğuz Erol, I can develop custom applications for these processes, adding AI where appropriate and focusing on whether users can complete the work. Use the [contact page](https://oguzerol.com/en/contact/) to briefly describe the workflow and systems involved. A paid scoping discussion establishes which part could be developed and how it would be verified. *Sources reviewed as of 31 October 2026. The working day and purchasing example are illustrative.* [Back to top ↑](https://oguzerol.com/en/forward-deployed-ai-engineer-guide/#icerik)