The FDE is not your Employee

The FDE is not your Employee

"This technology makes you as smart as the smartest person in the organization" -- Morgan Stanley's Jeff McMillan

I think the above quote encapsulates the enterprise AI dream perfectly: scale the best person in the company, become consistently excellent.

But why stop at one super-human if you can have 700? In early 2024, Klarna and OpenAI announced results from an AI assistant that had been live for one month: it did the equivalent work of 700 full-time agents. Being AI first is risky, but it does fit Klarna's profile as a digital-first, multilingual, cost-sensitive company.

So it was decided, from now on, they would be an AI first company! (Sidenote: if I had a euro for every time I hear this sentence I would be rich!)

Like many companies at the time, Klarna was eager to try out all sorts of AI pilots in late 2023. Senior management contemplated several choices, including:

• What's the scope? Should they build their own models?
• Should they start with low-hanging fruit, like customer support? Should they automate whole conversations or only parts of them?
• What's the risk to the brand?
• What do we do with current staff?
• ...

The specifics, though, were still unsettled. So they did what most of us would have done in their position: vibe-innovate talk to the geeks at OpenAI.

The engineer deciding your operating model

The modern equivalent of the geek squad is a team of Forward Deployed Engineers.

FDEs are technical people at the intersection of AI and business who know their company's product deeply. They come in and turn a wish like "we want AI in customer support" into system behavior: which requests the agent handles, what data it can see, when it stops, how success is measured, and which failures get fixed first. Things that require experience to learn. Important for later, while they may sit with your teams, but they do work for the vendor.

Bob McGrew, who spent years at Palantir before joining OpenAI, argued on the Lightcone podcast that FDEs are especially important in AI because there is no established product template yet — organizations need them to act as product discovery.

As an engineer turned business school professor myself, it has always been a strange idea to me that you would rely on an external partner for internal product discovery. Then again consulting companies have been operating on a similar model for decades.

I was naive though, the FDE (and tech consulting) is about much more than even product discovery. When FDEs come into a company like Klarna, the work is not "the chatbot", but often starts with a structured deployment sprint that can include things like:

Workflow mapping and use-case prioritization are indeed product discovery, but the remainder of the rows I would categorize under operating model design. The FDE doesn't exist because we don't know what products to invent, but because it's hard to envision the operating system around the product without first running real operations inside one. That's all well, except that the decisions made relating to operating model design you will likely have to live with long after the FDE leaves.

On the same Lightcone podcast, McGrew described the FDE loop like this:

"The FD goes and builds like a gravel road to where the product needs to go. And then the role of the product and engineering team was to look at that and figure out how it should generalize... and turn that gravel road into a paved superhighway."

McGrew later served as OpenAI's Chief Research Officer. OpenAI has since launched a dedicated deployment company targeting that same enterprise work. Consider this for a moment: in getting FDEs to come to their company, was Klarna buying an AI model, automating customer support, redesigning service operations, or outsourcing product discovery?

Haven't we seen this before?

If you are asking this, you are probably thinking of tech consulting companies like Accenture or other firms that use titles like Sales Engineer, Field Engineer, Solutions Architect, etc.

The economic logic is different here though. For the Accentures of the world, the services are the monetization. The point is to help clients while billing expensive hours. Last I checked, a 6-8 week project can easily cost hundreds of thousands of euros, sometimes more.

With AI companies, the product is the monetization strategy . Palantir is a good example. Palantir's model depends on customers expanding their use of Foundry over time — willing to take losses on early consulting work, recouping them through product revenue at scale.

Palantir explicitly disclosed a three-phase model in its contribution margins by phase in its 2019 figures from S-1/investor presentations:

In H1 2020, Palantir's Scale-phase customers were generating contribution margins of +68% — non-GAAP, but consistent with the unit economics described in the S-1. Since then, Palantir has used every deployment to improve the product, building paved highway at scale. The model has been successful and has spread from Palantir into frontier AI vendors and now into the Big 4. Deloitte launched Forward Deployed Engineering pods in late 2025. EY UK followed in April 2026.

According to a Bloomberry analysis of Revealera job-posting data, FDE job postings grew 1,165% year-over-year between January and October 2025 — so it seems like this is how enterprise AI gets sold now.

This can be perfectly fine. The client moves faster, the vendor improves the product, and the next deployment gets cheaper. The incentives are not necessarily evil, they are just not identical. Therefore, one must be very careful with drawing the line between getting expert eyes and relinquishing control over the operating model.

Horizontal = vendor dependency: from a relationship you could exit tomorrow, to one where the vendor is structurally embedded. Vertical = internal capability: from understanding the system well enough to own it yourself, to not being able to explain what it does. Most FDE engagements start somewhere in the bottom half and move upward as the work progresses. The risk is moving right faster than you move up.

In 2019, Hertz sued Accenture for $32M over a failed website redesign — the complaint names Accenture as product owner, and Hertz alleged it had relied on Accenture's expertise because it lacked the internal resources to run the transformation itself. The case settled with no court liability finding. Which quadrant do you think they were in?

About Klarna

Klarna's bot handled two-thirds of customer-service chats in its first month, across 23 markets and 35 languages. Repeat inquiries dropped 25%. Resolution time went from 11 minutes to under 2 minutes. Klarna estimated a $40M profit improvement. It was a textbook success.

What's less discussed: according to interview coverage with OpenAI's Colin Jarvis, learnings from Klarna and later T-Mobile helped validate patterns that were eventually productized through Swarm and the Agents SDK. That's what the scale phase means: your implementation doesn't stay in your implementation.

A year later, Klarna was again hiring humans into customer service. Siemiatkowski later acknowledged that quality dropped and the AI-induced hiring freeze went too far. My read: Klarna off-loaded too much too fast. Speed and cost worked. Service quality didn't hold. And how could an FDE team have caught that? Klarna is, after all, the expert on those matters.

In my view, a service-oriented company risks deteriorating service when it off-loads too much of it to AI. Simplifying things, there are essentially two outputs here:

1. A working system.
2. A new operating model.

The first one can come from the vendor. The second one has to be owned locally.

FDEs aren't necessarily at fault here. Their job is to make the vendor's technology work in the enterprise. Your job is to make sure the enterprise still works after the technology arrives. JPMorgan's internal AI tooling is a useful counterexample, and they use FDEs too (I'll cover them in the next post). Just be aware that they have very different incentives and goals. FDEs are useful because the gap between demo and enterprise deployment is currently still large, and many companies need them.

The risk is that the company treats the engagement as implementation while the vendor treats it as discovery. Own the operating model. When you feel you're losing control, as you very likely will, take a step back and reflect on the partnership.

Two questions to ask now

• What are we asking the FDE to build? If the answer is "a chatbot", you're probably underthinking it. The real answer should include the workflow, the evals, the escalation rules, the failure review process, and the internal owner.
• What do we want to know after they leave? A good FDE engagement should leave behind a working system as well as the know-how of how the work actually works.