The FDE Role: How Big Companies Turn AI Skills Into a Job Nobody's Filling

A forward deployed engineer is someone whose whole job is getting a business to actually use AI.

The FDE Role: How Big Companies Turn AI Skills Into a Job Nobody's Filling

Job postings for it are up 729% in a year. AWS put a billion dollars into a whole department for it. OpenAI's team for it went from 2 people to 39 in months. It's called the forward deployed engineer, and companies can barely find anyone to do it, mostly because people don't know the role exists. Here's what it is and how to start doing it yourself.

We build software, and we watch where AI is actually creating work rather than just noise. Right now the clearest opportunity is a role called the forward deployed engineer, or FDE. Over the past month the people running these teams at OpenAI, Anthropic, and Cursor have all given talks walking through real projects inside real businesses. We went through them and pulled out the parts you can actually use.

What an FDE actually is

A forward deployed engineer is someone whose whole job is getting a business to actually use AI. Not advising them. Not handing over a strategy document. It means getting AI running inside the systems they already use, so work their people were doing by hand gets done by AI instead.

Here's the core skill. In any process, a task is handled by one of three things: a human, software following fixed rules, or an AI. An FDE is the person who knows which of the three should handle which task.

A story shows why that judgment matters. A company put an agent on its refund requests. On paper it worked: it read each request, checked it against the policy, and turned down the ones that didn't qualify. A few weeks in, they started losing customers they'd had for years, and nobody could work out why, because every refund the agent denied was one the policy said to deny.

So the FDE sat with the person who used to do that job. It turned out they had an undocumented step. They checked how the order was paid for, and if it was on a company card, they approved it without reading further, because those come from businesses that buy every month and arguing over one refund costs you the account. The policy said nothing about it. They'd worked it out themselves years ago. That check went into the workflow as a fixed rule ahead of anything the model decided.

Takeaway: The value isn't handing everything to AI. It's knowing which steps stay human, which stay plain software, and which the model should own.

Why it's suddenly a whole job

The demand showed up before the people did. Job postings are up 729% in a year. AWS put a billion dollars into building a department of forward deployed engineers. OpenAI's own team went from 2 people in January to 39. Y Combinator alone has over a hundred startups hiring for the role. Three years ago basically nobody needed one.

The reason isn't the tools. Anyone can sign up for those, and most businesses already have. Last year MIT studied 300 AI projects and found that 95% produced no measurable return at all, and concluded the companies caused the failures, not the models. The ones that got nothing used generic tools that demoed well and fell apart on real work, and nothing they built ever learned how their business actually ran.

One executive burned a $10 million budget in 3 months that was meant to last a year. He handed the tools to everybody and left them to it, so everyone spun up whatever they felt like. The money went and the business got no better at anything.

And nobody already inside the company is going to fix that. The engineers have their own work, and the people running a process have done it so long that the workarounds look completely normal to them. Palantir lost a whole year to one of those: a move to a new file format was stuck because one engineer kept insisting the new format was worse, and nobody knew why. Someone finally watched her work. She'd been checking data by double-clicking files open, and the new format had nothing to double-click. They built her a way to open the new files the same way that night, and she approved the move two days later.

How the big companies actually do it

The same patterns showed up in every talk we analyzed. Four of them.

Pick the process that's actually costing something. With AI, that means volume. Find the person handling the same kind of message 50 times a day. Automating one message saves nobody anything. Automating a message sent a thousand times a week is where the business gets more productive. And it's easy to find now, because a business already has its whole past in its support history. Hand that to a model and it tells you where the volume is. OpenAI's team did exactly that at one of the biggest banks in the world, went after the one job thousands of advisers did daily, and around 98% of them ended up using what they built.

Build on top of whatever they already run. An agent is only worth what it can reach. If a team keeps everything in Notion, you don't build a separate system and move it all across. You connect the agent to their Notion with an MCP and everyone works the way they always did. One client had spent $5 million and 5 years getting onto their finance system, so moving them off was never happening. The whole job was getting everything else in the business talking to it.

Don't change how people work more than you have to. Hand someone who's run an 11-step process for years a one-step version, and they stop using it. They used to check the work as they went, and now the middle is gone and they're asked to trust an answer that just appeared. Leave the process looking like the one people know. Let the agent do the work inside each step, but keep the steps so people can still see that the answer is right.

Budget far more time for trust than for building. At that bank, the technical side was done in six to eight weeks. Then it took another four months of pilots before the advisers would rely on it. If you do something every day the same way for a year, any change has to earn its way in, whether you're handing it to 5,000 people or to five.

The 5-step roadmap to do it yourself

1. Watch the job and write down every step in the real order. Then ask why each step is done that way. If nobody can give a concrete reason, that's usually an old workaround nobody has questioned.

2. Decide which steps become AI and which don't. Hand the whole thing to a model and you join that 95% that produced nothing. Run every step through three filters:

• Does it follow a fixed rule that must come out right every time? Then it stays ordinary software, no AI needed.
• Does someone have to read something messy and make a judgment call? That's the part the model is for.
• What does it cost when it goes wrong? If getting it wrong is expensive, it stays with a person, even when a model could do it.

You'll almost never find the whole process should be AI. In one eight-step example, four steps ran on their own, three ran with a person checking the output, and one stayed fully human, because it was a business call AI can't make yet.

3. Build for the ways it fails, not just the happy path. When there's one way something goes right, there are a thousand ways it goes wrong. With AI that mostly means handling the places where the model isn't sure, because it hands you an answer either way, even when it has no idea.

4. Prove it works before it goes near anything real. A model gives a slightly different answer every time, so testing a few times misses the rare failures. Instead, take real examples from the process where you already know the right answer, run the system across all of them, count how many it got right, then read the misses and fix those.

5. Put a number on what it was worth. Money in, cost out, or risk reduced. Nothing else counts. Cursor had someone complain an agent cost him $2,000 a day, until they asked what it was doing: picking which engineer to send to fix broken equipment. Sending the wrong person cost him more than $2,000 a day. He'd only ever looked at what the agent cost, never what it saved.

Takeaway: The build isn't the hard part anymore. The judgment about what to automate, where it fails, and what it's worth is the job.

What you actually need to be good at

Companies hiring for this want people who are wide across business and technology, with one area they're genuinely deep in. They say the business half gets taught on the job and the technical half doesn't. For you it's probably backwards: focus on the business half, because the building is handled by agents now.

A Palantir exec put it sharply. The person who fails at this job is the careful engineer who wants code that still holds up in 10 years. The job is getting something rough in front of a real user quickly, which is basically what an agent like Claude Code hands you on the first pass anyway.

How we used this ourselves

These five steps are how we built our internal chatbot: a chat interface that lets the non-technical people on our team use Claude Code and everything it can do. HR and accounts aren't engineers, and everything around Claude Code assumes you are one, so the interface does the connecting to Slack, email, and the rest, and they just type what they need.

But we didn't start by building. Our engineers sat with HR and accounts first, because engineering had no real idea how those departments spent their days. They wrote down every repetitive thing done by hand, worked out which a model could take over, and that document turned out to be most of the build. The written-up processes became the instructions the agents follow and the knowledge the chatbot answers from. Then we handed the first version back and had those teams use it on real work, and they came back saying it saved them time.

Where to start

The place to begin is the smallest business you can physically walk into: where 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, while they actually do it. Then run the five steps on what you saw.

What comes out is called an audit, and it's a real thing businesses pay for. The people who run these projects inside big companies start every one with an audit before anything gets built, and they say that first phase is the biggest bottleneck in the whole job. It's also what you put in front of people, whether you're applying for an FDE role or pitching a business directly, because inside it you've got one real company's process written down, the steps you'd hand to AI, and what each is worth in money.

FAQ

What does FDE stand for? Forward deployed engineer. Someone whose job is getting AI running inside a business's existing systems, so work done by hand gets done by AI instead.

Do I need to be a strong engineer? Less than you'd think. The building is increasingly handled by agents. The scarce skill is the business judgment: which steps to automate, where the model fails, and what the result is worth. The careful, perfectionist engineer tends to fail at this job.

Why do so many AI projects fail? MIT found 95% produced no measurable return, because companies slap generic tools on top of processes nobody actually studied first. The fix is auditing the process before building.

How do I decide what to automate? Run each step through three filters: fixed rule (keep it as software), messy judgment call (good for a model), and high cost of being wrong (keep it human).

How do I break in with no experience? Sit next to whoever does the most repetitive job in the smallest business you can access, run the five steps, and produce an audit. That document is what you show when applying or pitching.

The takeaway

The tools are not the hard part, and they haven't been for a while. The bottleneck is someone who will actually watch how the work is done, decide what should and shouldn't become AI, and prove the result was worth it. That person is the forward deployed engineer, the demand is far ahead of the supply, and you can start with an hour and a notepad in the nearest small business.

Our curated roadmaps and guides for the FDE role live inside AI Labs Pro.