Forward Deployed Engineers (FDEs): Why AI Companies Are Sending Engineers to Customer Sites

Over the past two years, a new role has been appearing again and again in AI companies' job listings: the Forward Deployed Engineer, or FDE. Rather than building general-purpose products at headquarters, FDEs take models and platforms into customer organizations and work alongside business teams to connect AI to real data, processes and systems. The rise of the FDE makes one thing clear: the hardest part of AI adoption is not the model itself, but the “last mile” inside the customer's organization.

So what exactly does an FDE do? And why are model companies such as OpenAI and Anthropic building these teams at scale? In this article, we cover what the FDE role means and where it came from, why AI companies are building FDE teams, why AI adoption needs this kind of role, how FDEs differ from several similar roles and what skills they need, and how companies can work with FDEs and develop their own “in-house FDEs”.

What is a Forward Deployed Engineer (FDE)?

An FDE is a software engineer stationed alongside the customer. FDEs write code, build data pipelines and configure systems, but they serve one specific customer rather than “all customers”, and they are measured by whether that customer's business problem gets solved. A typical engineer builds one feature for many customers; an FDE combines many features for one customer.

The role first became widely known through the data analytics software company Palantir (source). In its official blog post “Dev versus Delta”, Palantir distinguishes between two kinds of engineers. Software engineers in product development (known internally as “Dev”) build a specific component of the platform and focus on “one capability, many customers”. Forward deployed software engineers in business development (known internally as “Delta”) are organized into teams around a single customer and focus on “one customer, many capabilities”; their success is judged by the customer's business outcomes, such as whether defects on a production line go down (source). The Deltas interviewed in the post spend a substantial part of each week on customer sites.

Another Palantir blog post sets out an FDE's day-to-day work: designing, developing and deploying bespoke workflows and data models for customers; building and maintaining the large-scale data pipelines that keep the business running; configuring access controls in line with regulatory and compliance requirements; owning the stability, upgrades and monitoring of production systems, and tracing the root cause when something fails; and feeding what they learn on site back to the product team, so that broadly useful solutions are built into the platform (source).

Notably, Palantir deliberately distinguishes FDEs from consultants. As it puts it, FDEs work with an existing software platform and components, and their aim is to build systems the customer can use for the long term — not to produce one-off analytical reports or assemble a custom solution for every client. This is the most fundamental difference between FDEs and traditional consulting: what they deliver is a system that keeps running, not advice.

Why are AI companies building FDE teams?

Model companies looked more like “standard product” vendors than almost anyone, yet they too have started sending engineers to their customers. The reason is straightforward: customers who buy a model are not necessarily able to put it to work — and if they can't, contracts are hard to renew and expand.

Several pieces of public information illustrate the trend:

• Demand for the role is rising fast. In November 2025, eWeek, citing the Financial Times, reported that OpenAI, Anthropic, Cohere and others were all expanding their FDE teams; data from the job site Indeed showed that FDE job postings grew by more than 800% between January and September 2025 (source). Note that this is a relative increase; it does not mean the absolute number of such roles is already large.
• Model companies are scaling up. The same report noted that OpenAI set up its FDE team in early 2024 and planned to grow it to around 50 people in 2025, while Anthropic planned to expand its applied AI team, including FDEs, fivefold in 2025.
• Deployment has become a business in its own right. In May 2026, OpenAI announced the launch of a separately operated deployment company, the OpenAI Deployment Company, with initial investment of more than USD 4 billion, led by TPG and joined by 19 investment firms, consultancies and systems integrators. It also announced the acquisition of the applied AI consultancy Tomoro, expected to bring in around 150 FDEs and deployment specialists (source). As OpenAI describes it, these FDEs will go into customer organizations, identify where AI can have the greatest impact, redesign processes and infrastructure around it, and connect models to the customer's data, tools and workflows.
• Job requirements are spelled out in detail. Anthropic's current FDE job posting states that the role sits within the Applied AI team, embeds with key customers, builds production-ready applications on Claude, and involves 25% to 50% travel to customer sites (source).

In a June 2025 article, the investment firm a16z called this approach “services-led growth”: enterprise AI products require a great deal of implementation work, so startups may do well to accept lower gross margins early on and use deep services to bring customers' processes and data on board first (source). In other words, FDEs are both a delivery mechanism and a way for AI companies to put down roots inside their customers.

Why does AI adoption need a role like the FDE?

Large models are general-purpose; a company's business is specific. A model knows what a “return” is, but it doesn't know how many approval steps a return goes through at your company, which system holds the data, or which customers are covered by exception policies. Bringing that specific knowledge in is the “last mile” of AI adoption.

This last mile usually gets stuck in three places:

• Data. Company data is scattered across ERP, CRM, warehouse systems, spreadsheets and email, with inconsistent definitions and differing access rights. For AI to answer “why hasn't this order shipped yet?”, it has to be able to read order, inventory and logistics data securely.
• Processes. Real business processes are full of rules and exceptions that were never written down. Even for purchase requests, for example, amounts above a certain threshold need the general manager's sign-off, and some suppliers require additional quotes. These rules only come to light when they are mapped out on site with frontline staff.
• Systems. For AI recommendations to become actions, they have to be written back into business systems: creating tickets, updating inventory, generating invoices. Whether the interfaces are stable, how failures are handled and who is authorized to execute them all call for engineering judgment.

The a16z article also notes that AI agents need secure connections to a company's internal databases, APIs and workflows, as well as an understanding of business logic and history; putting an agent to work is much like onboarding a new employee (source). The traditional division of labor often falls short here: product teams are too far from the customer to see the specific problems; implementation consultants understand processes but may not be able to write code or tune models; and a company's own IT team knows its systems but may not be familiar with the characteristics and limitations of large models. The value of the FDE lies in bringing business knowledge, systems knowledge and model knowledge together in one person or one small team.

For example, a wholesale distributor wants AI to automatically process orders that customers send by email. In the demo, the model accurately extracts products and quantities from a neatly formatted email. On site, however, the FDE discovers that customers use their own shorthand for product names, some orders arrive as scanned handwritten forms, and some require a credit-limit check first. Only once the product mapping table, the credit rules and the process for routing exceptions to staff are all connected does the AI become genuinely usable.

How do FDEs differ from software engineers, implementation consultants and pre-sales engineers?

FDEs are easily confused with several similar roles. Put simply, an FDE stays as close to the customer as an implementation consultant, builds systems hands-on like a software engineer, and is accountable for business outcomes after go-live.

The table below compares the four roles across several dimensions:

Companies do not all define these roles in the same way; the table reflects a common division of responsibilities and is for reference only.

What skills does a good FDE need?

The FDE skill set is “T-shaped”: deep engineering ability combined with broad business understanding and communication skills. What is scarcest is not any single skill, but the ability to keep things moving independently in an ambiguous, constantly changing customer environment.

Based on Palantir's role descriptions and Anthropic's job requirements, these skills fall into five categories:

• Solid engineering skills. Able to write production code, build data pipelines and handle systems integration. Anthropic's job posting asks for experience using large models in production, including prompt design, agent development and evaluation methods, as well as proficiency in Python (source).
• Learning unfamiliar domains quickly. Today it might be a manufacturer's quality inspection process; next month, a logistics company's dispatch system. Palantir lists “quickly getting up to speed on unfamiliar systems, domains and codebases” among the abilities an FDE needs (source).
• Translating business problems into technical solutions. Able to listen to business users' complaints, probe for the real problem behind them, and then decide what to hand to AI, what to handle with rules and what not to do at all.
• Communication and building trust. FDEs deal with frontline staff, the IT department and management at the same time, while also coordinating with their own company's product team. Anthropic's job posting explicitly expects FDEs to work autonomously, stay effective amid uncertainty and communicate well.
• Owning outcomes. An FDE's work does not end when the demo succeeds. It extends to tracking the system's stability and business impact after go-live, and distilling reusable practices into methods that are fed back to the product team.

How can companies work with FDEs or develop their own “in-house FDEs”? A step-by-step guide

For most small and mid-sized businesses, a model company's FDEs are unlikely to turn up at the door. But the FDE way of working is well worth adopting. Whether you partner with an external team or develop talent internally, the key is to have people who understand the business and people who understand the technology working side by side on the same concrete problem.

Step 1: Start with a specific, measurable business problem. Don't start from “we need to use AI”; start from concrete pain points such as “order entry ties up three people every day” or “month-end reconciliation takes a week”. OpenAI likewise describes its deployment service as beginning with a focused diagnosis and then concentrating on a small number of priority workflows (source).

Step 2: Prepare data and system access in advance. What FDEs most often find themselves waiting for is data and permissions. Before the engagement starts, be clear about which systems need to be connected, who approves access, and which data must not leave the company, so that engineers aren't left idle once they arrive.

Step 3: Appoint a business owner who stays involved throughout. However capable an external FDE may be, they won't know your exception rules and unwritten conventions. You need a business owner who knows the processes and has decision-making authority, who reviews progress with the FDE every week, answers questions and makes the call on trade-offs.

Step 4: Build together on site, in small, fast iterations. Seat the FDE next to the business team, start with a minimal version that can handle real documents, then refine it step by step based on frontline feedback. Every iteration should be tested on real data, not judged on how the demo looks.

Step 5: Set up operations and handover at go-live. Make clear who handles system issues, who decides on model or process changes and where operation logs are kept. Before the external team leaves, documentation, training and access handover should be complete, so the system doesn't depend on any single outside person.

Step 6: Develop in-house FDEs through the engagement. Choose one or two employees who understand the business and are keen to learn the technology — for example, an IT engineer who often works on the ground with business teams, or a data-savvy key business user — and have them work alongside the external team throughout, gradually taking the lead from the second project onward. The value of in-house FDEs is that your next AI project doesn't have to start from scratch.

Frequently asked questions about Forward Deployed Engineers (FDEs)

How is an FDE different from outsourced development? Outsourced development usually delivers features against a requirements document that the customer has written. FDEs, by contrast, discover and define problems together with the customer, are accountable for business outcomes, and build solutions on existing platforms and products rather than developing from scratch.

Do small and mid-sized businesses need to hire dedicated FDEs? Not necessarily. A more realistic approach for SMBs is to have key internal staff take an active part when working with an external team, gradually developing one or two “in-house FDEs” who combine business and technical skills.

With demand for FDEs growing so quickly, is this just a passing trend? The job title may change, but the need behind the role is unlikely to disappear: as long as models are general-purpose and businesses are specific, someone has to connect the two. As tools mature, some integration work will become easier, but understanding the business and owning outcomes will still depend on people.

How should you judge whether an FDE engagement has succeeded? Look at three things: whether the system is genuinely in daily use, whether the agreed business metrics have improved, and whether the company can maintain and extend it on its own after the external team leaves. Looking only at demo results or the number of features delivered tends to overstate what has been achieved.

References

• Dev versus Delta: Demystifying engineering roles at Palantir, Palantir official blog, no publication date given (accessed November 2026)
• A Day in the Life of a Palantir Forward Deployed Software Engineer, Palantir official blog, no publication date given (accessed November 2026)
• Why Forward-Deployed Engineers Are in High Demand, eWeek, November 2025
• OpenAI launches the Deployment Company, OpenAI, May 2026
• Forward Deployed Engineer (job posting), Anthropic, accessed November 2026
• Services-Led Growth, a16z, June 2025