Forward Deployed AI Is Becoming a Standalone Market Category

The most interesting development in enterprise AI this year didn't come from a model release.

It came from how quickly Forward Deployed Engineering is being turned into a formal thing that companies name, fund, and sell. Three moves inside a single quarter make the pattern hard to miss:

• In May 2026, OpenAI launched the OpenAI Deployment Company, backed by $4 billion of initial investment from 19 partners and staffed from day one with around 150 Forward Deployed Engineers and Deployment Specialists via its acquisition of Tomoro
• In June 2026, Amazon Web Services committed $1 billion to Forward Deployed Engineering, and extended the model to its consulting partners through a partner-led programme
• In July 2026, Tredence launched a domain-native FDE practice and committed to hiring 200 forward deployed engineers over 12 to 18 months, rather than growing a traditional AI consulting team

Individually, each one reads like a staffing decision. Together they look like the early shape of a market category.

The underlying message is fairly blunt. The hard part of enterprise AI has moved. Building AI is no longer where the scarcity sits. Embedding AI inside a real organisation is.

That distinction sounds small. It changes who gets paid well, what buyers are actually purchasing, and which skills hold their value over the next few years.

The term came out of Palantir, where engineers were sent to sit inside client organisations rather than shipping software from a distance and hoping it landed.

A forward deployed engineer works on the customer's ground. They learn the customer's data, their workflows, their approval chains, their odd exceptions, and the reasons things are done the way they are. Then they build against that reality rather than against a tidy spec.

It's a deliberate rejection of the clean handover. There's no moment where the product team throws a platform over the wall and a services team picks it up.

Traditional consulting produces recommendations, roadmaps, and slide decks that describe what should happen. Forward deployed work produces running systems inside the customer's environment, built by people who understand both the technology and the specific mess it has to survive.

The role sits awkwardly between product engineering and consulting, which is exactly why it's been hard to hire for and hard to price. What's changing now is that companies have stopped treating it as an awkward hybrid and started treating it as a distinct function with its own budget line.

Each of these moves tells you something slightly different.

OpenAI setting up a separate deployment company is the strongest signal, because it's a lab admitting that shipping the model isn't enough. If the frontier of capability were still the binding constraint, you'd pour everything into research. Creating a distinct commercial entity for deployment says the value is now leaking out somewhere between a capable model and a working business process.

The composition of that entity is worth a second look. It's a partnership with 19 investment firms, consultancies, and system integrators, led by TPG, with Bain & Company, Capgemini, and McKinsey among the founding partners. The big consultancies aren't being disintermediated here. They're buying into the delivery layer alongside the lab, which tells you they see the same thing OpenAI does.

The AWS commitment matters for a different reason. A billion dollars is a large number, but the revealing detail is the partner-led element. AWS is having partners stand up ring-fenced, AWS-credentialed engineering teams, with engineers passing an AWS-defined technical bar before they touch a customer. As the announcement puts it, the shift is from counsel to outcomes.

That's how a practice becomes an industry. When a hyperscaler pushes a delivery model through its partner network and attaches a certification standard to it, thousands of firms restructure their teams around it, and the category gets both a supply chain and a quality bar.

Specialist firms launching FDE practices instead of AI consulting teams is the quietest signal and possibly the most telling. Tredence framed its version around domain depth rather than engineering depth: retail FDEs who understand markdown cycles, supply chain FDEs who understand network constraints. These are businesses that live or die on billable positioning. They don't rename a practice on a whim. If they're leading with embedded delivery, it's because that's what clients are asking to buy.

Three separate parts of the market, arriving at the same conclusion inside a single quarter. That's usually a sign the constraint is real rather than fashionable.

A few years ago, getting a capable model into production was genuinely hard. You needed people who understood training, evaluation, inference costs, and a stack that changed every few months.

Most of that has been commoditised.

Frontier models are available through an API to anyone with a credit card. Orchestration frameworks are mature enough to be boring. Vector stores, evaluation harnesses, agent runtimes, and gateways are all off-the-shelf now. A competent team can stand up an impressive demo in a fortnight.

The result is that capability has become abundant while outcomes have stayed scarce.

This is the pattern that shows up whenever a technology matures. Access stops being the differentiator and application takes its place. Cloud went the same way. Once compute became a utility, the money moved to the people who could migrate an estate without breaking the business.

AI is hitting that point faster than cloud did, partly because the tooling improved so quickly and partly because the models themselves absorb work that used to need custom engineering.

The gap between a working demo and a working deployment is where most enterprise AI programmes stall, and it's rarely a technical gap.

What actually blocks progress tends to be organisational:

• data that's technically accessible but semantically ambiguous, where two departments use the same field to mean different things
• processes nobody has documented, held together by people who know the exceptions
• approval chains that were designed for human decisions and don't have an obvious place for an agent
• risk and compliance functions that need a defensible answer before anything touches customer data
• existing systems that can't be replaced and have to be worked around
• teams who've watched previous transformation programmes come and go, and are waiting to see if this one is different
• success criteria that were never agreed properly, so nobody can say whether the thing is working

None of that is solved by a better model, and none of it is solved by a strategy document either.

It's solved by someone sitting inside the organisation for long enough to understand why the process is shaped the way it is, then designing something that fits. That takes time, judgement, and a tolerance for the unglamorous parts of the work.

It's also close to impossible to package as a product. Which is precisely why it's valuable.

Commodity tooling competes on price. Once several vendors offer a comparable capability through a comparable interface, the buyer's obvious question is what it costs, and margins compress from there.

Embedded delivery doesn't work like that.

When the deliverable is a working system inside a specific organisation, there's no like-for-like comparison. The buyer can't run a straightforward bake-off, because the value depends on how well the supplier understands their particular environment. Switching costs rise as the engagement deepens, and the knowledge built up during delivery lives partly in the people doing the work.

That produces a different commercial posture. You're not selling seats or tokens, you're selling an outcome that only exists once someone has done the work of understanding the customer.

There's a second effect worth noticing. Forward deployed work generates something the vendor can't get any other way: a detailed, current picture of where real deployments actually break. For a lab like OpenAI, that feedback is arguably worth more than the consulting revenue attached to it.

So the move up the value chain runs in both directions. Higher margin on the way out, better product intelligence on the way back in.

If you're buying AI help, the useful question has changed. Asking a supplier what they can build tells you very little now, because most credible suppliers can build most things. Ask instead how they plan to operate inside your constraints, who will be sitting with your teams, and what happens to that knowledge when the engagement ends.

Be wary of anyone selling embedded delivery who's really selling a fixed methodology. The whole point of forward deployed work is that it adapts to your reality. A supplier arriving with a rigid framework has misunderstood the model.

Pay attention to how a supplier talks about the end of the engagement. The AWS programme describes systems structured for self-sufficiency rather than ongoing dependency, which is the right test to apply to anyone. Embedded delivery can quietly become permanent delivery if nobody agreed upfront what handover looks like.

There's a build-versus-buy dimension too. Some organisations will want this capability in-house, because the accumulated understanding of their own processes is a genuine asset. Others will bring it in and accept that some of the learning walks out of the door afterwards. Both are defensible, but it's worth deciding deliberately rather than by default.

For anyone thinking about their own positioning, the skills that hold value in this market are a mixture that's historically been rare. Technical depth on its own isn't enough. Neither is stakeholder management. What's scarce is the combination: people who can design a system and also read a room, who can talk to a compliance lead in the morning and debug an agent's tool calls in the afternoon.

Those people were always useful. They're now the constraint on an entire category.

Forward Deployed Engineering becoming a named market category is a signal about where enterprise AI actually is right now.

The models are good. The tooling is available. What's missing is the connective work of getting capable systems to function inside organisations that weren't designed for them, and that work resists being productised.

A frontier lab, a hyperscaler, and the specialist firms all reached the same read on this inside three months, and the large consultancies put money into it rather than defending their existing model. That convergence suggests a durable shift rather than a passing structure.

The competitive question for the next few years probably isn't which model an organisation uses. It's whether anyone in the building understands the organisation well enough to make the model useful.