Within nine weeks in mid-2026, Anthropic, OpenAI, Amazon Web Services and Microsoft each launched a new company or unit built on one premise: an AI model starts paying for itself only once an engineer sits inside the customer's business, wiring it into real data, permissions and workflows. That engineer is the forward-deployed engineer, a role Palantir created more than a decade ago and the rest of the software industry long treated as an expensive exception.
This guide explains what a forward-deployed engineer (FDE) does, how the AI FDE differs from Palantir's original, what the role pays, and how it compares with solutions engineers and consultants. It is written from the side most FDE articles skip: the company receiving the engineers, which has to decide whether to accept a vendor's team, hire its own or embed a vendor-neutral partner without giving away ownership of the result.
What is a forward deployed engineer?
A forward deployed engineer is a software engineer who works inside a customer's organization, writing and shipping production code in the customer's own environment until a product delivers a specific, measurable result there. The title comes from Palantir, where these engineers are Forward Deployed Software Engineers, known internally as Deltas after early business development teams named for letters of the NATO alphabet.
Palantir's own shorthand remains the clearest definition in circulation: a product engineer builds one capability that many customers will use, while a forward deployed engineer builds many capabilities for a single customer, with success measured against that customer's goal rather than adoption across a user base.
The job now travels under several labels, including forward deployed software engineer (FDSE), applied AI engineer, AI deployment engineer and, at some consultancies, forward deployment engineer. Anthropic's FDEs, for example, sit inside its Applied AI team, which is why the scope written into a posting tells you far more than the title on it.
Quick test: a role is genuinely forward deployed when the engineer writes production code, stays accountable for that code after it goes live, and feeds what they learn back into a product. Take away any one of the three and you are looking at presales, support or consulting under a newer title.
What does a forward deployed engineer do all week?
A forward deployed engineer's week moves between discovery, building, deployment and product feedback, with the mix shifting as an engagement runs from kickoff to handover. OpenAI's current forward deployed engineer job description captures the span, giving its FDEs ownership of discovery, technical scoping, system design, build and production rollout, and the same four kinds of work appear in almost every serious posting:
- Discovery where the work happens. Sitting with the people who run the process to learn where the data lives, who approves what, and what finished means to them, which is rarely what the kickoff deck says.
- Building inside the customer's systems. Writing integrations, data pipelines, agents and interfaces against the customer's real identity provider, network rules and legacy databases.
- Deployment and adoption. Shipping to production, fixing what breaks when real users arrive, and staying until the workflow owner can point to a changed number.
- Feedback into the product. Codifying the patterns that repeat and reporting the gaps, so the next customer needs less custom work, a duty Anthropic writes directly into its FDE posting.
Travel is part of nearly every forward-deployed engineer job, with Anthropic's current posting estimating about 25% travel to customer sites and OpenAI's San Francisco role requiring up to 50%. One of Palantir's own Deltas describes the rhythm as a couple of days most weeks at the customer's premises, with the rest spent on code, reviews and planning.
What is an AI FDE, and what changes when the product is a model?
An AI FDE, or AI forward deployed engineer, is a forward deployed engineer whose job is to take models and agents into production inside a customer's operation. Andrew Ng describes the role as an engineer embedded with a client to build and tune agentic workflows for that client's needs, and ties its resurgence to how much work it takes to turn an off-the-shelf model into a custom workflow.
Frontier labs describe the deliverables in unusually concrete terms, with Anthropic's FDE posting listing technical artifacts such as MCP servers, sub-agents and agent skills for production workflows, and asking for hands-on experience with prompt engineering, agent development and evaluation frameworks. OpenAI says its Deployment Company FDEs connect models to a customer's data, tools, controls and business processes.
| Classic forward deployed engineer | AI forward-deployed engineer | |
|---|---|---|
| What gets deployed | A data or software platform | Models, agents and the systems around them |
| Typical artifacts | Data integrations, pipelines, custom applications | MCP servers, sub-agents, retrieval pipelines, evaluation sets, guardrails |
| Hardest technical problem | Messy data and legacy integration | Messy data plus outputs that are not deterministic |
| Proof that it works | The workflow runs on the platform | The workflow runs, and evaluations show accuracy the business accepts |
| Pace of change | Product release cycles | Frequent model and platform updates |
The change that matters most is nondeterminism, because a classic integration either passes its tests or fails them, while an agent can answer correctly for a week and then drift after a model update. An AI FDE therefore has to leave behind an evaluation set and monitoring that the customer's own team can run long after the engagement ends.
Salesforce FDE director Sarah Khalid has described the same shift from the inside: agentic work is less black and white than coding, prompt and instruction writing were new to her toolkit, and the platform's release pace went from three releases a year to weekly or biweekly.
Why is every major AI vendor building an FDE team?
Every major AI vendor is building a forward-deployed engineering team because enterprise AI hit a deployment wall rather than a capability wall, with models good enough for real work but most companies unable to connect them to their own data, workflows and controls.
The clearest measure of that wall is MIT NANDA's GenAI Divide report, built on a review of more than 300 public AI initiatives, interviews with 52 organizations and a survey of 153 senior leaders. It found 95% of organizations getting zero return from generative AI, and among enterprise-grade tools, 60% of organizations evaluated one, 20% reached a pilot and just 5% reached production.
Hiring data moved the same way, with Indeed figures shared with Business Insider putting its index of forward-deployed engineer job postings 543% above its January 2025 baseline in April 2025, and 5,230% above it by April 2026, roughly 729% growth in twelve months.
Read that number carefully: these are index values against a baseline, not counts of job ads. Business Insider corrected an earlier version of its story that presented them as individual postings, and plenty of guides still repeat the uncorrected figures.
The vendors reorganized around the role within months, and the 2026 sequence below shows how quickly forward-deployed engineering moved from one analytics company's model to a standard part of how enterprise AI is sold:
| When | Who | What happened |
|---|---|---|
| March | Salesforce | Reported it had tripled its FDE team in six months, drawing on engineering, professional services and customer success |
| May 4 | Anthropic, with Blackstone, Hellman & Friedman and Goldman Sachs | Announced an AI services firm for mid-sized companies, launched as Ode with Anthropic on July 15 |
| May 11 | OpenAI | Launched the OpenAI Deployment Company with more than $4 billion in initial investment and agreed to acquire Tomoro, adding about 150 FDEs and deployment specialists |
| May | Google Cloud | CEO Thomas Kurian said the company was ramping up FDE hiring |
| June 30 | AWS | Committed $1 billion to a Forward Deployed Engineering organization of thousands of engineers |
| July 2 | Microsoft | Launched Microsoft Frontier Company, a $2.5 billion business with 6,000 industry and engineering experts embedded with customers |
| September 8 | Accenture and Google Cloud | Formed a Gemini Enterprise business group that will establish a 1,000-person FDE workforce |
Microsoft is the one vendor that argues with the label, with Judson Althoff, CEO of its commercial business, writing that the Frontier Company goes beyond what has been labeled forward deployed engineering. The model is still recognizably the same, with industry and engineering experts embedded inside customers to deploy AI systems against measurable business outcomes.
Forward-deployed engineer vs solutions engineer, consultant and architect
The difference is what happens after the sale: a forward deployed engineer writes production code in the customer's environment and stays accountable for a live result, a solutions or sales engineer proves technical fit to win the deal, a solutions architect designs the target system, and a consultant assesses and recommends, often leaving before anything runs in production.
| Role | Main job | Writes production code? | Accountable for | Leaves when |
|---|---|---|---|---|
| Forward deployed engineer | Make one customer's deployment deliver a result | Yes, in the customer's environment | A changed business metric in live use | The customer can run the system alone |
| Solutions or sales engineer | Demonstrate and configure before purchase | Rarely, mostly demos and proofs of concept | The technical win in the sale | The contract is signed |
| Solutions architect | Design the target architecture | Sometimes, usually reference builds | A design others can build | The design is approved |
| Consultant | Assess, recommend and plan | Usually not | Recommendations and roadmaps | The statement of work ends |
| Implementation engineer | Configure a product to a fixed scope | Configuration and scripting | Delivering the agreed scope | The scope is complete |
Khalid separates the last row from the first neatly, arguing that implementation teams build the solution while forward deployed engineers make sure it actually drives value. That is why a good FDE arrives without a fixed list of deliverables and stays tied to the customer's business outcome until it is met.
Is forward deployed engineering just consulting with a new title?
Palantir's engineers answered this long before the current wave, describing consultants as producing a one-time analysis, recommendation or solution, while a Delta builds a long-term solution with the customer and does far more engineering along the way. AWS draws the same line for its new FDE organization, contrasting it with consulting that assesses, recommends and treats each deployment as a standalone project.
The title is being stretched in both directions, so the quick test above still earns its place: McKinsey's QuantumBlack advertises a principal forward deployment engineer role asking for more than eight years of hands-on software, platform or infrastructure engineering, while other listings attach the label to go-to-market jobs that ask for presales experience.
How much does a forward deployed engineer earn?
Forward deployed engineer salary levels sit closer to senior software engineering than to presales, with Indeed data reported by Business Insider putting pay at about $170,000 to over $200,000 a year, and frontier AI labs advertising considerably more for the same title.
| Source | Location | Advertised pay |
|---|---|---|
| Indeed data, reported by Business Insider in May | Market range | About $170,000 to over $200,000 |
| OpenAI FDE posting | San Francisco | $185,000 to $300,000, plus equity |
| Anthropic FDE posting | New York, San Francisco, Seattle | $280,000 to $320,000 annual salary |
Both lab postings ask for serious experience, with Anthropic looking for four or more years in a technical, customer-facing role and OpenAI for five or more years of engineering or deployment work that included customers. Postings change often, so treat any single range as a snapshot of the market rather than a fixed benchmark.
For a company weighing whether to hire its own FDE, the honest comparison is not salary against a vendor's rate but the fully loaded cost of a senior engineer who can also run a customer relationship, plus the months it takes to find one and the risk of a whole capability living in one person, against borrowing that capability for the length of a deployment.
Which skills separate a strong FDE from a strong engineer?
A strong forward deployed engineer combines the technical range of a senior full-stack or data engineer with the judgment to run a difficult meeting with a customer's executives, because both halves get tested in the same week and often on the same day.
Technical forward-deployed engineer skills
- Strong programming, usually Python alongside TypeScript or Java, with a record of shipping production applications
- Data engineering that gets clean, governed data out of systems never designed to share it
- Integration across APIs, identity and access management, and network and security constraints
- Cloud deployment and observability in environments the engineer does not control
- For AI FDEs, context and prompt design, retrieval, agent development and evaluation frameworks
Customer-facing skills
- Discovery that uncovers how work really happens, not how the process document describes it
- Translating between business owners and engineers without losing either audience
- Delivering hard truths to senior stakeholders while keeping their trust
- Prioritizing under ambiguity when three departments want different things
- Writing decisions, runbooks and patterns down so someone else can reuse them
Salesforce, which fills much of its FDE team through internal moves, treats coding as the baseline and looks hardest at judgment, pattern recognition and the ability to deliver hard truths to C-suite stakeholders without alienating them. Around 40% to 50% of its FDE movement is internal, supported by a six-week onboarding program that pairs two weeks of technical training with four weeks on the job.
How do you interview a forward-deployed engineer?
Test the combination rather than each half separately, since plenty of strong engineers struggle in front of customers and plenty of strong consultants cannot debug production. Palantir's engineers name "technical decomp" as a core skill, taking a high-level business problem and breaking it down to the code that solves it, and four exercises cover most of what matters:
- An unfamiliar codebase with a real integration bug. Watch how the candidate orients before touching anything.
- A discovery role play with a wrong requirement. A strong candidate finds the real problem behind the stated one.
- One trade-off, two audiences. Ask for a two-minute explanation to a non-technical executive, then the same decision explained to an engineer.
- A deployment story with specifics. Ask what broke after launch, who owned it afterwards, and what changed in the product as a result.
When does a company need forward deployed engineers?
You need forward deployed capacity when the hard part of an AI rollout is fitting it into your own systems, data and workflows rather than choosing the tool, and nobody on your team has the time and range to own that fit from discovery to production.
Signs you need it
- A pilot works in a sandbox but stalls against real permissions, data residency rules or legacy systems
- The rollout crosses several departments and no single owner can make decisions across them
- Success depends on a workflow metric, such as handling time or error rate, rather than on installing software
- Your engineers can build, but not while also running discovery with operations teams
- Regulated data or audit requirements mean the system has to run inside your own environment
Signs you do not
- The product is mature software with standard connectors and a clear admin guide
- The scope is fixed and fully documented, which suits project delivery better
- Nobody owns the workflow on the business side, in which case an FDE will stall as well
Company size changes the math, since in the MIT NANDA research the top-performing mid-market companies moved from pilot to full implementation in about 90 days, while enterprises took nine months or longer. Embedded engineers tend to pay back fastest where decision paths are short enough for their work to reach production.
Should you use vendor FDEs, hire your own or embed a partner?
Use a vendor's FDEs when you have already committed to that vendor's platform and want speed on it, hire your own when AI deployment is a permanent capability you intend to own, and embed a vetted partner team when you need the capability now, across tools, without a search that can run for quarters.
| Route | Best for | Watch out for |
|---|---|---|
| Vendor FDEs | Speed on a platform you have already chosen | Usually reserved for the vendor's most strategic customers, and the system lands on that vendor's stack |
| Your own FDE hire | AI deployment as a permanent internal capability | Senior pay, long searches, and critical context held by one person |
| Embedded partner team, sometimes sold as FDE as a service | Vendor-neutral capacity sized to the deployment | Quality varies widely, so vetting and ownership terms decide the outcome |
The catch with vendor FDEs is structural rather than a question of talent, and Andrew Ng named it in May: vendor-neutral FDEs are hard to find, because they exist to integrate one product deeply, and while nobody can predict which AI service will fit best a year out, binding your processes to one reduces optionality.
Even vendor models built around self-sufficiency carry that shape, since AWS designs its engagements so customers can operate independently at the end, while the agentic systems it leaves behind run in the customer's own AWS environment. That is sensible engineering, and it is also a switching cost worth pricing in before the work starts.
Ng also expects far more AI engineer jobs than FDE jobs, reasoning that a company might accept a few embedded FDEs but will want many more of its own people on its projects, which is the strongest argument for treating any outside team as a bridge to internal capability rather than a permanent substitute.
The research leans toward outside help all the same, with learning-capable tools built through external partnerships reaching deployment about 67% of the time in MIT NANDA's sample, against about 33% for internal builds. The authors caution that these figures are self-reported and may reflect differences between organizations rather than the approach itself.
How do you keep ownership of what embedded engineers build?
Keep ownership by deciding, before the first commit, who owns the code, the environment, the evaluation set and the knowledge, and by structuring the engagement so your own people move from watching to building to running the system alone.
AWS describes that progression explicitly for its FDE teams, with customer engineers moving from observers to co-builders to autonomous operators, and customers leaving with runbooks, architectural documentation and trained internal champions. AWS told CIO Dive that it works in pods of five to six engineers on 45-day sprints, a useful benchmark for how tight a well-scoped engagement can be.
Deciding what must stay inside the company is the same exercise as any build-versus-outsource call, and our breakdown of what to keep in-house sets out control checkpoints, from architecture authority to sensitive IP, that apply just as much to embedded AI work. Whoever supplies the engineers, six terms belong in writing before kickoff:
- Code and infrastructure. Everything lives in your repositories and cloud accounts from the first day, with IP assignment written into the contract.
- Evaluation set and prompts. The test cases that define a correct answer belong to you and are versioned with the code, because they are the most reusable asset the engagement produces.
- A named internal counterpart. One person on your side pairs with the FDE from the first week and ships the final changes.
- Runbooks and decision logs. These are written while the work happens, not reconstructed in the last week.
- Exit criteria. A measurable workflow result plus a handover test, such as your team deploying and rolling back a change without help.
- Portability. Integrations go through open interfaces such as MCP where possible, so a change of model or vendor does not mean a rebuild.
How do you know an FDE engagement worked?
An FDE engagement worked if the target workflow changed measurably, the intended users rely on the new system, and your own team can operate and improve it after the engineers leave.
| Measure | What it tells you | When to set it |
|---|---|---|
| Time to first production workflow | Whether the work is getting past the pilot stage | Before kickoff |
| Active use by the intended team | Whether people actually adopted the system | Before kickoff |
| Change in the workflow metric | Whether the business result exists | Before kickoff, with a baseline |
| Evaluation pass rate over time | Whether quality holds through model and data changes | Before launch, with a threshold |
| Changes shipped by your own team | Whether the handover is real | As an exit criterion |
Khalid describes a customer whose service agent targeted a 70% deflection rate, a number that became the north star for every change, and once the team hit it the customer expanded to a second use case. That is the pattern worth copying: one number agreed up front, visible to both sides, with expansion earned rather than assumed.
OpenAI describes its Deployment Company engagements as opening with a focused diagnostic and a small number of priority workflows chosen with the customer's leadership and operating teams. That shape suits any FDE engagement, because starting narrow and measuring from the first day is what lets expansion follow evidence rather than enthusiasm.
What should you ask before bringing in outside AI engineers?
Ask for evidence of a deployment the team took from discovery to production inside a client's environment and then handed over, rather than a demo, and use questions that only a team with that experience can answer in detail:
- Which workflow did you take to production most recently, what broke once real users arrived, and who owns it now?
- Where did the code, prompts and evaluation sets live, and did the client's team ship changes without you afterwards?
- How do you handle identity, data residency and access to production data?
- Which models and platforms have you deployed on, and when did you last recommend that a client switch?
- Who on your side runs discovery with operations teams, and can we speak to one of those teams?
If you want forward-deployed capacity that answers to your roadmap rather than to one model vendor's, Vetted Outsource matches you with a single vetted development partner, evaluated on production ownership and delivery discipline, whose AI software engineers have already passed a first filter, so the questions above become a second one and the ownership terms can be agreed from day one.
