Forward Deployed Engineer: What Is Forward Deployed Engineering?

If you run a consultancy, an agency, or an accounting or advisory practice, you may have heard an AI vendor offer a forward deployed engineer and wondered whether a business like yours needs one. Forward deployed engineering means that an engineer works inside a customer's own work, with the people who will use the system, and builds the solution there instead of handing over a finished product or a written specification. A forward deployed engineer (FDE) is the person in that role.

Our view is that your team probably does not need a full-time FDE. Whoever builds your AI should still work the way one does: learn your work first, build on your data and leave your people able to run the system. Below, we cover the role, why AI companies hire for it, where AI projects get stuck, and how to recognize this way of working.

What is forward deployed engineering, and what does a forward deployed engineer do?

An FDE works directly with a customer, finds the problem and builds a solution, often using the vendor's existing software platform. The role started at Palantir, by that company's own account: a biography of its chief technology officer, Shyam Sankar, submitted to a House committee, says he "envisaged the role of the Forward Deployed Engineer." A Salesforce blog post also says that Palantir "pioneered" it. A Palantir job posting says FDEs "work directly with customers to quickly understand their greatest problems," and it compares the responsibilities to those of a startup chief technology officer: owning the project from beginning to end.

Take a hypothetical small consultancy that wants a system to draft client proposals from past proposals and call notes. The question is who builds it and what they learn before they start. We’ll talk more about this later.

Why AI companies are hiring forward deployed engineers

Companies that sell language models hire FDEs because a customer who buys a model still has to connect it to its own work. Many cannot do that alone. The companies also learn from the work, because what an FDE finds goes back to the product team. Here are some examples of companies hiring FDEs.

The launch release for the OpenAI Deployment Company, published by founding partner Advent in May 2026, says it will "embed engineers specialized in frontier AI deployment," meaning putting advanced AI models into day-to-day use. It describes the work as "connecting OpenAI models to the customer's data, tools, controls, and business processes."

Anthropic's job posting describes an FDE "who embeds directly with our most strategic customers" and will "contribute insights back to our Product and Engineering teams." Its May 2026 announcement of a services company, which does not use the term FDE, says that putting Claude into core operations "takes hands-on engineering and deep familiarity with how each business runs."

Salesforce's blog said in November 2025 that the company had committed to a team of 1,000 FDEs. It described some working in pods of one deployment strategist, who helps choose the use case, and two FDEs, while many worked individually with a customer. Google also lists a Forward Deployed Engineer role on its careers site.

Why the hard part of an AI project is the context of your work

We think the hard part of an AI project is usually the context of the work: the documents, the exceptions, the approvals and the people who know how each is handled. That context lives with the customer, which is why the engineer needs access to the people doing the work. "Context" is our reading of the three sources below, and each has limits.

Stanford Digital Economy Lab's The Enterprise AI Playbook was published in April 2026 and studied 51 successful deployments at 41 organizations through interviews held between August 2025 and February 2026. It reports that 77% of the hardest challenges concerned change management, data quality and process redesign, and that models were fully interchangeable in 42% of implementations. The 77% is a share of challenges, not of companies. The report covers only successful cases and relies mainly on self-reported data, so it shows where those teams struggled and not how often projects succeed.

MIT NANDA's July 2025 report The GenAI Divide showcased January–June 2025 research that draws on over 300 public AI initiatives, interviews at 52 organizations and a survey of 153 senior leaders at four industry conferences. The authors attribute failures of custom and vendor-sold enterprise tools to fragile workflows, systems that do not learn from context and a poor fit with daily operations. One buyer told the authors, "Most vendors don't get how our approvals or data flows work."

The model still matters, since "Model output quality concerns" ranked second by reported frequency among the barriers, which the authors read as "model quality fails without context." They also warn of possible selection bias, so we treat the report as evidence of the problems participants described, not a market-wide estimate.

Deloitte's State of AI in the Enterprise 2026 press release covers an August–September 2025 survey of 3,235 business and IT leaders in 24 countries. It reports that 30% of organizations were redesigning key processes around AI, and that 37% reported surface-level AI use with little or no change to how the business worked. Those answers are self-reported and do not show that redesign causes better results, but they suggest that many companies have not changed the work around the tools.

In the proposal project example we mentioned earlier, the context is which past proposals may be reused, who sets the fee, which clients want their own format and what a partner removes before anything goes out. A written specification can miss those details if it is prepared without the people who write proposals, because they may carry that knowledge in their heads.

One process built two ways: a proposal-drafting project

The same project can go two ways, depending on when the builder meets the people who do the work.

Built from a specification. A partner and an operations lead write down what they want, and a developer who has never met the proposal writers builds from that document, using sample files. The demo looks good, but in daily use the draft reuses a fee from an old proposal and misses a second partner's sign-off on large work. The consultants end up checking every line, so they go back to the old way.

Built the forward deployed way. The engineer who will build the system sits in the interviews and watches a few proposals get written, which is where they learn who sets the fee and which past proposals are safe to reuse. The prototype runs on the consultancy's own proposals, in its own environment, and the writers correct it as it is built. The fee section stays blank, and the system holds the draft for a named partner's approval before it can be sent. At handoff, a named owner keeps the approved proposals current, with review points and a runbook (written instructions for running the system), and the team has been trained on live proposals.

What differs between the two is the order of the work, because the second builder meets the exceptions during the build and not after launch. That version asks for more of your team's time and does not guarantee a good result, but the training and handoff give your people a way to run the system and catch the mistakes that remain.

What forward deployed engineering means for a team your size

A vendor can justify a full-time FDE because it has many large customers and a steady flow of deployments. If your business has one or two systems worth building at a time, you may not have enough ongoing work for a full-time FDE, so the way of working matters more than the job title. You still have the problem the role solves, though: Anthropic says that companies such as community banks and mid-sized manufacturers "lack the in-house resources to build and run frontier deployments."

So look for the same way of working from whoever builds your AI: people who learn your work first, build on your data and leave your team able to run the system. Whether to hire someone, use a vendor's FDEs or work with a consultancy that builds is a separate decision, and a later article covers it.

This is almost exactly how we work. The engineers who sit in the interviews write the prototype, so there is no hand-off between the deck and the code. We build on your own data, in your environment, and training is part of every build. At handoff, you have a named owner, review points and a runbook.

Four signs you are buying the forward deployed way of working

You can check for this way of working on a call or in a proposal, whatever the provider calls it.

1. The people who will build it ask to talk to the people who do the work. Ask who sits in those conversations and whether the same person writes the code.
2. The first prototype runs on your data, in your environment. A demo on sample files cannot show how your documents and approvals will behave, so ask what the first version will run on.
3. Your team's corrections change the system during the build. Ask how your people will test it on live work, and where their exceptions and approval rules get written down. Your build partner should have a plan for User Acceptance Testing (UAT) with your team that occurs before launch.
4. The handoff is in the plan from the start. Look for a named owner, review points, a runbook and training, and ask who will change the system a month after launch. Our article on what an implementation engagement should deliver goes further.

Questions buyers ask

Is a forward deployed engineer the same as an AI engineer?

No, although one person can be both. "Forward deployed" says where and how someone works, while "AI engineer" says what they build with. Anthropic's posting describes both, and Palantir's posting describes the job without mentioning AI. When a provider offers you an AI engineer, ask whether that engineer will sit with the people who do the work.

Does a forward deployed engineer have to work in our office?

Not always. Palantir's posting says "often on site," but Salesforce's blog says, "Sometimes, they even travel to the customer," so being on site does not define the role. What matters is steady access to the people, the documents and the systems. Ask how the engineer will see the work being done, and who on your team will give them that time.

What does our team have to provide if we work this way?

Mostly time and a decision-maker, not engineers. The system depends on what your people know, so the builder needs interviews, access to the documents and quick answers when an exception turns up. Name one owner before the work starts, and block time for the two or three people who do the work most. If nobody can give that time, first decide whether to build anything at all.

You do not need the job title, but you do need builders who learn your work first and leave your team able to run the system. See how we build agentic systems with your team.