Forward deployed engineering for enterprise AI

This is the context in which the role became famous. Enterprise AI has a last-mile problem, and the last mile runs through somebody else's building.

Where pilots actually die

MIT's Project NANDA published "The GenAI Divide: State of AI in Business 2025" in July 2025, reporting that 95 percent of generative AI pilots delivered no measurable profit-and-loss impact and only 5 percent of integrated systems created significant value. The sample was 52 executive interviews, surveys of 153 leaders and analysis of 300 public deployments, which is worth stating whenever the number is used.

The reported causes are consistent and none of them are about the model.

Data nobody audited before the build. The pilot ran on a curated extract. Production has the nulls, the three spellings of the same category, and the records from a migration in 2019 with a different shape.

A success metric nobody defined before sprint one. Which means at the end there is no agreed answer to whether it worked, so it does not get funded further.

Users who were not involved in designing the workflow. So the system is correct and nobody uses it, because it does not fit how the work is actually done.

Why none of the three is fixable from outside

Each one requires being inside the environment.

Auditing data means querying the real tables, not reading a schema document. The schema is a historical artefact; the data is the truth.

Defining the success metric means getting a room of people who disagree to commit to a number. For an AI system that number is uncomfortable: what error rate is acceptable, what happens on a wrong answer, who gets told. Nobody wants to be the person who said 3 percent was fine. That conversation happens in the room or it does not happen.

Involving users means sitting with them, which surfaces the exception covering 15 percent of cases and the spreadsheet somebody maintains by hand. Discovery inside the customer environment covers the technique.

The structural difference with AI work

Traditional integration started from a specification the customer could write. AI work cannot, and this is the thing to internalise.

Nobody knows the acceptable error rate, the edge cases, or the escalation path until the system runs on real data with real users. So the specification is an output of the engagement rather than an input to it, which breaks fixed-scope contracting and is why pricing works differently here.

It also means the pilot is not a smaller version of production. It is an instrument for producing the specification. Treating it as a proof that the thing works, rather than as a way to find out what correct means, is how a successful pilot produces no production system.

What an embedded engineer actually does about each

On data: queries it in week one, produces the list of what is different from the description, and rescopes. The uncomfortable finding is the deliverable. What a forward deployed engineer ships in week one covers why that happens first.

On the metric: forces the definition before production, in writing, with a named measurer. An outcome you cannot measure on the day you agree it is a hope, and outcome-based pricing covers how to write one that holds.

On users: sits with them, then designs the escalation path around what they actually do. For an AI feature this is most of the design work: what happens when the model is unsure, who reviews, and what the person sees.

On the release path, which the MIT framing understates: maps what it takes to get a change into production at this company and plans the schedule around it. This is where more deployments are lost than in any of the three above, and it is entirely predictable in week one.

What changed on the demand side

AWS framed its own $1 billion commitment around a shift in what customers want: Francessca Vasquez, VP of Frontier AI Engineering and Services, described customers as having moved past exploring what AI can do and wanting it core to how they operate. It named regulated sectors, financial services and government as focus areas.

That matches the hiring data. Among 1,000 postings that named a target industry, financial services led at 24 percent, government and defence 18 percent, healthcare 17 percent, insurance 17 percent. These are the sectors where the environment rather than the model is the hard part.

The verification point, which is not optional here

An AI system inside somebody else's production environment needs stronger verification than one in your own, because a wrong answer is their incident, their regulator and their customer relationship.

Generated code is not secure by default, and the model's own outputs need grading by something independent of the model. Checks derived from the specification, written before the code exists, graded separately. That is eval-driven development, and never letting the model grade its own work is the part that makes it mean anything.

This also produces the handover artefact that matters: the customer's team inherits the checks, so they can change the system and still know whether it works.

The honest summary

Most enterprise AI failure is not a model problem, a data-science problem, or a tooling problem. It is three organisational problems and a release path, all of which live inside the customer's building.

That is why the role exists, and it is also why it does not always apply: if your pilot has a named production owner, a defined metric, audited data and a mapped release path, you may not need anyone embedded. You need to finish.

The three sectors where this concentrates each add their own binding constraint, and the constraint shapes the engagement more than the technology does: financial services, where it is the audit trail; government and defense, where it is clearance and disconnected environments; and healthcare, where the data cannot leave and the workflow cannot stop.

Next: forward deployed engineering for AI agents, which is the specific version of this problem most engagements now involve.