Forward deployed engineers: the hottest job in AI and the modernization work it cannot skip

For anyone running a modernization program, the FDE story confirms something we have said for a while. The model stopped being the hard part a while ago. The state of the systems, the data and the processes the model plugs into is what still stops projects, and no embedded engineer changes that by showing up. Which is why the question that decides whether an FDE engagement works is not how good the engineer is. It is whether you can still run the thing after they leave.

Sources: CIO.com and The New Stack

Abstract

Within a ten day window in May, the forward deployed engineer went from niche to headline. OpenAI launched a $4 billion Deployment Company, Google Cloud opened dozens of FDE roles with salary bands reaching $265,000, Anthropic embedded engineers inside financial technology vendor Fidelity National Information Services (FIS) to co-build an anti money laundering agent, and ServiceNow and Accenture launched a joint FDE program. A columnist at The New Stack framed the role as AI's most durable new career and laid out a training path for it. A contributor at CIO.com read the same events and saw a dependency forming, quoting a Gartner analyst who predicts that by 2028 seventy percent of enterprises will abandon agentic AI projects delivered this way, because vendor costs stay high and internal teams never learn to run what was built. We reviewed both with Kishan Chamman, our CTO.

Review and insights

A job title for something that already existed. For all the noise around it, the FDE is not a new kind of person. Kishan's description on camera was blunt. An FDE sits close to a full stack engineer who also carries business and process knowledge and can sell an idea inside a company. The market took the multidisciplinary engineer, the one who understands a framework and the business at the same time, gave the combination a name and attached a senior salary to it. Worth knowing, because it tells you the supply is thin and the role is hard to fake.

The 20 percent that demos and the 80 percent that does not. One line from the reporting stuck with both of us: getting a demo running in a sandbox is roughly a fifth of the job. The rest is enterprise single sign-on, legacy extract-transform-load pipelines, regulatory constraints and prying production credentials out of a security team. Kishan's version, from years of enterprise and government delivery, is that building the system was never where projects die. They die in the ecosystem around it, in the months spent getting stakeholders to agree on what is being built and why.

Service, not software. The CIO piece has the cleanest reframe of the moment. CIOs think they are buying software. What lands is a professional services engagement, with a different cost model, a different dependency model and a different governance model. When a vendor tells you every agent decision is auditable and traceable, that is accurate and beside the point. The harder question is which decisions belong to the agent at all, and banks have spent decades building decision-rights frameworks that do not map onto an agent harness written by someone else's engineers.

The test that actually matters. A member of the Coalition for Secure AI gave the CIO piece its best idea, and we adopted it on the spot. After the forward deployed team leaves, can your organization operate, monitor, challenge and safely modify the workflow? If the answer is no, you have a successful implementation project and not yet a capability. A Gartner analyst puts a number on how often the answer is no: seventy percent of these engagements abandoned by 2028. Kishan's read from the field lands in the same range or worse. He reckons seventy to eighty percent of companies will fail that test, left running an agent they cannot maintain and paying the vendor to keep it alive.

The invoice, and who wrote it. This is the part that should make a CTO sit up. An independent analyst quoted in the CIO piece names a conflict of interest sitting inside the whole model. The vendor being paid to tame the complexity is often the same vendor whose model created it. If the business runs on embedded engineers billing to keep agents alive, where is the incentive to ship agents capable enough to not need them? It is fair to assume some of these offerings are shaped, on purpose, to keep the engineer in the building. The chief analyst at Greyhound Research put it more sharply, describing the result as "dependency with better stationery."

Version one and version two. So how do you take the help without buying the dependency? Kishan walked through how we scope this at Eli5, and it is the clearest answer we have to the CIO test. Start by finding the value rather than the tech. Sketch cheap prototypes across a handful of use cases, score them on effort against value, and move the low effort, high value ones first. Then ship in two versions on purpose. Version one is the quick win that proves what the tooling can unlock, deployed fast, not yet woven into the company. Version two is the embedded version worked in behind it, the one that arrives with the process changes, the internal support structure and the education that let your own people run it. The rule we hold to is that we never scope version one without version two. Building something the client cannot operate is how you end up in that seventy percent.

The link to modernization

This connects straight to the work we spend our days on. The reason so many of these engagements collapse once the engineers leave is not the agent. It is everything underneath the agent that nobody touched. Undocumented business logic, fragmented data, brittle integrations and processes that were never designed for software that acts on its own. AI tooling relies on accurate data and an accurate picture of the landscape, and most organizations have written down neither. Drop ten brilliant engineers into that and they will build something that interfaces beautifully with what you have. Leave it running for a month without changing the process underneath and it breaks. The FDE does not remove the modernization work underneath, it just makes skipping that work more expensive.

We watched the same story play out with digital transformation. Buying the tool was supposed to fix the company. It did not, because nobody changed the processes or brought the people along. Swap the word transformation for AI and the failure mode is identical.

Concluding remarks

The forward deployed engineer is a real role doing real work, and the salaries are not a bubble in the way prompt engineer was in 2023. The demand is genuine, because deploying an agent inside a live enterprise is harder than most people expect. What has not changed is the thing underneath it. Before any model earns its keep inside your organization, someone still has to deal with the legacy systems, the messy data and the workflows that were never built for intelligent software. That work does not get faster because a vendor sends an engineer with a famous logo behind them.

For a CTO or PO watching this, two moves are worth avoiding. Doing nothing is the worst one. Signing a single vendor engagement before you understand your own stack is close behind, because the first engineer who sits down also sets the defaults for which model, which tools and which integrations you end up married to. Get an independent read on your systems first. Know which workflows are ready to be rebuilt around AI and which ones need modernization before anyone touches them. Then decide who you want holding the pen, and make sure the deal you sign hands you something you can run on your own.

‍

‍

Full video episode: Forward deployed engineers: the hottest job in AI and the modernization work it cannot skip

The first step to start your modernization journey

Software modernization and architectural rebuilds lie at the heart of Eli5. We solve complexity to deliver direct business value by focusing on pragmatic, cloud-native transitions.

Before you decide whether to wrap your legacy system, buy a new SaaS product, or use AI to build custom tools, you need total visibility into your current tech landscape.

Would you like to book a free brainstorm to discuss your legacy stack? It is the essential first step to turning your technical debt into a scalable, modular future.

‍

‍

‍