The AI industry says enterprises can’t absorb AI. Its answer is to absorb it for them.

That’s not the same thing.

The engineer across the table knew the model cold. Not vendor-deck cold. He could tell me where it would break, what it would cost, and which benchmark numbers to ignore. One of the better technical minds who has ever sat in that chair.

Forty minutes in, I asked which of our problems he would point to first. He named a minor workflow one of my directors had mentioned that morning.

The easy read is that he didn’t know my business. True, and not very interesting. Here is the real issue: the people who sent him are making the exact mistake they are being paid to fix.

They’re not wrong about the problem

The frontier labs aren’t confused, and I want to be fair before I disagree.

MIT found that about 95% of enterprise AI pilots produced no measurable profit impact, despite tens of billions spent. Winning the benchmark wasn’t winning the deal. And a customer who never gets to production never renews.

So, they did the logical thing. They sent engineers:

• OpenAI: Launched the OpenAI Deployment Company in May with $4 billion of initial investment from 19 partners, starting with 150 forward-deployed engineers (FDEs) and deployment specialists.
• Anthropic: Partnered its engineering capability into an enterprise AI services venture with Blackstone, Hellman & Friedman, and Goldman Sachs, reportedly valued above $1.5 billion.
• Microsoft: Launched Frontier Company in July with $2.5 billion and approximately 6,000 embedded engineers and industry experts.
• AWS: Committed $1 billion to a forward-deployed engineering unit embedding engineers with customers.
• Market surge: FDE job postings grew roughly 800% in nine months, with principal-level compensation past $1.2 million.

That is a serious response. But it answers the wrong question.

All that capital is aimed at getting customers into production and keeping them there. We have been reading it as the playbook for getting AI into the wider economy. Those are two entirely different problems, and only one of them currently has anyone working on it.

The same mistake, twice

One structural fact tells you what this really is: the forward-deployed function sits on the commercial side of these companies, not in research. OpenAI capitalized its deployment arm as a separate business with outside investors.

That’s not an accusation; the org chart is simply more honest than the positioning. What that structure measures is pilots converted to production within the quarter. Against that scoreboard, the model isn’t shallow at all. It’s optimal.

Now look at the same failure from my side of the table.

A team builds an intelligent demand-forecasting agent. Accuracy improves by double digits. The engineering readout is genuinely good. And absolutely nothing happens to cash.

Accuracy was never the point. It only matters if it changes an operational decision: how much safety stock you hold, what commitments you make to suppliers, or what you schedule to build. If none of that changes, you haven’t freed a single dollar. Worse, if the model was tuned for fill rate, because that’s what the commercial team asked for — inventory climbs, working capital gets suffocated, and you are worse off than before. The project wins. The company loses.

Anyone who runs S&OP knows this reality: inventory is cash sitting on a shelf. Every forecast is a claim on that cash. Every service-level promise decides how much liquidity you lock away. The value is never in optimizing a single, isolated number; it is in managing the trade-offs between them.

Outside engineers cannot own those trade-offs. Look at what their engagements are sold on: a deflected ticket, an automated records request, a closed underwriting case. Local, siloed inside one function, and measurable in weeks. Those are the only outcomes an outsider can deliver before rolling off to the next logo.

The results a CFO cares about cross three functions and only show up in cash two quarters later.

Delivery vs. Diffusion

This gets celebrated as AI reaching the real economy. In practice, it does close to the opposite:

• The learning runs one way. Anthropic’s job listings are the most explicit about this, asking engineers to codify repeatable deployment patterns and contribute those insights back to product and engineering. That is honest, and it is the point. Analysts have flagged the same concern from the buyer’s side: that deep reliance on frontier labs hands those labs insight into the very industries they may later enter.
• Capability is replaced instead of built. The engagement leaves behind a functioning workflow, but zero internal muscle to solve the next bottleneck. Constellation Research warned this year that FDEs are often used as a crutch for product immaturity, and as part of a broader vendor dependency play. Without Palantir’s feedback loop — where every deployment continuously enriches an integrated customer ontology — this is simply an expensive systems consultancy with a frontier brand name.
• The mid-market waits. Dice reported in August that the shortage of engineers is now directly holding back enterprise AI returns. The scarcest engineering talent sits inside Fortune 50 anchor accounts, while the companies that make up most of the economy queue behind them.

In engagements structured this way, the lab learns your business. You learn their product.

So here is the test I now apply to any engagement, including the ones I sign: when it ends, are we better at finding the next problem ourselves?

If the capability leaves the building when the outside engineer packs up their laptop, that was delivery, not diffusion. Delivery is a fine business, but it doesn’t compound. Diffusion is nothing but compounding.

What we did instead

We eventually fixed our inventory problem.

Not by pointing an off-the-shelf frontier model at raw ERP tables, but by redesigning our entire planning architecture from the ground up. We staffed the initiative with operators who had spent years inside our supply chain and knew where the real constraints actually sat — the lead time, the allocation rule, the supplier commitment that no outsider would have known to model and then applied AI directly to those decision points.

The result: Inventory came down and stayed down, turns improved, and the part that matters for this argument, nobody had to be flown in to do it again the following quarter.

There is no version of that outcome a single outside engineer could have designed, no matter how brilliant the model in his hands.

The bigger stake

Scale this up and the macro picture becomes clear. A country’s AI advantage will not come from a few hundred flagship deployments. It will come from millions of operators applying AI to operational decisions they were previously making badly.

Which brings me back to the man across the table.

We are spending millions sending AI experts to learn business. We should be sending business operators to learn AI.

• Business knowledge is slow. It took most of my career to instinctively know which trade-offs to make around working capital and inventory.
• AI execution is fast. An experienced operational team can master agentic tooling, evals, and model orchestration in a matter of months.

We are running the harder transfer at immense cost and mistaking it for progress.

I don’t need more forward-deployed engineers. I need backward-deployed domain experts.

Nobody is selling those. Which means the only people who can build them are already on your payroll.

There’s something very attractive about saying “we embed very closely with our customers and just figure it out with them”, especially since the company that started “forward deploying engineers” is growing 84% with $5B+ revenue. But “forward deployed engineer” is a vague term and means different things depending on the business you’re running.

I spent almost 5 years at Palantir as a forward-deployed software engineer, and Palantir’s version of an “FDE” does not make sense for most companies I now meet as an early-stage VC. Depending on the type of business you’re building, this role could broadly mean one of two things: “the product builder” or “the platform operator.” Clearly defining which bucket you fall into will make it easier to hire for this role and run your FDE org.

Kabir Sial

The product builder: The OG Palantir version

The north star is: do whatever it takes to actually solve the user’s problem. FDEs are not just responsible for making the platform work, but also discovering what to build and building it (actually creating software) in service of the customer.

The platform operator: Solutions + technical customer success

The north star is: make the product work for the customer – deploy and operationalize it. This is what most startups today really mean when they want FDEs. FDEs here configure the core platform, manage account relationships and drive adoption. This is not new – companies have always had solutions engineers, sales engineers, customer success etc., although the work looks different as FDEs are increasingly building prototypes, configuring evals and building MCPs.

Which FDE is right for you

Kabir Sial

For most situations, hiring product builder FDEs is a mistake.

At scale, the FDEs should be the platform operator. It’s hard to have FDEs build and maintain highly custom product features, especially as the company scales. Over time, the custom product surface area distracts from building the core product, even though AI coding tools make it easy to ship new features quickly and maintain them.

Many fast-growing AI startups recognize these constraints and structure the FDE role more like the platform operator. This also allows them to have 5-10 accounts per FDE, which is a much higher ratio than Palantir had (at least in 2023). Even the Palantir FDE role has evolved to look more like the platform operator.

There are, however, situations when your FDEs should be the product builder archetype.

1. You have very large customers (F500 scale)

Technical complexity: Large customers have complex environments with legacy infrastructure that often requires “out-of-platform” engineering work. I often encountered bespoke data infrastructure, privacy requirements, etc. at various Palantir customers that required me to build “out-of-platform” connectors, UIs and backends.

Organizational inertia and trust: Serving large enterprises is about building trust. In short time periods, overfitting product to a specific user/workflow is often what delivers the most value, builds trust and helps organizations get over the inertia of moving away from Excel and legacy software tools that are part of their day-to-day workflow. For AI-native startups, it’s arguably even more important to invest in doing “unscalable” development with engineering boots on the ground, as it helps solidify your right to exist and eventually expand the customer relationship.

2. You have many ICPs and workflows

If you have a broad range of ICPs and workflows that you serve, your product probably is not walk-up usable on day 1 of deployment. The short-term hacky things that product builder FDEs build to make the product work for these heterogeneous users/workflows will help you shape the product long-term.

Kabir Sial

Note: see Palantir Foundry’s architecture here.

This was a big reason why Palantir FDEs were more like product builders (and are still able to – see the Forward Deployed Software Engineer job profiles as an example). The vision for Foundry was to be the operating system for an enterprise’s critical decisions – inherently multiple industries, users and workflows. A lot of FDE-led development showed that solving many of these use cases required complex data integrations, which led to the early versions of Foundry being best-suited for complex data integrations and building a customer’s “Ontology”. Similarly, FDEs like myself built custom frontend applications for fraud analysis, pricing, etc. As certain patterns of what these applications required became more clear, they were centralized into an application-layer product.

Who you should hire

Kabir Sial

Kabir Sial

Platform operator: There is a much broader set of people you could hire, testing for technical fluency (e.g., being good at data analysis, complex Excel work, even SQL), product intuition and an inclination to build customer relationships. Backgrounds like technical customer success, solutions engineering, software engineering, product management and consulting are all strong fits.

Product builder: You want candidates that are high ownership and missionary software engineers, or technical PMs who want to ship products themselves.

Hiring for these profiles, especially product builders, is hard. It’s worth calling out two things that helped Palantir hire software engineers into what might be considered a less sexy role.

1. Culture of building at the edge: Strong engineers are motivated to build things. Palantir gave FDEs a lot of ownership to build products, which is why much of the core product leadership was former FDEs.
2. Cult built around mission: Internally, there was a cult-like devotion to the mission. Everyone always talked about why outcomes were far more important than software, and why most companies building tools had it wrong. I’ve never been at a company where people feel so closely bonded around a mission.

As founders building AI startups think about hiring FDEs, it’s worth being specific about your culture and asking: Am I just hiring people to support development teams, or am I hiring people to shape and build product? It’s hard to get software engineers (even today) to be excited about an FDE role that might just be technical customer success.

What FDEs should be doing (regardless of archetype)

You’ve hired the right people. How do you best leverage your team of FDEs?

FDEs were Palantir’s way of delivering outcomes rather than tools. AI-native startups can take this much further and FDEs can help in a few unique ways by leveraging their proximity to customers.

1. Find the most critical workflows: As AI lowers the cost of producing software, companies will face a lot more competition. FDEs at AI startups should be constantly finding ways to serve the most critical workflows for a customer and paying attention to how customers do work across newer and legacy tools. For example, FDEs at Harvey should pay attention to which workflows are in Westlaw, which ones are moving to ChatGPT/Claude, and how the Harvey product can stay ahead.
2. Build around nondeterminism: In more regulated environments, FDEs should be hyper-focused on making products reliable for specific use cases using evals and configs. Previously, product reliability lived with product and support. As companies provide outcomes instead of tools, configuring products appropriately and managing evals shifts towards FDE teams.