Let me tell you what I keep seeing, because I think it explains why so much AI money is going nowhere.

Companies have bought in. They’ve run the pilots, sat through the demos, nodded at the slides. And then, mostly, nothing ships. The pilot stays a pilot. Eighteen months later a board member asks why the thing they approved isn’t doing anything yet, and nobody has a clean answer.

Here’s the part people get wrong. They assume it’s a technology problem, or that they picked the wrong model. It almost never is. IBM’s consulting boss Mohamad Ali said it pretty plainly back in May: the problem isn’t the vision or the tech, it’s the operating model. Which sounds like consultant-speak, but he’s right. The way work actually gets delivered, who sits where, who’s on the hook for the result, how the people thinking about the problem connect to the people building the fix, that whole machine was built for a different era. And it’s the thing quietly killing AI projects.

Which brings me to the job everyone’s suddenly fighting to hire.

So what’s a forward deployed engineer?

The role didn’t start at IBM. Palantir came up with it back in the mid-2000s, and honestly out of necessity more than strategy. Their early clients were government and defense, the kind of places where the data is so sensitive and the systems so weird that you can’t just take a spec home and email back a solution. Somebody had to physically sit inside the customer’s world, figure out the real problem in context, and build the fix right there. Palantir called them Deltas. For a while they had more of those embedded engineers than regular software engineers, which tells you how much of the actual value lived in the field and not in the office.

Fast forward to now, and that exact shape keeps showing up with AI. The data’s a mess. Every company’s architecture is its own snowflake. The compliance people won’t bend on governance. And the gap between “cool idea” and “running in production” needs to close in days, not the better part of a year.

A forward deployed engineer, FDE for short, is the person who closes that gap. The good ones are a weird blend of three jobs that used to be three separate people. Part engineer, part consultant, part business person. They can hear a problem, design the answer, and build it right there in the place where it’s going to run, while the customer’s watching. They’re not strategists who hand you a deck. They’re not contractors banging out someone else’s spec. They’re both at once, which is exactly why they’re hard to find.

One person can’t carry it, though

Here’s the catch, and it’s the bit I think IBM gets right.

The fact that everyone wants FDEs isn’t the answer. It’s the symptom. It’s the market telling you the delivery model is broken. Because no single human, however good, is going to personally untangle fragmented data and a knotted architecture and the governance reviews and the “ship it to prod by Friday” pressure all at once. You hand all that to one brilliant engineer and what you get is a burned-out brilliant engineer and a project that’s still late.

So IBM’s move is to stop treating it as a hero role and wrap a team around it. They call it a forward deployed unit, an FDU. And the structure is the whole point. It’s not a person, it’s a pod. Humans on the outside (a business domain person who rethinks the actual process, an architect who connects the strategy to the build, engineers who make it real and scale it), and in the middle a bunch of specialized AI agents doing the grunt work. The coding, the testing, the evaluation, the documentation. All of it under human direction, not running loose.

The numbers are what make finance people sit up. IBM says a six-person FDU can do roughly what a thirty-person team used to do, at meaningfully better cost, and the methods get sharper each time they run an engagement. That’s the actual pitch for AI as an operating model instead of a fancy autocomplete. Not “everyone types faster.” The team is shaped differently. They say it’s already live with Riyadh Air, Nestlé, Heineken and Pearson, and they’re rolling it out across Asia Pacific, Europe and the US.

There’s a second thing the pod fixes, and I think it matters more than the cost. Old-school consulting splits the thinking from the doing. Strategy gets handed off, and somewhere in that handoff the context leaks out and you end up building slightly the wrong thing. With agent-based AI that’s fatal, because these systems don’t go quiet after launch. They need constant tuning, governance, plumbing into the real workflows. The FDU is built to keep going instead of packing up at go-live, and it measures progress in working systems, not documents. It also leaves the client able to run the thing themselves afterward, which most vendors are not exactly motivated to do.

What the job actually looks like

If you’re trying to hire for this, or fund it, it helps to picture the person.

An FDE is senior, full-stack, and weirdly comfortable being uncomfortable. They answer to a pod that’s on the hook for a business result, not a technical checkbox. They spend their days inside the customer’s systems and data, not back at some vendor HQ. The thing that really defines them is range. They’ll go from a whiteboard chat with a line-of-business lead in the morning to elbow-deep in a broken data pipeline after lunch, and they don’t think either one is beneath them. IBM, for what it’s worth, runs a dedicated technical career track for these folks and recruits out of the top engineering schools, which says they see it as a real profession and not a staffing fad.

The skills, the real ones

The technical bar is genuine. You need to actually code (Python, Java, TypeScript, C++, that family), plus data engineering, at least one cloud platform you know cold, CI/CD, and a working feel for security and access controls. And now, in the agent era, you’ve got to know how to build and wrangle and evaluate AI agents too, because in an FDU you’re basically directing a little digital workforce, not typing every line yourself.

But honestly? The technical stuff is the easier half. What separates a fine FDE from a great one is the human side. Being able to translate, in real time, between what a CFO is worried about and what a system can actually do. Patience with ambiguity. Figuring things out when there’s no documentation because nobody’s solved this exact problem before. The best ones are basically trusted advisors who happen to ship code, and that’s the part the agents can’t replace. The agents handle the volume. The person supplies the judgment.

A day in the life, more or less

There isn’t really a typical day, which is sort of the point. But here’s a composite that feels about right.

Morning kicks off inside the client’s world. A stand-up with the customer’s own engineers and a business owner, treated like teammates rather than people you’re delivering to. Some new fire pops up. Say a fraud-detection workflow is throwing way too many false positives and the business is getting twitchy about it. By mid-morning our FDE is digging through the data, tracing where the model’s inputs are going sideways, and handing the boring stuff (test cases, first-draft docs, scaffolding) to the pod’s agents, then checking what they spit back.

Around lunch the conversation jumps a level. They sit with the architect and the domain specialist and argue it out: patch what’s there, or redesign the workflow? And there’s a governance rule the client’s risk team flat out won’t waive, so that constrains things. Because the same pod designs and builds, that argument turns into committed code the same afternoon instead of a recommendation in next month’s deck. Before they log off they walk a client engineer through the change. Not a handoff. More like deliberately teaching, so the customer can actually run this after the unit’s gone. Nobody measures that day in billable hours or slides produced. It’s measured in one working system that does something today it couldn’t do yesterday.

Why this is the job the moment needs

For decades, the way you scaled delivery was simple. Add people, get more output. AI breaks that math. Now the output depends on how well you build and coordinate agents, hold the governance line, and turn raw capability into something the business can actually use. And that’s a property of how you’re organized, not how many bodies you’ve got. The FDE is the human in the middle of that, and the FDU is the structure that lets one person’s judgment stretch across a pod of agents and the client’s whole workflow.

So the companies that win the next stretch of AI probably won’t be the ones with the best model. Everybody’s getting the good models. They’ll be the ones who actually rewire how the work gets done, who get the people and the platform and the operating model into one system that ships and keeps the value running long after launch. Which is the real reason “FDE in an FDU” is less a job title and more a bet on how this whole AI thing finally starts paying for itself.

---

Sources: IBM Newsroom, “A New Way to Make AI Actually Work in the Real World,” Mohamad Ali, May 14, 2026; The Pragmatic Engineer, “What are Forward Deployed Engineers, and why are they so in demand?”; Palantir Blog, “A Day in the Life of a Palantir Forward Deployed Software Engineer”.

#ForwardDeployedEngineer #FDE #ForwardDeployedUnits #EnterpriseAI #AIDelivery #AIOperatingModel #AgenticAI #AITransformation #FutureOfWork #IBMConsulting #AIinBusiness #AIAdoption #DigitalWorkforce #AIStrategy #TechHiring how to make enterprise AI work, moving AI from pilot to production, AI delivery model, scaling AI in business, forward deployed engineer vs consultant, AI pod team structure