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.

When the embedded model fits, and when it does not

Those four demands are the buyer’s floor. The question underneath them is different: is embedding the right shape of engagement for this piece of work at all? Often it is not, and finding that out late is expensive.

Embedding earns its keep when the hard part of the problem lives inside your operation rather than inside the software. A few honest signs. The rules that decide a correct answer are not written down anywhere, and the people who know them disagree with each other. The data the agent needs sits across systems that were never designed to talk, and half the job is getting a clean read. Nobody can hand you an evaluation set, because nobody has agreed what a right answer looks like. Or the thing the agent touches has consequences: money moves, an account closes, a regulator can ask why.

Those problems share a property. You cannot specify them accurately enough in advance to hand off. Somebody has to sit inside the operation, watch what actually happens, and change the design as they learn.

It is the wrong model in at least as many cases. If the use case is well bounded and somebody has already solved it as a product, buy the product. If your requirements really are stable and can be written down, an ordinary statement of work will be cheaper and less disruptive. If you have a capable platform team who mainly need a design review and a second opinion, embedding is an expensive way to get one. And if what you want is more engineers on your own roadmap, that is staff augmentation, which is a reasonable thing to buy and a different thing.

Where it differs from outsourcing the implementation

The two look similar from a distance. They separate on one question: who is accountable when the system is live and wrong.

An implementation partner delivers against a specification you wrote. Scope changes are change requests. The engagement succeeds when the deliverable matches the spec, which means it can succeed while the outcome fails, and both parties can be entirely correct about that at the same time.

An embedded engagement starts from the outcome and treats the specification as something you discover together. It is judged on whether the agent resolves the thing it was built to resolve, after go-live, on your data. That is a harder commitment for a vendor to make, and a worse deal for them when the problem turns out to be easy, which is part of why it is worth asking for.

What you should own when it ends

Ask this in the first conversation, before scope and before cost. What do we have when you leave?

A good answer is specific. Production code in your repositories, under your licence, that your own engineers have read. An evaluation set built from your real cases, which is the artifact that lets you change the system later without guessing. Runbooks and an on-call path with a named owner on your side. The design decisions written down, including the ones that were rejected and why, because those are what stop your team relitigating them next year.

A weak answer is a dependency wearing a maintenance contract. If a vendor cannot describe the handover in the first meeting, you have your answer.

On cost, the useful framing is a comparison rather than a number. Embedding costs more per week than a licence and less than a pilot that runs for a year and never ships. Whether it is worth it turns on what the delay is costing you, and that is a figure you have and the vendor does not.

The part buyers leave out of the evaluation

Something happens in an embedded engagement that cannot happen in a specified one. The engineer who hits the wall is the same person who can move it.

The OpenAI voice case earlier in this piece is the clearest published example. The model was not good enough for that customer to ship. Embedded engineers built evaluations on the customer’s real calls, and that work both moved the customer into production and improved the Realtime API that everyone else uses. One customer’s edge cases became the product’s test cases.

That loop only closes when the person writing the code is close enough to the operation to see the failure and close enough to the product to do something about it. It is the strongest argument for the model, and the one most often missing from a buyer’s comparison.

If you are weighing this for a specific piece of work, forward deployed engineering is how I run it.

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.