Forward deployed engineers alone won't fix your AI adoption problem. Here's what will

A forward deployed engineer will get your first AI workflow into production. That is what the model is built for, and it genuinely works. What it does not do on its own is leave your organisation able to build the next three without them. That gap, between one successful deployment and a standing capability, is where most enterprise AI programmes are currently stuck.

Forward deployed engineer used to mean something specific. Palantir built the model in the early 2010s: a senior engineer embedded inside a customer's environment, with commit rights on their stack, judged on whether the system worked in production. No handoff, no deck, no separation between the person who scoped the problem and the person who shipped the fix.

In 2026 the title has spread everywhere, and it now tells you almost nothing on its own. What matters is the substance behind it: who has commit rights, what gets left behind, and who owns the outcome once the engagement ends.

The title spread faster than the substance

OpenAI now runs its own forward deployed engineering function, and in July 2026 it launched Presence, an enterprise agent platform delivered exclusively through those engineers and a short list of named systems integrators rather than self-serve. Anthropic is hiring applied AI engineers on the same embedded model. EY launched forward deployed engineer roles across the UK and Ireland in April 2026, and the other large consultancies are expected to follow.

When a job title arrives everywhere at once, it is usually because it is solving something real. In this case it is. The question is what you are actually buying when someone offers you one.

What the forward deployed engineer model genuinely solves

The model exists because a specific failure pattern kept recurring. A consulting team hands over a roadmap, an internal team inherits half-finished integration work, and the AI system never reaches production. Removing the handoff removes the failure point. One team scopes the workflow, writes the integration against real production data, and gets paged when it breaks.

For a single well-defined workflow with an unclear technical path, that structure works, and it works fast. It is also why we use it. Embedding senior engineers directly in a client team is the first tier of how we deliver, and it is the reason we can ship things like an AI-powered property valuation platform for Upstix in seven days. You cannot move at that pace through a statement of work and a fortnightly steering committee.

So this is not an argument against forward deployed engineers. It is an argument about what happens on the day they leave.

Why every model provider suddenly wants one

Whoever owns the last mile into a customer's production systems owns the relationship, the renewal, and increasingly the model choice too. That is the part worth reading carefully in the Presence launch. It is a forward deployed engineering model in service of a product, and the product runs on one provider's models.

Those engineers are not neutral, and there is no reason they should be. Their job is to get you live on the platform, not to leave you able to run agentic work on whatever stack turns out to fit your organisation in eighteen months. If your agent strategy is going to outlive the current model generation, that distinction matters more than it looks today.

What embedding an engineer doesn't solve

The industry's own numbers make the gap obvious. Kyndryl's 2026 People Readiness Report found that 57% of enterprises now have AI embedded in core business processes or deployed broadly, up from 35% a year earlier, but only 11% have achieved both of their top two AI objectives. McKinsey's state of AI research puts scaled agentic adoption in single digits within any individual business function, and its work on AI spending has been widely reported as finding that 93% of enterprises exceed their AI budgets, with a large share of that overspend going into refining and correcting agent responses rather than the task itself.

None of that is a deployment problem. Deployment, in the narrow sense of getting one workflow into production, is exactly the part the forward deployed model is good at. The gap is organisational. Teams have shipped one agent for one workflow, but they have no way to evaluate the next one, no shared standard for what production-ready means, and no internal capability to keep improving the system once the vendor's engineers move on to the next account.

An engineer who leaves once the workflow is live has not closed that gap. Often they have just moved it further out. We have written before about the related version of this problem, where organisations expect a single AI hire to carry an entire strategy. Embedding someone else's engineer instead of hiring your own does not change the underlying maths.

Deployment or capability - which are you actually buying?

Before you embed anyone inside your team, ask what they are optimising for once the specific workflow ships. If the answer is renewal on their product, you have bought a deployment. If the answer is that your team can run the next three without them, you have bought capability.

Both are legitimate purchases. A deployment is often exactly the right thing to buy, particularly for a first proof of value where the technical path is genuinely unknown. But they are not the same purchase, and conflating them is how organisations end up with a working pilot and no repeatable way to build the next one. It is worth being explicit about which one is on the table before contracts are signed, in the same way you would when choosing between a large consultancy, an embedded squad and in-house build.

How we run forward deployed engineering

We deliver in two tiers. The first is forward deployed engineers: senior engineers embedded directly in your team, writing code alongside your own engineers, moving at your pace, with none of the handoff overhead of a traditional vendor relationship. The second is an AI product squad, which is the same engineers plus product management and design in one embedded team, so the people deciding what to build are the people building it.

Because we do not sell a platform, those squads are not optimising for which model you end up locked into. That independence is the point. We build agentic systems against whatever fits the problem, and the architecture decisions get made on your constraints rather than ours.

The work is checkable. We built the agent system now supporting 5,000 Google Cloud sellers, taking it from concept to deployment in 90 days. We built the AI-native creative studio that took Tesco's retail-ad approvals from four weeks to days. Each of those started as a single deployment, and each was structured so the client team could keep extending it.

That is the shape of our model: Discover to find the problem actually worth solving, Build to ship it properly, and Scale to make it repeatable without us in the room. Successful innovation is not only about moving fast. It is about creating the conditions where teams feel confident enough to experiment on their own, long after the embedded team has gone home. If that is the problem you are trying to solve, start a conversation with us.

Frequently asked questions

What is a forward deployed engineer?

A forward deployed engineer is a senior engineer who works embedded inside a customer's team and environment rather than from a vendor's own delivery centre. They typically have access to the customer's production systems, write and ship code against real data, and are measured on whether the system works in production rather than on documents delivered. The model originated at Palantir in the early 2010s and has since been adopted by AI labs, consultancies and product agencies.

What is the difference between a forward deployed engineer and a consultant?

A consultant typically advises and hands over. A forward deployed engineer builds and stays until it works. The practical test is commit rights: if the person recommending the architecture is not the person writing and shipping the integration, the handoff risk that the model was designed to remove is still there, whatever the job title says.

Should we hire forward deployed engineers or work with an agency?

It depends on whether your constraint is throughput or judgement. Hiring works well when you already know what to build and need more hands on it. An embedded external squad is usually faster when the technical path is unproven, because you get people who have solved the same class of problem across several organisations and can rule out dead ends quickly. Most organisations end up doing both, with internal engineers owning the system long term and external squads used to open up new areas.

Why do most enterprise AI deployments stall after the first workflow?

Because the first workflow is a technical problem and the second is an organisational one. Shipping one agent proves the technology works in your environment. Shipping the next five requires shared evaluation standards, agreed definitions of production-ready, and enough internal confidence to make build decisions without the original team in the room. Those are capabilities that have to be deliberately built, and they rarely arrive as a side effect of a successful pilot.

How do you avoid model lock-in when a vendor deploys your agents?

Ask who employs the engineers doing the integration and what they are measured on. If they work for the model provider, the architecture will reasonably be built around that provider's platform. Keeping the orchestration, evaluation and data-access layers under your own control, and having them built by someone with no stake in which model wins, is what preserves the option to change your mind later.