Finding the leverage
Pull twenty real cases, sort them by what went wrong, work out roughly what that costs, and sit beside the person doing the work for a full day. An hour in a meeting room surfaces the process people think they follow.
Forward deployed engineer
The companies building the AI models are spending billions to send people into their customers to make those models work. The role is called forward deployed engineer. This guide explains what it is, what OpenAI, Anthropic, Mistral and Palantir themselves publish about it, where it fits inside an ordinary business, and where it does not.
Origin: PalantirOpenAI: its own deployment company, May 2026Anthropic: €241,000–€276,000 in the postingMistral: the same role, hired across EMEAAbout an 18 minute read
Written from the labs' own published material and from trade press. Every source is linked at the bottom. There is no offer, no ask and no form on this page.
Read on if
- You pay for an AI seat for everyone and the work still runs the way it did a year ago.
- There is a workflow that runs several hundred times a month and loses days each time.
- You have heard the term and cannot tell whether it is a role, an agency or a passing fashion.
- Someone has proposed an AI project and you lack a basis for saying yes or no.
What is in this guide
Fifteen sections. Section 02 is what makes the rest checkable: it holds the labs' own words, with links. Section 12 is the decision the guide was written for.
01 · The definition
What a forward deployed engineer is
The term comes from Palantir, where engineers were sent to the customer, learned the workflows, and built on top of the customer's own data. Palantir's own distinction is the clearest one available: a traditional software engineer builds a single capability many customers can use. A deployed engineer builds many capabilities for a single customer.
A forward deployed engineer is the person who learns how the work actually runs inside your business, including everything nobody wrote down, and then builds and operates the software that removes the most expensive delay.
Building it
The simplest system that hits the point. Permissions and data boundaries set so the model only sees what it needs. And tests: a set of real cases with known answers that the build is measured against.
Owning the result
Put it into live work, watch what breaks, fix it, repeat. A build can score beautifully on the tests and still fail on contact with reality. This is the stage most projects are abandoned at.
Almost nobody starts equally strong in all three. The engineer can build but struggles to see why a missing field costs money. The consultant sees it but cannot build and verify it. The solutions architect does both up to a point, then hands off. That is why the title alone tells you nothing, and why screening matters more than the CV.
02 · The primary sources
What the labs themselves say
The strongest argument that the role is not a buzzword: the companies selling the models are building entire businesses around getting them installed inside customers. Below are their own words, with links.
“…work closely with business leaders, operators, and frontline teams to identify where AI can make the biggest impact, redesign organizational infrastructure and critical workflows around it, and turn those gains into durable systems.”
What they built
In May 2026 OpenAI launched a separate deployment company together with nineteen investment firms, consultancies and system integrators, led by TPG. The founding acquisition was Tomoro in Edinburgh, giving it roughly 150 experienced FDEs on day one. Trade press put the initial capital above four billion dollars, roughly €3.4bn.
What they measure
The postings say it plainly: success is measured on “production adoption, measurable workflow impact, and eval-driven feedback”. Adoption and measured impact, scored after go-live.
openai.com/index/openai-launches-the-deployment-company
“…a Forward Deployed Engineer (FDE) who embeds directly with our most strategic customers to drive transformational AI adoption.”
What the posting reveals
$280,000–$320,000 (about €241,000–€276,000), four years of experience, 25–50% travel to customers. The deliverables are named: MCP servers, sub-agents and agent skills: code inside the customer's systems, not a report.
And what matters most here
In May 2026 Anthropic co-founded a company aimed squarely at mid-sized businesses: its own examples are community banks, mid-sized manufacturers and regional health systems that “lack the in-house resources to build and run frontier deployments”.
anthropic.com/news/enterprise-ai-services-company
“…FDSEs focus on enabling many capabilities for a single customer.”
Why it matters
Palantir has run the model for over a decade, long before AI. The engineer sits at the customer, not at the vendor, and works one place at a time. That is why it works, and why it is expensive.
And a detail worth noticing
Palantir now sells “AI FDE” as a product: an agent that operates the platform on command. The mechanical half of the role is being automated by the people who invented it. The half that decides where to build is not.
“Applied AI, Forward Deployed Machine Learning Engineer, Critical and Sovereign Institutions, EMEA”
That is a real job title
That is the posting, verbatim. Mistral runs the same function under the Applied AI name, with open roles across EMEA, and describes the team as working with customers from pre-sales through implementation. Same shape as the other three, hired in Europe.
Why it reads differently
The analysis of their deals says Mistral's engineers go further than the American labs on one axis: the weights run in the customer's own data centre, and the work includes wiring the thing into European compliance. Named deployments include BNP Paribas, AXA, Orange, CMA CGM, Stellantis and the French Ministry of Armed Forces.
jobs.lever.co/mistral
And what they have set in motion around them
The labs cannot staff the demand themselves, so they are paying others to. Every programme below was announced publicly within the last nine months.
“DXC will train tens of thousands of Claude-certified forward-deployed engineers — engineers embedded directly inside customer organizations.” Into the systems DXC already runs for banks, airlines, insurers, manufacturers and government. The published use cases: agentic solutions and core system modernisation in insurance, analysis and refactoring of legacy code, an always-on security engineer subagent for security operations centres, and agents for application maintenance.
Roughly 30,000 Accenture staff trained on Claude, including deployed engineers. Accenture calls them “reinvention deployed engineers” internally. The stated purpose is moving companies “from AI pilots to full-scale deployment”. Named areas: compliance workflows in financial services, datasets and clinical trials in life sciences, and citizen-facing agents in the public sector.
$100 million in 2026 alone, about €86m, and a fivefold scaling of partner-facing teams, including dedicated Applied AI engineers assigned to partners working live customer deals. Named partners: Accenture, Deloitte, Cognizant and Infosys. UST is separately training 20,000 staff, deployed engineers included.
An entirely new company whose only purpose is getting Claude into operations at mid-sized businesses. Anthropic's own example of an engagement: a regional health system where clinicians and IT staff sit with the engineers and build documentation and medical coding tools into the workflows that already exist.
And the numbers that puncture the headlines
You run into “the million-dollar job” quickly. That figure is real, but it is a frontier-lab figure. A review of a thousand postings paints a very different and far more useful picture for an ordinary company. Source figures stay in the currency they were published in, with euro equivalents at roughly $1.16 to the euro, the rate in early September 2026.
$173,816, or roughly €150,000. That is the level of a good senior engineer. The million-dollar numbers are real, but they apply to the few hundred people working inside the labs themselves.
Bloomberry · 2025–26Most of the companies hiring are the size of a mid-sized European business, with no large IT department and complicated workflows.
Bloomberry · 2025–26Worth noting if somebody introduces themselves as a forward deployed engineer and starts talking about licences. The role is delivery, not sales. The most frequently named responsibility across the postings is “working directly with customers”, in 55% of them.
Bloomberry · 2025–26And what exists in Europe
OpenAI advertises the role in London, Munich and Stockholm. Tomoro, which OpenAI acquired, sits in Edinburgh and has worked for Tesco, Virgin Atlantic and Supercell among others. Mistral hires for it across EMEA, including a variant aimed at critical and sovereign institutions, which is the clearest sign that this is not only an American import. And it has already reached the Nordics: BCG X is currently recruiting a Forward Deployed AI Engineer and a Forward Deployed AI Scientist in Copenhagen, as permanent roles and as internships. What is almost entirely missing is writing about it in any language other than English. The vocabulary has not travelled yet. The work has.
03 · Why the role appeared
The AI model is no longer the advantage
A few years ago access to AI was scarce. Today your competitor buys the same AI model, at the same price, from the same supplier. The story about companies being priced out of intelligence did not hold. What is left is application, and that cannot be bought ready-made, because no two businesses work the same way.
LinkedIn's January 2026 labour-market report put growth in deployed engineering roles at 42-fold over two years, against 13-fold for AI engineers. In a labour market otherwise weaker than before the pandemic.
LinkedIn, Jan 2026The figure is MIT research, widely quoted. What matters is not the number but the explanation: pilots do not fail because the AI models are too weak. They fail because nobody made the decision about where the model belonged.
MIT figure, as cited in Isenberg/VasumanAnthropic itself writes “tens of thousands” about the DXC programme. In August 2026 Nate B Jones counted the number actually trained at 86. Whatever the figure is today, the gap between the promise and the delivery is the entire reason the role pays what it does.
Anthropic (June 2026); Nate B Jones (Aug 2026)Read the salary as a signal, not as a price. The figures are American, and nobody expects you to pay them. What matters is what the market says about scarcity: if the companies building the AI models both pay that and found companies to get people out to customers, then the model is not the hard part.
04 · What goes wrong
Why AI projects stall
The patterns below recur across the sources. If two or more look familiar from your own house, they are evidence that nobody did the work before the build.
The most common strategy and the most expensive. One source describes an executive team burning a ten-million-dollar budget, roughly €8.6m, in three months (it was meant to last a year) without moving the business. Everyone used it for a bit of everything. Nobody used it for anything measurable.
“An email arrives” sounds like a clean trigger. In reality it arrives from forty different senders, no two formatted alike, half of them are exceptions, and the rule for handling them lives in one person's head, and they will not think to tell you.
One case that runs cleanly is free to demo. The value sits in everything else: schemas that do not match, missing fields, two systems that disagree. The exceptions are the product.
One source describes a client who spent a couple of years and a couple of million dollars moving onto their ERP. A proposal that starts by leaving it gets rejected in the meeting. What works sits on top of what you already run and connects it.
Without a set of known cases with known answers there is no yardstick. The discussion becomes taste: some people think the answers look fine, others do not. Status quo wins that discussion every time.
The supplier handed over and moved on. But the real failures only appear in live use, and a system nobody corrects in the first months is quietly abandoned by the people it was meant to help.
05 · The core of it
Where the intelligence belongs
This is where the role differs from anything else you can buy. The decision is not which model. It is which steps in the workflow need an AI model at all, and which are better served by ordinary software, a lookup, a rule, and a person who says yes.
- 01The case arrives
- 02Attachments extracted
- 03Is anything missing?
- 04Fields validated
- 05What is it about?
- 06Lookup in the system
- 07Reply drafted
- 08A human approves
- 09The message goes out
- 10The case is recorded
Six steps: ordinary softwareThree steps: the model judgesOne step: a human approves
06 · The method
How the starting point is found
A company has twenty, thirty, sometimes hundreds of plausible places to apply AI. The same month of engineering can remove two thousand days of waiting, or make a rare edge case slightly better. The difference is the choice, and the choice is a business question.
How often it happens →
Rarely
Every day
Costlyto get wrong
Large payouts, suspected fraud, personal cases. Experience is the whole value, and one error costs more than the entire saving.
Worth taking later. Not first: the tests, the audit trail and the approvals have to exist before anyone dares let go.
Cheapto get wrong
Perfectly automatable. It just moves nothing, and a month of work is gone.
The answer already sits in the material, it happens hundreds of times a month, and nothing is given authority that can do harm.
The rule of thumb the sources use
Find the point where a relatively small build moves the largest amount of work, without giving the model a dangerous amount of authority. It is rarely the place that sounds most impressive on a slide. It is usually something that is waiting.
Pull twenty real cases
The actual completed cases from recent months, with what happened along the way, rather than a description of the process. Classify them by what went wrong and count how many hit the same thing.
Week 1Sit beside the work
A full working day beside the person doing the work. A one-hour interview gives you the process people think they follow. A day gives you the one they actually follow, and half of your first list turns out to be wrong.
Week 2Do the sums
How many cases a month, how long each one loses, what an hour costs. No financial model is needed. What is needed is a number that can be compared with the next candidate on the list, and checked afterwards.
Before anything is built07 · A worked example
From the CEO's wish to a number you can check
The example comes from Nate B Jones and concerns claims handling at an insurer. It is not a client case of mine, and the numbers are his. It is here because it shows the translation: the same sentence from the CEO can become a project that never lands, or something you can measure in four weeks.
“I have seen enough AI presentations to know the technology can read documents. I want claims processed twice as fast.”
- Two files were read side by side. One moved through intake in a day. One sat for almost a week: the repair estimate arrived Tuesday, the signature page was missing, and nobody noticed until Friday.
- Three days disappeared before anyone made an insurance decision at all, because a document was missing and nobody looked for it.
- The arithmetic: a few thousand claims a month, 600–700 of them incomplete, several days lost on each. Roughly 2,000 claim-days sitting still every month.
- The answer already sat in the packet. Any adjuster can see in a couple of minutes that something is missing. It did not need judgement. It needed somebody to look immediately.
- What got built: a service that notices on arrival that a file is incomplete, points at the missing item, and prepares the message to the customer. Nothing else. Injury, fraud review and payment stayed with people.
Note what can be measured afterwards: how quickly a gap is spotted, how often the system raises a false alarm, how often it misses one, and how long the adjuster spends checking it. Four numbers. None of them require a debate about whether the answers look good.
08 · Use cases
Where it typically fits
The patterns below resemble each other more than the industries do. All eight have the same shape: it happens often, the answer already sits in the material, and the delay sits in front of everything else.
Applications, claims, orders, vendor onboarding. A document or a field is missing and nobody notices for days. Everything behind it waits.
Invoice, delivery note, contract, certificate. Somebody rekeys from a PDF into the ERP, and gets it wrong occasionally.
The CRM says one thing, the ERP another, and a spreadsheet settles it. Somebody reconciles by hand every month, and the errors surface later.
Support, procurement, HR, service desk. One experienced person routes everything because only they know the rules. They take holiday in week 29.
Eighty per cent of the content is the same every time, but it is assembled by hand from old files. The deadline decides the quality more than the customer does.
You sample, because there are not enough hours to check everything. A subset stands in for the whole, and everyone agrees to call that coverage.
Same extract, same layout, same commentary every month. Somebody spends two days on it and nobody reads the footnotes.
The answer is known and sits in the system. It is just waiting on a person who is busy with something else.
The common thread is the shape: high frequency, low cost per individual error, and an answer that already sits in the material. If you can fit three of your own workflows into that shape, you have a shortlist, whether or not you bring anyone in.
The use cases the labs themselves highlight
Worth holding against the list above, because this is what they chose to publish. Anthropic and DXC name agentic solutions and core system modernisation in insurance, analysis and refactoring of legacy code, an always-on security engineer subagent in the operations centre, and agents for application maintenance. The Accenture partnership names compliance workflows in financial services, datasets and clinical trials in life sciences, and citizen-facing agents in the public sector. Anthropic's own example of a mid-sized customer is a regional health system building documentation and medical coding tools into workflows the clinicians already have. Note the shape: all back office, high frequency, close to systems that already exist. None are customer-facing and none make the final decision.
And where it does not fit
The honest half, which the material rarely covers
Decisions with legal or financial exposure
Large payouts, credit decisions, hiring and firing, regulatory matters. A wrong answer can cost more than the entire saving, and accountability cannot sit somewhere without a name.
Work that happens rarely
Year-end, a single large contract, the complicated case that shows up twice a year. It can absolutely be built. It just does not pay for itself, and a month of work is gone.
Processes that are already automated
If a working integration already runs, there is no gain in putting a model inside it. There is only a new thing that can break.
Areas with no history
If you cannot find thirty completed cases with known answers, no test set can be built. Without tests, nobody can say whether the system got better or worse. The first step is collecting the cases, before anyone is hired.
09 · The engagement
How the work actually runs
The sources agree on the order, and that no step can be skipped. Each stage is the precondition for the next, and the loop restarts, because the first bottleneck you remove makes the next one visible.
- 1 · AuditHow the work really runs, exceptions included. A map and a ranked list.
- 2 · EvalsKnown cases with known answers. What “good enough” means, agreed before building.
- 3 · Shadow modeThe system runs alongside real work without touching anything. You compare.
- 4 · ProductionOn top of your own systems. Human approval. An audit trail on everything.
- 5 · The next bottleneckThe first fix releases work downstream and reveals where it pinches now.
It is the value, not the delay
The sources describe clients valuing the audit at ten times what it cost, independently of what got built afterwards. A process map your own people recognise, with the exceptions written down, exists almost nowhere.
They turn opinion into evidence
An eval report reads like this: 50 runs, 41 passed, and of the nine: five had missing data, four pulled the wrong record. That is a conversation that can be closed. “Do the answers look sensible?” is not.
On top of, never instead of
The build sits on the ERP, the CRM and the systems you have already paid for, and joins them up. Any proposal that starts with a migration is spending its credibility on the wrong thing.
The yardstick is the size of the win
If the win is twenty hours a month rather than two thousand, the wrong point was chosen. Look for the cause before concluding that the technology does not work.
10 · Trust
The system earns each stage before it gets the next
No stage is skipped. This is how the exceptions get found, and how the person who has to use the thing gets to watch it be wrong on a day when that costs nothing.
The system runs alongside real cases but touches nothing. You compare its answers with your own.
It proposes, a person decides. Every case. This is where you find the exceptions nobody wrote down.
Clean cases run through. Only the doubtful ones reach a person, and the system flags them itself.
It runs. Metrics and alerts say when it stops running well. Someone still has their name on it.
What to insist on seeing
This list works regardless of who does the work: an employee, an agency, or your own people. It is also the easiest way to separate real work from a demo.
- A map of the process your own staff recognise, exceptions included.
- A ranked list with a number behind each entry, so two candidates can be compared.
- A test set: thirty to fifty known cases with known answers, and a written agreement on what “good enough” means.
- An eval report with failures grouped by cause, rather than a single headline percentage.
- An audit trail: what the system did, when, on what basis, and who approved it.
- Data boundaries: what the model may see and what it never gets access to. Written down before building.
- A name: the person who approves, until the numbers say it is no longer necessary.
11 · Timing
Why this is now rather than in two years
Four arguments, and one against. The last one is here because a guide that only points one way is a pitch in disguise.
Two years ago you could reasonably wait for the technology to become good enough. That wait is over. What is missing now is the decision about where to apply it, and waiting does not make that decision easier.
You can watch it happening. DXC, Accenture, Cognizant, Infosys and UST are already training people to be deployed, and OpenAI bought an entire firm to get a hundred and fifty of them at once. Those people get committed to customers as they qualify.
Each bottleneck you remove makes the next one visible and cheaper to remove, because the map, the test method and the data boundaries already exist. A year without the first engagement is therefore not a year of status quo. It is a year in which whoever started is a lap ahead.
Even if you never build anything, a map of how the work actually runs, with the exceptions written down, is something few companies have. It is also exactly the knowledge that walks out when the right employee resigns.
The argument against: when to wait
If you cannot pull thirty completed cases from the workflow you have in mind, you are not ready, and that is not an argument for hiring someone to find out. The cheapest first step is collecting the cases yourself. It costs an afternoon, it can be done by the person already doing the work, and it is the first thing any competent person will ask for anyway.
12 · The decision
The three routes, and which is yours
This is what the guide was written for. The role can be hired, bought, or grown from inside. For almost everyone the first move is the same one: buy a single engagement. It answers the question the other two routes quietly assume you have already answered, and it does something neither of them can. While it runs, you find out which of your own people gravitate to the work. That is your answer on whether to hire or to promote, and it costs one project to learn rather than one bad year. The three routes are below, and under them a table for checking which one you are actually in.
Buy an engagement
Fits if
You are at the start. This is nearly always the right first move, whatever you intend to do afterwards.
The cost
Faster to start, but the audit must be your property, the code must run on your systems, and the contract must say who owns the test set. Put one of your own people alongside it from day one; half the value is what they learn.
The trap
The engagement ending at handover. It is after launch that the work is worth paying for.
Grow one inside
Fits if
You have someone who knows your systems and exceptions better than any outsider could reach.
The cost
Time and training. But it is exactly the route the market itself is taking: DXC, Accenture and UST take people already working inside complicated systems and add the technical layer. Domain knowledge is the part that cannot be bought quickly.
The trap
Handing the person the job on top of everything else. Without protected time and a named workflow it becomes a side project that dies quietly.
Hire
Fits if
You have run one engagement, you know the work pays, and you now know what good looks like.
The cost
You are competing for a profile the labs, the consultancies and the American companies also want. Recruiting takes months, and a bad hire costs a year. The market median sits well below the headline numbers, so the real risk is time and judgement rather than salary.
The trap
Hiring on the title. The role attracts people who can do both halves and people who can do neither.
On growing one inside, one figure is worth knowing. In a study of roughly 400,000 sessions with an AI coding tool, people rated as experts in the task reached a verified result more than twice as often as novices, and non-technical users came within a few points of the engineers on the code they produced. The domain expertise is the scarce half. The technical half has become easier to acquire than domain knowledge ever will be.
So which one is yours
Each row is a situation you can check against yourself in a minute. The verdicts use the three names above.
- You cannot find thirty completed cases from the workflow you have in mind.
None of them yetCollect the cases first. An afternoon, done by the person doing the work. It is the first thing any competent person will ask for anyway.
- The pressure is coming from the board, not from a specific workflow.
WaitA project that starts from wanting to have AI ends as a demo. Find the delay that costs most first, and go back to the board with that.
- You have one clear bottleneck and want to see whether this works for you at all.
Buy an engagementAnd tie the map, the test set and the code to yourselves in the contract. Otherwise you have rented an insight you cannot reuse.
- You have five or more bottlenecks, and they are connected.
Still one engagement first, scoped as the first of severalThe value compounds, so the knowledge does need to end up in-house. That is an argument for hiring second rather than first: run one, watch who inside leans into it, and let that decide whether you are recruiting or promoting.
- You have an employee who knows the systems and the exceptions better than any outsider could reach.
Grow one inside, alongside an engagementThe cheapest and most overlooked route. Put that person next to whoever runs the first engagement and they learn the method on your own workflow. Protect the time and give the job a name, or it becomes a side project that dies quietly.
13 · Screening
How to tell a good one
This part is for later, once you have chosen a route and someone is sitting in front of you. The sources themselves warn that the role is filling up with people who are neither the best communicators nor the best engineers, and the title on a CV will not separate them. These five questions will.
“Tell me about an exception you found that nobody had written down.”
Someone who has only read process documents has no story. Someone who has sat beside the work has five.
“Show me an eval report from something you built.”
A list of what failed and why. If it does not exist, the system was never measured.
“What did you decide not to use a model for?”
This is the whole judgement in one question. If they cannot answer, they did not make the choice; they just built.
“What happened after launch?”
This is where solutions architects and agencies typically stop. The answer should contain failures, fixes and numbers, rather than a handover.
“What would you put on our systems, and what would you leave alone?”
Anyone proposing a migration in the first conversation has not understood what makes the work hard.
And a note on titles
The same work appears as applied AI engineer, solutions engineer, implementation engineer, technical deployment lead and AI operations. Accenture calls it reinvention deployed engineer internally. Mistral calls it forward deployed machine learning engineer. So the title on a CV, or on an agency's staffing plan, tells you almost nothing. Judge the scope: how much of it is building, and who owns the result after go-live.
14 · Glossary
The words that get used without explanation
Eight terms that recur in every presentation on the subject. Worth knowing, because they are where a conversation typically goes wrong without anyone saying so.
- Eval
- A set of known cases with known answers that the build is measured against. Without it, “does it work?” is a matter of taste. It is technical work, but it needs no code. It needs somebody who can decide what a correct answer is.
- Golden set
- The collection of correct examples itself. The more history you have, the easier it is to assemble, and the harder it is to build if you kept nothing.
- Agent
- Software that can carry out several steps in sequence and reach into other systems along the way, rather than only answering a question. That is what makes small misunderstandings more expensive than they used to be.
- Harness
- Everything around the model that makes it behave: instructions, tool access, boundaries, memory and checks. This is where the work sits. The choice of model matters far less.
- MCP server
- The standard way of giving a model access to one of your systems: a socket between the model and the ERP, the archive or the case system. Anthropic names it directly as something its own deployed engineers deliver at the customer.
- Human in the loop
- A fixed point where a person approves before anything leaves the building or is written into a system. On most workflows it is permanent, not a stage you pass through.
- Shadow mode
- The system runs on real cases without permission to act. You compare its answers with your own and find where it is wrong while that is free.
- Audit trail
- A readable record of what the system did, when, on what basis and who approved it. Usually the difference between a system your auditors accept and one they do not.
Questions
What usually gets asked
Is this not just consulting with a new name?
Half. The mapping and the communication are consulting, and that is how the role began at Palantir. The difference is that the same person builds it afterwards and stays with it in production. Anthropic's own posting makes the difference concrete: the deliverables are MCP servers, sub-agents and agent skills: code inside the customer's systems, not a report. And none of the thousand postings reviewed carried a sales quota.
How large does the company need to be?
Smaller than you would think. In the review of a thousand postings, 58% of hiring companies had between 11 and 200 employees. And in May 2026 Anthropic co-founded a company whose stated purpose is mid-sized businesses: its own examples are community banks, mid-sized manufacturers and regional health systems. Volume decides it: if the workflow runs several hundred times a month and loses time each time, there is something to get.
Which model should we choose?
Which AI model, that is. It is the least important choice on the list, which makes it remarkable how much air it gets. The sources recommend getting genuinely good at one ecosystem first while preserving the ability to switch. The value is in knowing where to put it.
Does the person have to sit with us physically?
Partly, and the labs have put numbers on it. Anthropic's posting states 25–50% travel to customers; OpenAI writes up to 50%. The argument is not that the information cannot be gathered over video. It is that being present for a full day shows you what nobody remembers to mention: what breaks, the unwritten rule, the colleague who gets asked every time.
What does it cost?
This guide cannot answer that for a specific market, and any figure would be invented. Two things can be said. The median across a thousand international postings was $173,816, roughly €150,000, which is the level of a good senior engineer. And the price should attach to the audit as a standalone piece of work with an output you keep, whatever you decide afterwards.
Is this a fashion that will be gone in a year?
The title may well disappear or turn into something else, and it already appears under five or six names, and Palantir now even sells “AI FDE” as a product that automates the mechanical half of the role. The work does not disappear. As long as intelligence is general and companies are specific, somebody has to choose where to apply it. That choice is the half nobody has automated.
In closing
What is worth taking away
Everyone can buy the same AI models. Nobody can buy the knowledge of where it belongs inside your particular business. That knowledge already exists: it sits distributed across the heads of the people doing the work, and it has never been written down. That is the whole reason OpenAI founded a company and Anthropic is paying five consultancies to train people: they can sell the model, but they cannot sell that knowledge. It has to be extracted, one business at a time.
The decision is in section 12, and it is less dramatic than the subject sounds. The first step is the same whichever route you take: find thirty real cases from one workflow and look at what actually happened to them. It can be done in an afternoon, by the person already doing the work, without talking to anyone outside.
15 · Sources
Where this comes from
Everything is linked so you can check it yourself. Most of it is the labs' own published material, announcements and job postings, which is the best available source on how they actually think about the role. The figures are international, mostly American, and none has been independently verified here.
- 01OpenAI · “OpenAI launches the OpenAI Deployment Company”
May 2026. OpenAI's own announcement of a separate company that places deployed engineers inside customers. Source for the description of what FDEs do, the nineteen co-investors led by TPG, and the Tomoro acquisition with roughly 150 engineers.
- 02OpenAI · Forward Deployed Engineer job postings
Postings in San Francisco, New York, London, Munich, Stockholm, Tokyo, Singapore and Seoul among others. Source for how OpenAI defines the role, and for success being measured on “production adoption, measurable workflow impact, and eval-driven feedback”.
- 03Anthropic · Forward Deployed Engineer, Applied AI job posting
Source for the $280,000–$320,000 band, the four-year experience requirement, the 25–50% travel, and the deliverables described as MCP servers, sub-agents and agent skills.
- 04Anthropic · “DXC integrates Claude into systems regulated industries rely on”
11 June 2026. Source for the wording about training tens of thousands of Claude-certified deployed engineers, the named industries, and the four published use cases.
- 05Anthropic · a new enterprise AI services company with Blackstone, Hellman & Friedman and Goldman Sachs
4 May 2026. The most important source here for a mid-sized business: Anthropic states the company is for mid-sized firms (community banks, mid-sized manufacturers, regional health systems) that “lack the in-house resources to build and run frontier deployments”.
- 06Anthropic · the Accenture partnership and the Claude Partner Network
December 2025 and March 2026. Source for the roughly 30,000 trained Accenture staff including deployed engineers, the $100 million partner network, and the named partners Accenture, Deloitte, Cognizant and Infosys.
- 07Palantir · Forward Deployed Software Engineer and “AI FDE”
The origin of the role, and the framing that a deployed engineer delivers many capabilities for a single customer where a traditional software engineer delivers a single capability for many. Plus Palantir's own documentation of “AI FDE” as a product.
- 08Mistral AI · Applied AI, Forward Deployed Machine Learning Engineer
Open roles across EMEA, Montreal and Palo Alto, including one for critical and sovereign institutions. Source for the job titles and for Mistral describing its Applied AI team as working with customers from pre-sales through implementation. The on-premise and customer detail in the card comes from a May 2026 third-party analysis, not from Mistral.
- 09Bloomberry · an analysis of 1,000 job postings
November 2025, updated January 2026. Source for the $173,816 median, for 58% of hiring companies having 11–200 employees, for the industry split, and for none of the postings carrying a sales quota.
bloomberry.com/blog/i-analyzed-1000-forward-deployed-engineer-jobs-what-i-learned
- 10BCG X · Forward Deployed AI Engineer, Copenhagen
The Nordic signal: the title is already advertised in Copenhagen, as a permanent role and as an internship, alongside a matching Forward Deployed AI Scientist.
careers.bcg.com/global/en/job/56036/Forward-Deployed-AI-Engineer-Denmark-BCG-X
- 11Nate B Jones · “OpenAI Pays $280,000 For This Job”
23 August 2026. Source for the claims example in section 07, the three parts of the role, the study of roughly 400,000 coding sessions, and the count of how many DXC engineers had actually been trained at that point.
- 12Greg Isenberg & Vasuman (Varick Agents) · “FDE: The $1M/Year AI Job Explained”
20 July 2026. Source for the argument that intelligence has become a commodity, the MIT 95% figure, the three-of-ten-steps rule, the audit → evals → deployment loop, and the requirement to build on existing systems.