Forward deployed engineers: why AI gets built next to the business, not for it

A forward deployed engineer (FDE) is a software engineer who works on site or embedded with a customer, close to the people who do the work, and turns a general product or model into something that runs in that specific business. The role is not sales and not support. An FDE writes code inside the customer's systems, against the customer's data, until the solution works in production: live, in daily use, not in a demo.

For artificial intelligence (AI), this matters now. Models are general enough to do useful work almost anywhere, and that is exactly the problem. A general model does not know your pricing exceptions, your approval chain or which spreadsheet really runs the warehouse. Someone has to close that gap, and the companies that build the models have concluded it takes engineers in the room.

Where the role came from: Palantir's Deltas and Echos

The model is usually traced to Palantir, the data software company. In a 2019 post on its blog, Palantir contrasted two engineering roles: software engineers who build the core platform, "one capability, many customers," and forward deployed engineers, known internally as Deltas, who deploy it to customers, "one customer, many capabilities." Palantir wrote that Deltas do "significantly more engineering and technical work than a consultant" and often contribute code back to the product.

Deltas worked alongside deployment strategists, called Echos, whom Palantir describes as closer to product managers, while noting that in practice the lines between the two roles "blur heavily." Nabeel Qureshi, a former Palantir employee, wrote that engineers on customer teams were typically expected to go onsite and work from the customer's offices three to four days a week. According to The Pragmatic Engineer, until around 2016 Palantir had more FDEs than conventional software engineers.

Why AI companies adopted forward deployed engineering

By 2025 the model had reached the AI labs. OpenAI's careers page says its forward deployed engineering team "partners with customers to turn research breakthroughs into production systems," and asks FDEs to "embed closely with customer teams." Anthropic's listing for the role describes engineers who embed with strategic customers and "work within customer systems to build production applications" with its Claude models. The Pragmatic Engineer reported that OpenAI's team started at the beginning of 2025 with two FDEs. Fast Company, citing the Financial Times, reported that job postings for the role rose more than 800 percent from the start of 2025 through September.

In 2026 both labs went further. In May, Anthropic announced a new AI services company with Blackstone, Hellman & Friedman and Goldman Sachs to work with mid-sized companies, from community banks to regional health systems, that "lack the in-house resources to build and run frontier deployments." A week later, OpenAI launched the OpenAI Deployment Company with more than $4 billion in initial investment and acquired Tomoro, an applied AI consulting firm, bringing in about 150 forward deployed engineers and deployment specialists.

The reasoning is in the announcements. Anthropic wrote that putting Claude to work in core operations "takes hands-on engineering and deep familiarity with how each business runs." The venture capital firm Andreessen Horowitz described forward deployed teams as the people who "operationalize the model into a real-world solution."

Most of the value of AI is lost in the last mile

The gap was visible before the labs moved. In August 2025, Fortune reported on a study from a research initiative at the Massachusetts Institute of Technology that found about 5 percent of AI pilot programs achieve rapid revenue acceleration, while the vast majority stall with little or no measurable impact on profit and loss. According to Fortune, the problem was not the quality of the models: generic tools stall inside companies because "they don't learn from or adapt to workflows."

That is the last mile. The model works; the business around it is messy. Data lives in several systems that do not agree. The process that matters is undocumented and lives in one person's head. The exceptions, often the costly part, never made it into the requirements. The integrations need access nobody has approved. And the people who are supposed to use the tool were never asked what they need.

None of that appears in a slide deck or a vendor demo. It appears when a builder sits next to the person who processes the claims and sees a step the manual never mentions. A generic tool cannot see it. A builder next to the work can see it, fix it and ship the fix the same week.

How a mid-market company can apply the model

You do not need to hire an FDE team to work this way. You need the habits that make the model work.

1. 01EmbedThe builder works where the work happens
2. 02Start realOne workflow, with the people who run it
3. 03BaselineVolume, time, errors and cost today
4. 04Ship smallInto daily use, with a person reviewing

IterateAgainst the baseline; widen only when results hold

Embed the builder with the operation for a period. Whoever designs the solution should spend real time where the work happens: in the queue, on the calls, in the spreadsheets, not only in meetings with managers.

Start from one real workflow, with the people who run it. Pick a process with a clear owner and a cost you can name: intake, quoting, billing, scheduling. The people who do it every day define what "done" means.

Measure a baseline before you build. Record volume, handling time, error rate and cost per case as the process runs today. Without that, no one can tell whether the new system helped.

Ship something small into production fast. A narrow version in daily use teaches more than a broad pilot on a test server. Keep a person reviewing the outputs at first.

Iterate against the baseline. Compare the numbers, fix what the exceptions reveal, and widen the scope only when the results hold.

The risks of the model, and how to manage them

Embedding has costs, and they are predictable.

Dependence on one person. When the builder who knows everything leaves, the knowledge leaves too. Require that the design, the prompts (the instructions the model receives), the integrations and the known failure cases are written down as the work happens, not at the end.

Knowledge that never transfers. A system nobody inside the company understands is a system nobody inside the company will fix. Plan the handover from the first week: who will run it, who will change it, and what training they need.

Scope creep. An embedded builder keeps finding more things worth automating. That is useful, and risky. Keep a written scope, a list for later, and a business owner who decides what comes next.

The remedy for all three is the same: ownership stays inside your company. The builder is there to make the system work and to leave it in hands that can keep it working.

Questions to ask any AI partner

Use these to tell whether a partner works like forward deployed engineers or like a vendor:

• Will the people who design the solution also build it?
• Will they spend time with the people who do the work, not only with management?
• Which single workflow would they start with, and why?
• What baseline will they measure before building, and how?
• How soon will something run in production, in daily use?
• Will they work inside our existing systems, or ask us to move to theirs?
• How will they handle exceptions and human review?
• What documentation and handover do we get, and who owns the system afterward?
• What happens if the person who built it is no longer available?

What this means for your business

The AI labs are sending engineers into their customers' operations because models alone did not produce results inside businesses. Their conclusion applies to any company: the value of AI is decided in the last mile, by people who understand both the technology and the work.

For a mid-market company, the lesson is not to buy a bigger tool. It is to insist that whoever builds your AI does it next to your operation, starts from a real workflow, measures against a baseline, and hands over something your company owns. That is how we work: the people who design the solution build it, inside your operation, to grow revenue, reduce costs or reduce risk.

If you want builders who sit next to your operation, book a meeting with us.