The forward-deployed engineer is the missing role in business AI

There is a name for the gap I keep finding between an AI demo and a useful system.

The forward-deployed engineer.

An FDE works inside the problem. They sit with the people doing the job, learn how the process really works, decide where AI belongs, and then build the thing into the systems the business already uses.

That sounds obvious. It is also the part most AI projects skip.

The usual process starts with a solution. Somebody has seen an agent, a chatbot or a clever demo and asks where they can put one. A team builds it. The demo works. Then it meets the actual business: incomplete data, undocumented exceptions, old software, security rules, worried staff and the one spreadsheet nobody mentioned in the kickoff meeting.

The model was not necessarily bad. The diagnosis was.

Building is no longer the scarce part

Two years ago, being able to build an AI application was a meaningful edge. Models were harder to use, tool calling was new and the infrastructure around agents barely existed.

That has changed quickly.

The same frontier models are available to everyone. Claude Code, Codex and the rest can produce working software at a speed that would have sounded silly not long ago. A competent operator can get from an idea to a convincing prototype in hours.

But easier building has not made it easier to choose the right thing to build.

It has made the cost of choosing badly less visible.

You can now produce the wrong system beautifully and at remarkable speed.

The often-repeated figure that 95% of enterprise generative-AI pilots produce no measurable return comes from the 2025 MIT Project NANDA report. It is worth being precise about that number: it concerns measurable financial impact from the pilots studied, not a universal law that 95% of AI software is technically broken.

The distinction matters. Many of these systems can work exactly as demonstrated and still create no business value.

The real shortage is not access to AI. It is the judgement required to connect AI to valuable work.

A business does not run like its process document

I wrote recently that the bottleneck in building agents is human communication.

Every business has three versions of a process.

There is the official version in the procedure. There is the version the software appears to enforce. Then there is the version people actually perform when Monday morning arrives.

That third version contains the business.

It contains the customer who always needs an exception, the check an experienced employee does without thinking, the reason one field is ignored, and the point where somebody knows to stop and ask a manager. Much of it has never been written down because the people doing it no longer notice that they know it.

You cannot discover that from a requirements form. You find it by watching the work, asking awkwardly simple questions and following the exceptions.

This is the first job of the forward-deployed engineer. Not prompting. Not coding. Finding out what is true.

AI should rarely run the whole process

Once the real workflow is visible, every step needs a decision.

Some steps belong in normal software. If a rule is fixed and the answer must be exact every time, code it as a rule.

Some steps suit a model. Reading an untidy document, interpreting a free-text answer or making a bounded judgement across messy information are things modern models can do well.

Some steps must stay with a person. The consequence of being wrong may be too high, the decision may require authority, or the situation may be too unusual to justify automation.

A good deployed system is normally a mixture of all three.

This is where many agent projects go wrong. The model is given the entire process because the point of the exercise was apparently to use a model. Reliability is then treated as a prompting problem when the real architectural mistake was asking AI to do work that should have remained deterministic or human.

The FDE is responsible for drawing those boundaries and changing them when production evidence says they are wrong.

The existing systems are part of the job

Businesses rarely need another isolated AI interface.

They need their existing ATS, CRM, inbox, document store, finance platform or internal database to do something it could not do before. The new capability has to respect the permissions, terminology, audit requirements and working habits already around it.

Replacing all of that is normally unrealistic. The business has already spent years filling those systems with data and teaching people how to use them.

The useful work is integration: APIs, tools, queues, webhooks, approval steps, identity, logging and a clean route back to a person.

This is one reason the FDE has to be an engineer rather than an adviser who hands over a slide deck. Discovery and implementation cannot be cleanly separated. What you learn while integrating changes your understanding of the process, and what happens in production changes it again.

A live system teaches things a prototype cannot

I have seen this directly in recruitment onboarding.

An early system was useful and handled real work. It also exposed the things a demo could not: rate limits, concurrent conversations, session behaviour, channel security, model cost and the awkward edges between AI decisions and the recruitment platform around them.

The answer was not a larger prompt.

We separated the recruitment business logic from the AI execution layer. We broke the work into configurable steps, reduced the context each step needed, added structured handoffs and model controls, and then moved the pipelines towards durable serverless infrastructure.

That redesign came from deployment. The first version was not wasted work; it was how we learned what the real system needed to be.

Forward-deployed engineering treats production as a source of evidence. Build, observe, correct and turn the parts that repeat into reusable infrastructure.

Trust takes longer than the build

Even a technically sound system can fail if the people doing the job do not trust it.

If an established eleven-step process suddenly becomes one unexplained answer, the team has lost all the points where they used to check the work. The new system may be faster, but it feels less controlled.

Adoption has to be designed.

That means showing evidence, preserving useful checkpoints, recording why decisions were made, escalating uncertainty and making it easy for a person to take over. It means testing with real cases, including the strange ones, rather than five examples invented by the build team.

It also means listening after launch. Policies change. Customers find new paths. Staff develop new workarounds. Model behaviour changes. A deployed AI workflow is an operated system, not a finished artefact.

The large AI companies have reached the same conclusion

The title is suddenly appearing everywhere because the deployment problem has become impossible to ignore.

OpenAI’s Deployment Company describes FDEs working alongside operators and frontline teams, beginning with a focused diagnostic and then designing, building, testing and deploying production systems around the customer’s data, tools and controls.

AWS has committed $1 billion to forward-deployed engineering, explicitly arguing that enterprise AI has moved beyond the advisory model.

Anthropic and DXC are training forward-deployed engineers to bring Claude into the regulated systems used by banks, airlines, insurers, manufacturers and governments.

These companies are not investing in the role because businesses need more AI presentations. They are doing it because the final mile between a capable model and dependable operational value is mostly business-specific work.

What businesses actually need

Most businesses do not need to begin with an AI strategy.

They need someone to find one costly, repeated process and understand it properly.

Start with the volume. Sit with the person doing the work. Write down the real steps. Find the hidden rules. Decide what should be software, what should be AI and what must remain human. Put a value on the outcome. Then build the smallest version into the environment where the work already happens.

If it works, measure it and expand carefully. If it does not, learn before spending more.

That is not traditional consulting and it is not ordinary software delivery. It combines diagnosis, engineering, product judgement, change management and operational responsibility in one role.

The model is no longer the moat.

Knowing where it belongs—and staying long enough to make it work—is becoming the valuable part.