A Forward Deployed Engineer is not a person who writes a strategy deck about AI. An FDE's job is to get a business actually using AI: inside the systems people already work in, on work that was being done by hand, with a number attached to what changed. Deployment, measurement, and trust, not a convincing demo.
Over the past year, people running these teams at OpenAI, Anthropic, and Cursor have walked through real projects inside real businesses. The same patterns keep showing up. This issue pulls those patterns into four deployment moves and a five-step audit you can run without waiting for a job title to appear on a posting.
Honest constraint: AI Minority Lab's Safe Refund Agent teaches operational judgment under policy in a simulated company. It is not a Forward Deployed Engineer credential, and it is not a client-engagement playbook. The Lab is in private preview while the full free exercise is still being built.
The role nobody knows exists
Companies can barely fill this role, and it is not because the work is impossible to learn. Most engineers have never heard the title. Demand arrived before the people did.
In talks this year, FDE leaders have cited job postings for the role up 729% in a year, AWS putting a billion dollars into a forward-deployed department, and OpenAI's own team growing from two people in January to 39. Colin Jarvis, who runs that team at OpenAI, has said there simply are not many FDEs out there. Y Combinator batches now include more than a hundred startups hiring for the same job.
Three years ago almost nobody needed an FDE. The tools were not the bottleneck then either. Anyone can sign up for them, and most businesses already have. The shortage is people who can sit inside a real process, decide what should stay human, what should stay ordinary software, and what a model should be allowed to touch, then stay long enough for the people who do the work to trust the result.
What an FDE actually does
Advising is not the job. Handing over a strategy document is not the job. The job is getting AI running inside the systems a business already uses so that work people were doing by hand gets done by a mix of software, models, and people, on purpose.
Every process you will sit next to is some combination of three things: a human doing the task, software following hard-set rules, or a model making a judgment call on messy input. An FDE is someone who can say which of those three should own which step, and who can tell when the current assignment is wrong.
The undocumented workaround
A company put an agent on refund requests. On paper it worked. It read each request, checked it against the refund policy, and turned down the ones that did not qualify. A few weeks in, the company started losing customers it had had for years. Nobody could work out why. Every refund the agent refused was one the policy said to refuse.
The FDE sat with the person who used to do that job. That person had a step of their own which was not documented. They checked how the order had been paid for. If the purchase was on a company card, they approved it without reading further. Those orders came from businesses that bought every month. Arguing over one refund cost the account. The policy said nothing about that. They had worked it out themselves years ago.
That check went into the workflow as a fixed rule ahead of anything the model decided. The agent had been policy-correct and still wrong, because the real operating rule lived in one person's head.
Why adoption fails
Most people cannot tell you what they need. They describe something they have already imagined instead of the problem they are actually having. The people who do the work need the output to come out. They do not look at the process itself. That is why it is hard to build something they will adopt, and it is the largest issue in getting a business to use AI at all.
Ever since the tools became popular, companies have been adding them into everything they do without knowing whether they needed them. That is why they are suddenly hiring someone whose whole job is to sort it out.
Why this must be someone's whole job
The tools are not the hard part. Last year, MIT-associated research published as the NANDA GenAI Divide report looked across hundreds of enterprise initiatives and reported that about 95% produced no measurable return. The authors located the failure in how companies adopted the tools. Generic products looked good in a demo and fell apart on real work. The models were not the failure.
Vasuman Mosa does this work for a living. He has said AI is getting slapped on top of broken processes because nobody looks at the process first. One executive he spoke to burned through a $10 million budget in three months that was meant to last a year. The company had handed the tools to everybody and left them to it. Everyone spun up whatever they felt like. The money went. None of it made the business better at anything it was already doing.
Nobody already inside the business is going to do this work. Engineers have their own queue. The people running the process have been doing it so long that the workarounds look normal.
Palantir lost a year to one of those workarounds. A move onto a new file format stalled because one engineer kept saying the new format was worse. Nobody could work out why until someone watched her work. She had been checking the data by double-clicking the files open. The new format had nothing you could double-click. The team built her something that night that let her open the new files the same way. She approved the move two days later.
That is why it is worth having somebody whose whole job is to work this out before anything gets built. The alternative is a year of cost and no change in the work.
How the teams that do this actually deploy
When you line up the talks from OpenAI, Anthropic, and Cursor, four moves keep repeating. They are not a vendor playbook. They are constraints of getting delegated work into a business that already runs.
Pick the process that already costs
With AI that usually means volume. Look for the person who handles the same kind of message fifty times a day, then ask whether that volume is actually a thousand times a week. Automating one message saves nobody anything. OpenAI's team did this at a large bank: they went after the one job thousands of advisers did every day, and around 98% of them ended up using what was built.
That job is easier to find than it used to be. A business already has its past in support history. You can hand that corpus to a model and ask where the volume is, as a map, not as the deployment.
Build on whatever the business already runs
An agent is only worth what it can reach. If a team already keeps its work in Notion, you do not build them a separate system and migrate everything so an agent can read it more easily. You connect the agent to the tool they already paid for. Most teams will not give up a system they have spent years on.
One of Mosa's clients had spent $5 million and five years getting onto their finance system. Moving them off it was never going to happen. The whole job was getting everything else in that business talking to it.
Do not change the way people work more than you have to
If somebody has been running an eleven-step process for years and you hand them a one-step version, they stop using it. They used to check the work as they went. Now the middle is gone, and they are being asked to trust an answer that just appeared. Leave the process looking like the one people already know. Let the agent do the work inside each step. Keep the steps visible so someone can still see why the answer is right.
Budget far more time for trust than for building
At that same bank, the technical side was finished in six to eight weeks. It then took another four months of pilots before the advisers would actually rely on it. If you have done a job the same way for a year, any change has to earn its way in, whether you are handing it to five thousand people or to five.
Five steps you can run yourself
The road map is five steps, and the first one happens before you build anything. Print theprocess audit worksheet and fill it in while you watch.
1. Watch how the job is really done
Write down every step in the order it actually happens. Then ask why each step is done that way. If nobody can give you a concrete reason, you are usually looking at a workaround somebody put in years ago that nobody has questioned since.
2. Decide which parts should become AI
If you hand the whole process to a model, you recreate the 95% that never produce anything. Run every step through three filters.
You will almost never find that the whole process should be run by AI. In Mosa's example of an eight-step process, four steps ended up running on their own, three ran with a person checking the output, and one stayed fully human because it was a business call. Either the cost of getting it wrong was too high, or the step did not come up often enough for a model to be worth the trouble.
3. Build for the ways the system can fail
When there is only one way something can go right, there are a thousand ways it can go wrong. If you only build for the way it goes right, what you built is worth nothing. With models that mostly means handling the places where the system is not sure, because it will hand you an answer either way.
4. Make sure it works before it touches anything real
A model gives a slightly different answer every time, even if you ask the same question. If you only test a few times, you will miss the rare cases where it falls over. Take real examples out of the process you wrote down, where you already know the right answer. Run the system across all of them. Count how many it got right. Read the ones it missed and fix those.
5. Put a number on what it was worth
You should be able to say whether it brought money in, took a cost out, or made a risk smaller. Nothing else counts.
Cursor had somebody complain that an agent was costing him $2,000 a day. When they asked what that agent was actually doing, it was picking which engineer to send out to fix broken equipment. They asked what it was costing him to send the wrong person. More than $2,000 a day. He agreed immediately. He had been looking at what the agent cost and never at what it saved.
The written process is the product spec
Teams that get this right do not start in the model playground. They sit with the people who do the work, write down every repetitive step, and only then decide what a model can reasonably take. That document becomes the instructions the agents follow and the knowledge they answer from. The first version goes back to those same people, on their own real work, until they can say it is saving time.
That is also why a simulated enterprise is a useful practice surface. You cannot always sit next to a refund desk this week. You can still practice writing the steps, triaging human / software / AI, and checking whether a workflow holds when the process is messy, against stateful APIs rather than a chat window.
What to get good at
Companies that hire for this job want people who are wide across business process and technology, with one area they are genuinely deep in. They often say the business half gets taught on the job and the technical half does not. For most readers of this issue that is backwards. The building is increasingly handled by agents. The scarce half is seeing the process.
A Palantir exec has said the person who fails at this job is the careful engineer who wants code that still holds up in ten years. The job is getting something rough in front of a real user quickly. That is a different virtue than long-horizon software design, and it is a mistake to treat one as a substitute for the other.
Start here: the audit
The place to start is the smallest business you can physically walk into wherever you work, or somewhere a friend runs. Ask whoever runs it if you can spend an hour sitting next to whoever does the most repetitive job in the place while they are actually doing it. Then run the five steps on what you saw.
What comes out the other end is called an audit, and it is a real thing businesses pay for. Mosa starts every engagement with one before anything gets built, and he has said the first phase is the biggest bottleneck in the whole job. That is what you put in front of people whether you are applying for an FDE role or pitching a business directly: one real company's process, the steps you would hand to AI, and what each of those is worth in money.
If you cannot sit next to someone this week, use the simulated refund desk instead. Same audit: write the steps, triage human / software / AI, then see whether the workflow holds when the process is messy.
Private preview. Do not treat the Lab as a live assessment or a Certificate of Completion until those parts actually launch. The exercise teaches operational judgment under policy. It is not a Forward Deployed Engineer credential.
Sources and limits
This issue is a synthesis, not original fieldwork inside OpenAI, Anthropic, Cursor, Palantir, or the bank described in those talks. Figures such as the 729% posting increase, the OpenAI headcount change, the bank's 98% adviser usage, and the six-to-eight-week then four-month rollout are reported as those teams presented them. The 95% figure refers to the 2025 MIT NANDA GenAI Divide findings as they have been publicly discussed. We have not independently audited those organizations.
Names and stories attributed to Colin Jarvis and Vasuman Mosa come from those public talks as compiled in the source material for this issue. Where a number would change the argument if it were wrong, treat it as a claim to verify against the primary talk or paper before you reuse it in a client setting.