AI engineer vs forward deployed engineer: value framework

AI engineer vs forward deployed engineer: value framework

The argument over AI engineer vs forward deployed engineer has sharpened for a reason: enterprise AI is no longer a novelty problem, it is a delivery problem. The models are improving faster than most organizations can absorb them, and when the work hits production, somebody has to own the mess.

That is why Tomasz Tunguz reported this week that AI companies have committed roughly $9.75 billion to forward-deployed engineering in the past 12 months. He also relayed MIT’s “GenAI Divide” finding that 95% of enterprise GenAI pilots produced no measurable P&L impact, while companies spent $684 billion on AI in 2025. Those are big numbers, but they matter here as evidence, not as the thesis. The real question is simpler: when does an AI engineer create more business value, and when does a forward deployed engineer do the heavier lifting?

This is a decision framework for leaders choosing between the two roles, and for engineers deciding which path fits the kind of work they actually want to do. The short version: the titles sound adjacent, but the economics are not.

What AI engineer vs forward deployed engineer really means

The cleanest way to compare the roles is by what each one is trying to make possible.

An AI engineer builds reusable capability. That means training or fine-tuning models, building data pipelines, developing inference infrastructure, and creating internal tooling. Palantir’s own description of the traditional software engineer is useful here: that role “focuses on creating a single capability that can be used for many customers” (Palantir Blog, 2020). In practice, the business value comes from platform reuse, lower inference costs, better reliability, and less duplicated effort across teams.

A forward deployed engineer turns that logic inside out. An FDE embeds directly with the customer, working against real data and in real workflows to solve problems the customer often cannot fully specify upfront (Perspective AI, June 2026). At Palantir, FDSEs own the full arc of the work, from scoping to implementation to go-live support and handoff to the client team (Palantir Blog, 2020). The business value shows up faster, and more narrowly, in adoption, deployment success, and the field signal that comes back into the product.

The real dividing line is accountability. Netguru puts it plainly: AI staff augmentation drops vendor engineers into your team under your direction, while FDE transfers end-to-end delivery accountability to the embedded engineer or team. That difference matters more than seniority, rate, or the logo on the slide deck. If you choose the wrong model, Netguru says from experience across 40-plus engagements, delivery can slip by three to six months before most teams realize what happened.

The split is not mystical. Choose an AI engineer when you already know what to build and have enough internal leadership to direct the work. Choose an FDE when you do not, or when the main problem is not invention but getting AI to survive contact with a real organization.

Where the AI engineer compounds business value

The AI engineer gets short shrift in a lot of this debate, usually because the FDE story is easier to tell. That is a mistake. A good AI engineer can compound value in ways that are slower to see but much harder to replace.

The best AI engineers build shared infrastructure. They create model services, data pipelines, and observability systems that many teams can use, which means the same line of code does not need to be rewritten every time a new feature ships. Palantir’s 2020 description of the traditional engineer’s work, building a capability that serves many customers, is basically the case in miniature (Palantir Blog, 2020). That kind of work matters because it turns one-off technical effort into repeatable use.

The business payoff is usually less dramatic than a flashy deployment story, but it is often more durable. Reliability improves. Inference costs fall. Internal teams stop rebuilding the same plumbing. A mature AI engineer function can quietly become the reason the rest of the company moves faster. Not glamorous. Effective, though.

That is the central point the FDE debate sometimes obscures. An organization does not need only embedded engineers chasing immediate adoption, it also needs people who can turn repeated deployment lessons into a platform that scales. Without that, every customer becomes a fresh engineering project. Nobody has time for that for long.

Where each role breaks down

Neither role creates value automatically. Each fails in a different way.

The AI engineer’s failure mode is building in a vacuum. If the team never gets close enough to the customer environment, it can spend months optimizing technically elegant systems that do not solve the real bottleneck. Model metrics improve. Adoption stalls. Everyone nods at the dashboard and then goes back to using spreadsheets.

The FDE’s failure mode is almost the mirror image. Embedded engineers do not create durable value just by showing up in the customer environment. They create value when what they learn gets fed back into the core product. And that is where the hard part begins.

And Vijay Says argues that what Palantir built was not really an implementation shop. It was a product organization that sends engineers into the field, then uses what those engineers learn to improve the platform for everyone else. That is the point of the model. A customer-specific fix should become something the next customer gets for free. If it does not, you are just doing bespoke work with a polished name badge.

Perspective AI’s playbook makes the same distinction in more operational terms. A working FDE function should leave behind reusable abstractions, and it should run through a productization phase that ships at least one feature back into the core product per engagement within 90 days. The playbook also treats roughly 10 weeks to production and handoff within 120 days as target metrics, not industry gospel. That is a useful distinction. Targets are discipline. Standards are something else.

The incentive problem is where many FDE programs go wrong. Traditional consulting rewards utilization, which means people get paid for staying busy. A real FDE function has to reward productization instead, even when that reduces billable hours. And Vijay Says makes the point bluntly: without that shift, the role becomes “just another implementation consultant with a more modern title” (And Vijay Says, July 2026).

Netguru’s NewGlobe example shows what the better version looks like in practice. Working in an FDE-style embedded model, the team built an end-to-end AI pipeline that cut teacher guide creation time from four hours to 45 seconds (Netguru, June 2026). That is not just speed for its own sake. It is a sign that end-to-end accountability can turn an embedded team into a delivery engine rather than an extra layer of process.

What the evidence supports, and what it does not

The spending data points in the same direction. Tunguz reports that five major technology companies committed about $9.75 billion to forward deployed engineering programs within a year: OpenAI at $4 billion, Microsoft at $2.5 billion, Anthropic at $1.5 billion, Amazon at $1 billion, and Google Cloud at $750 million. He also notes Salesforce has committed 1,000 FDE roles. That is a serious bet, even if the structures differ.

Tunguz’s broader argument is that the FDE model, which embeds engineers inside customers to deploy AI, has moved from a Palantir signature to something close to an industry default. The logic is easy to see. FDEs sit where the friction lives. They see proprietary workflows, data schemas, and failure modes that no API call surfaces, and that field intelligence can feed back into product decisions and make switching costs harder for a customer to bear (Tunguz, July 2026).

There are limits to what this evidence can prove. Most of the spending figures come through Tunguz’s compilation, not a tidy round of first-party disclosure. The 95% pilot failure rate is also relayed through his account of MIT’s “GenAI Divide” report, not quoted directly from MIT. And there is still no rigorous head-to-head study showing revenue per FDE versus revenue per AI engineer, or retention gains attributable to either role. The current conversation leans heavily toward the FDE side because the companies hiring them, and the vendors selling the model, have more to say than the quieter teams building internal AI infrastructure.

Even the cost picture is suggestive rather than definitive. Tunguz says Palantir has 400 to 500 FDEs at a median of roughly $215,000, while senior FDEs at labs are reportedly paid $350,000 to $550,000. That gap matters, but it does not resolve the strategic question. Higher pay can reflect scarcity, use, or panic. Sometimes all three.

The cleanest reading is this: embedded engineers tend to outperform talent-augmentation models on time-to-impact when the adoption bottleneck is real. That is not the same thing as saying FDEs beat AI engineers everywhere, or that a company should staff itself as if every problem is a deployment problem. It is a narrower conclusion, which is usually the honest one.

A decision framework for buyers

If the question is AI engineer or forward deployed engineer, the deciding variable is where the bottleneck sits.

Choose an AI engineer, or AI staff augmentation, when the company already has functional internal AI leadership, a clear technical gap, and the ability to direct the work without outsourcing judgment. In that setting, the value comes from scalable capability: reusable components, lower costs over time, and tighter internal control.

Choose an FDE model when those conditions do not hold. No internal AI lead. A greenfield product. A deployment problem the company cannot absorb on its own. That is where an embedded engineer with end-to-end accountability can do more than a team of hired hands waiting for tickets.

If the goal is productization, the best structure is not one role replacing the other. It is the two roles in sequence. FDEs surface the messy problems. Core AI engineers turn the recurring patterns into platform capabilities. That is the architecture that lets field work compound instead of evaporate.

What engineers should take from this

For engineers, the tradeoff is clearer than the title suggests.

The FDE path offers broader scope and a faster line from code to business outcome. Palantir engineers describe the role as one where success is measured by operational impact, not just technical neatness (Palantir Blog, 2021). That can be energizing. It can also be exhausting. You need to be comfortable writing production systems, talking to customers, and making decisions with incomplete information. Some engineers love that. Others would rather stay home with the compiler.

The AI engineer path is narrower in the moment, but it can be more accumulative. The best engineers in that lane build the shared machinery that makes later deployment work easier and cheaper. The payoff is less visible day to day, but it can reach farther across the organization. Different temperament, different reward.

Conclusion: measure the structure, not the job title

The point of this debate is not to crown a winner. It is to match the role to the bottleneck.

An AI engineer creates compounding value when the organization already knows what needs to be built and can make use of reusable technical infrastructure. A forward deployed engineer creates compounding value when the harder problem is adoption, not invention, and when the company is built to convert field learning into product. If that feedback loop does not exist, the FDE role starts to look suspiciously like consulting with a better haircut.

That is the real test for companies making serious bets on embedded deployment. Not how many FDEs they hire, but whether the work they do gets turned into product, faster than the next customer can ask for the same thing twice.