Forward Deployed Engineering: Why Agentic AI Doesn't Ship Itself

I have been parachuted into complex enterprise environments where the access was limited, the systems were fragmented, the processes were undocumented, and the expectation was still one sentence long. Make it work.

That is the real work behind enterprise deployment, and it was never just deployment. It was translating messy customer reality into production systems that actually held up. Sit between the customer, engineering, product, SRE, QA, operations, and the business leaders. Understand the operating model. Turn a business problem into a technical design. Work through the constraints nobody documented. Coordinate across teams that do not report to you. Stay close after go-live, and own the outcome when reality hits and the clean demo meets the dirty edge case.

I recognize the model the industry is now spending billions to name, because I have lived it for years, long before the market had a clean label for it. Today a version of this is called Forward Deployed Engineering, and in a nine-week window in the middle of 2026 it went from a niche Palantir term to the most expensive bet in enterprise AI. This piece is about what that spending admits, and why it is the clearest signal yet that agentic AI does not ship itself.

The market just gave it a name, and a very large number

Start with the number, because the number is the argument. In nine weeks, four of the most important companies in AI committed to embedding their own engineers inside customers to make AI actually work in production. Not to sell more licenses. To go sit inside the building and get the thing running.

The details matter, and so does one honest caveat. Anthropic announced a roughly $1.5B joint venture on May 4, backed by private equity, explicitly modeled on Palantir forward-deployment approach and aimed at mid-market firms. A week later, on May 11, OpenAI launched the OpenAI Deployment Company, a roughly $4B venture that acquired a firm bringing about 150 forward deployed engineers with it. On June 30, AWS stood up a dedicated Forward Deployed Engineering organization backed by $1B, describing it as agentic-first, delivered in small pods embedded per customer, and designed so the customer is self-sufficient when the engagement ends. Two days later, on July 2, Microsoft announced the $2.5B Frontier Company with 6,000 embedded experts.

The caveat: Microsoft leadership was careful to say Frontier goes beyond what has been labeled Forward Deployed Engineering, so grouping it under FDE is the press framing, not Microsoft own. That is worth respecting. But the shape is unmistakable across all four. Send our own engineers into the customer, co-build against the customer real systems, and stay accountable for a measurable outcome. When four rivals independently reach for the same expensive move in the same nine weeks, they are not following a fashion. They are responding to the same problem.

What Forward Deployed Engineering actually is

The role was created at Palantir in the early 2010s, where it was named internally, without much ceremony, the Delta. Until around 2016, Palantir employed more forward deployed engineers than regular software engineers, which tells you how central the model was to how the company actually delivered. The Pragmatic Engineer has the clearest account of the history and the role, and it is worth reading in full.

The definition is simple, and the simplicity is the point. A forward deployed engineer embeds inside the customer and writes production code in the customer environment. They are not a consultant who analyzes the problem and hands back a recommendation, and not a sales engineer who demonstrates the product and moves on. They build the thing, in the customer systems, and they own whether it works. At Palantir the work often meant configuring and extending an existing platform rather than writing everything from scratch, but the accountability was the same: make it run in the customer real conditions.

Forward deployed engineer versus the roles it is often confused with

	Forward deployed engineer	Consultant	Shipped SaaS tool
Deliverable	A working production system	A recommendation or report	A product the customer integrates
Writes production code?	Yes, in the customer systems	No	Pre-built; the customer wires it in
Where they sit	Inside the customer operation	Alongside, then departs	Nowhere; it is software
Owns the outcome after go-live?	Yes	No; the engagement has ended	Support tickets, not ownership
Fails when	The system does not produce the outcome	The advice is wrong on paper	The demo does not match reality

The AI labs have made the distinction formal. OpenAI stood up a dedicated Forward Deployed Engineering function in early 2025, deliberately separate from its advisory Solutions Architect role. One advises; the other owns the build in production. When a frontier lab splits those into two named jobs, it is telling you that the second one is not a soft skill bolted onto the first. It is the harder half.

Why agents make the embedded model non-optional

Here is the spine of the whole thing. A demo proves an agent can work once. Production tests whether it works repeatedly, safely, within a cost and latency budget, on messy real inputs, with tools that break and permission boundaries that must hold and real users who behave in ways no test suite anticipated. That gap is the reason most agentic AI demos fail in production, and it is not a gap you close from the outside with a better API.

You close it by fitting the agent to the customer actual environment: their data, their governance, their workflows, their definition of what a correct answer even is. That fitting is embedding work. It is done best by an engineer sitting inside the operation, watching the agent meet real conditions and correcting where it breaks. The $9B is the market pricing in that reality. A capable model is necessary and nowhere near sufficient, and the last mile is not shipping, it is embedding.

The clearest documented example comes from OpenAI. Working with a call-center voice customer, the model was not performing well enough to put into production. Embedded engineers built evaluations on the customer own real cases, and that work did two things at once: it moved the customer into production as an early adopter, and it improved OpenAI shared Realtime API for everyone who came after. That is the embedded model in one story. The generalizable gains came from getting specific, inside one customer messy reality. I have spent enough time in contact centers and voice deployments to know that this is exactly where the hard problems live, and why voice AI agents are harder than chatbots in the first place: the edge cases do not show up in the demo, they show up in the building.

The honest tension

It would be too neat to end there, so here is the counterargument, because it is a good one. A 2026 Forbes analysis put a number on the discomfort: if more than 30 to 40 percent of your deployments require significant FDE effort, the problem is no longer go-to-market, it is product. The tool is not finished. Heavy embedding can be a sign that a vendor is quietly using expensive humans to paper over a product that does not yet work on its own. Investors have noticed that services revenue carries thinner margins than software, and a model that needs an engineer in every customer does not scale like software is supposed to.

Take the critique seriously, because part of it is right. As agent reliability improves, some of the hand-holding should recede, and it will. But the deeper part of the work does not. Translating a messy customer operating model into a system that produces the right outcome is not a temporary crutch for immature models. It is the part no tool has ever automated, the part I was doing long before anyone wrote FDE on a job description. The volume of embedding may fall as the models get better. The function, understanding the customer reality well enough to make software actually work in it, does not disappear. It just keeps getting rediscovered, and renamed.

What to demand of any agentic deployment

You do not need a billion dollars or an army of embedded engineers to use the lesson. The FDE wave is really a checklist in disguise, and it applies whether you build in-house, hire a vendor team, or buy a platform. If a deployment cannot meet these four, it is a demo wearing a production badge.

The operator scorecard: demand these of any agentic deployment

Demand	The test that proves it
Delivery on real data	Has it run on your actual inputs and workflows, not a synthetic demo set?
Evals on your cases	Is success scored against your definition of correct, on your examples?
A named outcome owner	Who is accountable after go-live, by name, not just through launch?
A self-sufficiency exit	When the vendor engineers leave, can your team operate and extend it?

That scorecard is close to what I look at when I help a team decide whether an agent is actually ready for production, or is still a convincing demo. It maps directly to the framework in Designing Enterprise Agentic AI Systems, which is written for exactly this moment: the point where a capable model has to become a system that survives contact with real operations. The same reframing runs through how the contact-center world is moving from deflection to resolution, where the winners are not the ones with the best model but the ones who did the integration and outcome work.

The label is new. The work is not.

For me, the rise of Forward Deployed Engineering feels less like a new category and more like recognition. The industry has finally put a name, and about $9B, on work that many of us have been doing quietly inside complex enterprise environments for years. Sit between the teams. Understand the operating model. Turn the business problem into a design. Work through the constraints. Stay close after go-live and own the outcome when reality hits.

Agentic AI raised the stakes on that work, it did not invent it. The reason four rivals reached for the same expensive move in the same nine weeks is that they all hit the same wall: the model was never the hard part. Making it work, inside a real business, on real data, under real governance, always was. That is the whole job. It just finally has a title.

If you are trying to work out whether an agentic system is ready for your real environment, or why one that demos beautifully keeps stalling in production, that is the kind of embedded, outcome-owning work I do with teams. Details at how I can help.