Editor’s note
Last week, we looked at why model companies are sending engineers into customer environments. This week comes the awkward question: isn’t that just consulting… or outsourcing with a better acronym?
The resemblance is annoyingly convincing. Hence, in Part 2, Henry draws the boundary between the three and shows why confusing them is an efficient way for both clients and candidates to hit a wall.
Why FDE looks like consulting
When people first read an FDE job description, the same question tends to follow.
“Isn’t this just McKinsey or Accenture for AI?”
For less hype and more engineering, pull up a chair.
The comparison is understandable. FDEs embed with customers, turn loosely defined business problems into workable use cases, align technical teams with senior executives, and stay involved from discovery through deployment.
The McKinsey resemblance comes from problem framing and executive advisory. The Accenture resemblance comes from embedded technical delivery. Add the client-site travel, conference-room whiteboards and stakeholder meetings, and the roles can look similar.
But those similarities describe how the work is delivered, not its centre of gravity. Traditional consulting starts with the client’s processes and asks how they should change. FDE work starts with the model’s capabilities and asks how far they can be made useful inside those processes—then carries what fails back to the model company.
Consultants are hired to redraw process boundaries. FDEs are hired to discover model boundaries.
Put these two side by side in a table, and the differences will become immediately apparent.
The most revealing row in the table is Knowledge durability.
Traditional consulting scales through asset reuse. A solution developed for one bank can be adapted for another, while a retail playbook can be reused across multiple clients. Each engagement adds to a library of frameworks, benchmarks and delivery patterns. Much of that knowledge can remain valuable for years.
FDE knowledge compounds differently. Domain understanding and implementation judgement endure, but model-specific techniques can depreciate remarkably quickly. A prompt chain carefully assembled today may be reduced to a single instruction by the next model release.
That does not mean FDEs rebuild everything from zero. It means they must repeatedly test the model’s boundaries, reconsider the toolchain and reshape the Product Form as capabilities change.
The durable asset is not a fixed playbook. It is the ability to rerun the loop when the model moves underneath you.
What exactly is Product Overhang?
I use Product Overhang to describe the gap between what a model can do and what the existing product allows users to do.
The capability exists, but the access points, permissions, context or workflow integrations needed to make it useful do not.
An FDE’s job is to close that gap. They translate latent model capability into something that works inside the client’s environment. Clients are not simply buying access to an API. They are buying confidence that someone can turn its unused capability into a working part of their business.
The Project structure row follows from the same distinction. A traditional consulting engagement usually begins with a Statement of Work (or SOW), a Work Breakdown Structure (or WBS) and agreed acceptance criteria. That model works when the objectives and expected deliverables can be defined before the contract is signed.
An FDE engagement often begins one step earlier. Clients arrive with something closer to this:
“I know AI should be able to do something for me, but I have no idea what that is.”
The goal itself is part of the project.
FDEs still work within contracts and commercial boundaries, but the scope is often mission-led rather than fully specified upfront. Each iteration clarifies what the model can do, what the business actually needs and what shape the eventual Product Form should take.
The deliverable reflects that difference. A consulting engagement may produce recommendations, a redesigned operating model, an implementation plan or, in some cases, production software. FDE work is ultimately judged by what remains running inside the client’s environment.
It may be small, clunky or short on a polished interface. But people are invoking it, modifying it and complaining about it every day. In other words, it is alive.
The distinction is not that consultants never ship code. It is that an FDE mission has not proved itself until the product survives contact with a real workflow.
The Competitive edge row is subtler.
An FDE’s advantage is not a secret methodology. It is a current, intuitive grasp of the model’s boundaries. Every recent deployment reveals something useful—what breaks under messy inputs, which workflows need guardrails and where human intervention remains unavoidable.
Some of that knowledge can be documented, but documentation cannot fully replace the judgement built through repeated exposure to real failures. Model boundaries move quickly, so the engineers closest to current deployments often see the change first.
When someone asks whether FDE is simply a new version of Accenture, the most useful answer is that the two may share a client-facing delivery model, but they operate different learning loops.
Traditional consulting primarily helps the client reshape its processes. FDE uses those processes to discover what the model can and cannot reliably do… then carries that evidence back to the model company.
FDE is not software outsourcing
If saying “FDE is the new Accenture” is the first layer of misinterpretation, then “FDE is overpriced software outsourcing” constitutes the second layer. This second layer is far more misleading, as the superficial evidence appears overwhelmingly convincing: FDE consultants do go to clients’ premises to write code, do customize functions according to clients’ business needs, and do have their working hours allocated by clients. At first glance, they seem no different from outsourcing engineers.
But a single glance at the feedback loop reveals the difference immediately. Outsourcing is built around requirement fulfilment. FDE is built around co-exploration.
The crucial difference in this diagram is not the straightforward flow across the top. It is the additional feedback chain running back to the model company.
That chain is not decoration. It is the real reason the FDE role exists.
Break the distinction down and four comparisons emerge.
The work they take on is fundamentally different. Outsourcing vendors typically take on SOWs—a clear set of requirements agreed before the contract is signed. The document specifies what to build, which technology to use, how the work will be accepted and what happens if the terms are not met. FDEs, by contrast, often take on missions. The client may not know exactly what it wants. It knows only that “AI should be able to help me with something.” SOWs are built on the premise of certainty. Missions are built on the premise of exploration. These are two fundamentally different postures from which to begin a project.
The scope of work differs. Outsourcing usually delivers a defined component (a module, website or data pipeline) then moves on. FDE is more likely to take end-to-end ownership, from the original business problem and model selection to Product Form design and user adoption after launch.
The billing model is different. When a model company dispatches an FDE, it cares about more than the project fee. Will the client continue using the model? Will it become a retained customer? Will adoption expand into other lines of business? Long-term usage and adoption matter more than the number on an acceptance document.
Feedback flows to different destinations. In conventional outsourcing, client feedback usually remains within the vendor relationship. With FDE, it flows back to the model company’s roadmap. Failed prompts, unreliable tool calls and problems discovered in real workflows can inform future evaluations, tools and product features. In that sense, every FDE customer becomes a natural design partner for the model company.
This is the real value model companies are paying for when they recruit FDEs. They are not simply selling a service. At the client’s site, they are collecting real-world Product Form signals.
Those signals cannot be captured through questionnaires or market surveys. They come back through an engineer who has personally watched the model hit roadblocks inside a specific client workflow—and had to make it work.
What do FDEs earn at OpenAI and Anthropic?
As of September 2026, OpenAI’s San Francisco FDE role lists compensation of $185,000–$300,000 plus equity. Anthropic’s US FDE role lists an annual salary of $280,000–$320,000. The figures are not directly comparable, and neither reveals the complete package. But they make one thing clear. Model companies are not paying these amounts for outsourced working hours. They are paying for someone who can take on the combined risk of the product, the client, and the model.
When I began my career at a central state-owned enterprise in 2006, the company was undergoing its own digital transformation. I remember our group paying Accenture consultants 3,500 yuan per day. They remained on site for years and were described by the media as the “gold-collar workers” of that era. I later moved to SAP, where consultants became an even more visible symbol of the same category.
FDEs may become their equivalent in the AI era. In my view, demand for them (and the salaries attached) will continue to rise over the next 24 to 36 months.
Outsourcing is Labor Arbitrage, and FDE is a frontline perceptron. Confusing the two leads clients to structure FDE engagements around rigid SOWs and candidates to approach the role like outsourced delivery. Both sides will hit a wall very quickly.
That tells us what FDE is not. Part 3 traces the role from Palantir, the software company that pioneered the FDE model, to the new generation of AI companies, then follows it into China. Same role. Very different soil.
That’s it for this one. We’ll pick up the conversation next week.
Until then, keep building.
Tanya D’cruz
Editor-in-Chief