---
title: FDE (Forward Deployed Engineers) turn business pain into product. Where the model breaks
metaTitle: FDE - product company or expensive outsourcing?
description: A breakdown of Forward Deployed Engineering - when an embedded engineer builds a real product, and when it's just costly outsourcing. Majento's view.
date: 2026-08-12
tags: [agentic-ai, enterprise, fde]
cover: cover.webp
coverAlt: Abstract composition of glowing lines on a dark background
draft: false
sources:
  - https://x.com/thejessezhang/status/2087198484093149421
  - https://spoken.md/episode/ep-153-palantir-cto-shyam-sankar-on-heretics-ai-weapons-1000766812326
  - https://blog.joelonsdale.com/p/lessons-from-palantir-in-the-ai-age
  - https://nabeelqu.substack.com/p/reflections-on-palantir
  - https://www.sec.gov/Archives/edgar/data/1321655/000132165526000011/pltr-20251231.htm
  - https://www.sec.gov/Archives/edgar/data/1321655/000132165526000004/a2025q4ex991earningsrelease.htm
  - https://openai.com/index/openai-launches-the-deployment-company/
  - https://www.anthropic.com/news/enterprise-ai-services-company
  - https://www.businessinsider.com/forward-deployed-engineer-jobs-in-demand-2026-5
  - https://joinplank.com/fde-job-market
  - https://job-boards.greenhouse.io/anthropic/jobs/4985877008
  - https://decagon.ai/blog/introducing-duet
  - https://decagon.ai/blog/series-d-announcement
  - https://a16z.com/services-led-growth/
  - https://sequoiacap.com/article/services-the-new-software/
  - https://www.iconiq.com/growth/reports/state-of-ai-2026
  - https://aventis-advisors.com/software-valuation-multiples/
  - https://www.sec.gov/Archives/edgar/data/1467373/000146737325000213/q4fy25earnings8-kexhibit.htm
  - https://kun.uz/en/news/2025/12/27/uzbekistan-aims-to-raise-it-services-exports-to-5bn-by-2030
  - https://www.dentons.com/en/insights/alerts/2021/january/25/uzbekistan-data-localization-requirement-to-be-effective-in-april-2021
  - https://www.trade.gov/country-commercial-guides/kazakhstan-digital-economy
---

## A product, or expensive outsourcing?

*A composite scene - not one specific project, but a situation we have seen several times.*

An engineer has spent three weeks working inside a client's company. He figured out their CRM (customer relationship management software - the system that tracks sales leads and customer data), found out why numbers differ between departments, and is building an AI agent to close that gap. Good work.

The problem is elsewhere. He closed the exact same gap at the previous client. And he will almost certainly close it at the next one.

If the solution gets built from scratch every time, that is expensive outsourcing. If each deployment makes the next one faster - because the pain turned into a reusable piece of the platform - that is a different conversation entirely. The gap between those two outcomes is the central question of the FDE model. FDE stands for Forward Deployed Engineer: an engineer whom a software company sends to work physically inside a client company.

![An engineer at a laptop in a client's office, a process diagram visible on screen](fig-fde-scene.webp)


## A role that used to be an insult

A year ago, sending engineers to client sites read as an admission of weakness: the product was not good enough, so people had to go finish it by hand. Today the same model commands a premium as a strategic advantage.

In a single week in May 2026, both of the largest AI laboratories announced the creation of deployment companies. OpenAI launched The OpenAI Deployment Company with more than $4 billion from a consortium of 19 investors, and immediately acquired Edinburgh-based Tomoro - roughly 150 field engineers. Anthropic announced enterprise services in partnership with Blackstone and Goldman Sachs. Amazon and Microsoft followed with their own forward-deployed units.

According to Indeed data published by Business Insider in May 2026, job postings with the FDE title in April 2026 were up 5,230% compared to January 2025. That number needs a caveat, though: the starting base was tiny. Plank's analysis found roughly 1,000 to 1,500 real roles with that title worldwide - growth from hundreds to thousands, not to millions. Anthropic posted an FDE opening in March 2026 with a base salary of $200,000-$300,000 a year - the pay band of a strong product engineer.

The trend reversed fast, but the underlying economics stayed the same. An engineer still travels to the client, learns their processes, and builds a solution for a specific pain. The question of where that pain goes afterward has not gone away.

![Chart of FDE job posting growth from January 2025 to April 2026](fig-fde-wave.webp)


## How it worked at Palantir

Palantir is the most instructive full-cycle example: from "consulting with a fancy label" to a platform with gross margin above 80% (gross margin measures how much revenue remains after direct costs). Their story appears here not for decoration - it is the structural support for the whole argument.

Joe Lonsdale, a Palantir co-founder, wrote in an essay dated October 31, 2024, that the mainstream had called the company a "glorified consultancy" for nearly twenty years. He also admitted it plainly: "We started this way out of necessity." Palantir had a strong product but no understanding of how intelligence and defense work actually operated - their workflows, the step-by-step routines people follow to get things done. Necessity became an advantage, and the service was turned into a product. Lonsdale's formulation is direct: services always supported product revenue, not the other way around.

Former FDE Nabeel Qureshi described the mechanics of that transition in a 2024 essay. Engineers went to clients and did messy manual work - making sense of data, fixing broken data pipelines, moving analytics out of Excel and into working processes. Product engineers back at headquarters watched that work and converted the repeating pieces into tools. That is how the Foundry platform assembled itself piece by piece: custom deployments produced platform primitives - the basic building blocks from which solutions are assembled - including an ontology (a map of a company's data), object models, access controls, and data-lineage tracking.

Foundry launched as a commercial platform in 2016; the AI Platform AIP followed in 2023 (annual filings with the US securities regulator). By Qureshi's estimate, Foundry accounted for more than half of revenue by 2024.

Gross margin climbed as custom work became platform: from 67.8% in 2020 to 82.4% in 2025, per company filings. Palantir crossed 80% only in 2023 - the journey took more than ten years. Meanwhile commercial revenue caught up with government revenue: the US commercial segment grew 109% in 2025.

Palantir CTO Shyam Sankar, speaking on Joe Lonsdale's podcast in May 2026, recited a formula the company had repeated internally for years: "metabolize pain and excrete product." Retellings often shorten this to "eat pain," but the original is sharper. Metabolism means the pain changes the organism's structure - it does not simply pass through.

![Chart of Palantir gross margin 2020-2025](fig-palantir-margin.webp)


## Why the economics settle everything

The difference between "we implement" and "we build a product" is measurable in money - specifically in margin and in how the market values the company.

The median gross margin for public software companies sits around 80%, based on Aleph's sample of 342 companies from 2025. Markets value those companies at roughly 3.7 to 6 times annual revenue, according to Aventis Advisors.

Services companies look different. Accenture closed its 2025 fiscal year at 31.9% gross margin; EPAM came in around 29%. Valuation multiples run 1 to 2 times revenue. At identical revenue, the services business is worth three to five times less.

The transition is possible. ServiceNow went public with a 63% gross margin and reached 79% by 2024 - that path is documented in a16z's essay from June 2025. A heavy implementation-first start is not a permanent sentence, as long as pain converts to product along the way.

Venture capital noticed. A16z published "Trading Margin for Moat" in June 2025, arguing that optimizing margin at the start is shortsighted and that owning the client's "system of work" matters more. Sequoia released "Services: The New Software" in March 2026, making the case that for every dollar of software sold, six dollars of services are consumed - and that the next giant company will be "software wearing a services mask." Both pieces carry the same condition: services margin must be temporary.

One more pressure point for the whole industry: AI products averaged 45% gross margin in 2025, with a forecast of 53% in 2026, based on ICONIQ's survey of more than 300 companies. Service and compute costs weigh on margin even at companies that consider themselves product businesses.

![Comparison of gross margins: software, AI products, services companies](fig-margin-gap.webp)


## Why this new category cannot skip the field work

There is an argument that usually gets said quietly, even though it is central. When Salesforce sold CRM software in 2005, a well-understood workflow already existed - a sales team operated on a known pattern, and the product automated what people were already doing by hand. An AI agent in 2026 has to invent the workflow from scratch.

A client cannot write a specification for an agent because no one has experience working with agents yet. The client can describe the pain - "we lose three days on every budget approval" - but cannot describe what a solution looks like. The shape does not exist yet. The only way to understand what to build is to go inside and see how the pain is structured.

In our region, there is an additional layer that American FDE discussions rarely mention. Uzbekistan's personal data law (ZRU-547, amendments effective April 2021) requires that citizens' data be stored and processed on servers inside the country. Kazakhstan introduced an equivalent requirement in January 2025. Here, data sovereignty is not a preference - it is a legal obligation.

That changes the calculation. A cloud subscription product running on servers in Amsterdam simply cannot be sold in these markets. The system must operate within the client's closed perimeter, without any external cloud - a setup called on-premise deployment. Deep immersion in the client's infrastructure shifts from an option to a requirement.

Uzbekistan's IT exports reached $1 billion for the first time in 2025, against a target of $5 billion by 2030 - the market is growing, but enterprise deals here are noticeably smaller than American ones. Contracts at the scale that built Palantir's economics are rare. The demands placed on the FDE model are the same, but the timeline is longer: fewer ready-made workflows exist, perimeter requirements are stricter, and deal sizes do not cover expensive product development at the outset.


## Where the model breaks

Jesse Zhang, co-founder of Decagon, published a post on August 11, 2026. His central point lands precisely: the FDE trap is not in how you start, it is in where you stop. FDE lets a company avoid every hard product decision - each custom patch in the field is a product decision you chose not to make. If every deployment takes the same time and headcount as the one before it, that is outsourcing with an FDE label.

Zhang also separates two kinds of work that often get conflated. FDE in the original sense is an engineer who goes to a client to learn something unknown and convert that knowledge into a product primitive. Deploying to a known specification is installation and configuration of an existing product. The second kind of work is valuable, but it is a different job. Conflating the two lets a growing services department get counted as product investment when it is not.

Zhang's final test fits in one line: are your FDEs discovering something new, or absorbing something already known.

One thing deserves to be said clearly here. Zhang is the co-founder of Decagon, a company valued at $4.5 billion as of January 2026, which builds AI agents for customer support. The post appeared alongside the launch of their product Duet - a "partner" that assembles and adjusts agents automatically, without manual FDE work. Decagon's other co-founder came from Palantir, which makes their reading of Palantir's history both authoritative and self-interested at the same time. The speed-of-deployment figures in their public materials are vendor claims, including the formula that "initial build is only 10% of the work," which they cite without independent verification.

Read Zhang's post as a seller's argument. The logic still holds.


## Five questions worth asking your implementation partner

Each question has an honest answer - and if the partner avoids it, that avoidance is already an answer.

**Does the customization live in your environment or in gaps in the product?** If every deployment requires custom code that cannot be reused, there is no product yet. An honest partner can show which parts of the solution came from a ready-made platform and which were written specifically for you.

**Is the last mile unavoidable, or just not built yet?** The last mile is the final adjustment of a solution to fit one specific client. Some things will always be custom: the connection to your accounting system (ERP - enterprise resource planning software), the specifics of your industry. That is normal. But if the "last mile" consumes 80% of every project's time, the first 80% has not become a product yet.

**Are your FDEs discovering something new, or absorbing something already known?** If the engineer comes to you to understand a workflow that nobody has automated before, that is discovery. If they come to configure something they have configured ten times already, that is absorption. Absorption is also necessary - it should just cost less than discovery.

**What went into the product after the last field deployment?** This is a concrete question with a concrete expected answer. The partner should name a feature, a primitive, or a rule that now works for all clients - not just for you. No answer means the pain did not become a product.

**Does each new deployment cost less than the previous one?** Few companies track this metric. But even without a precise number, there should be a noticeable difference: the second project faster than the first, the third faster than the second. If not, the model is running as outsourcing.


## How we do it

Majento builds AI agents and deploys them inside client companies using the FDE model. That is a deliberate choice with a specific reason: the category is new, the workflows do not yet exist, and clients cannot describe something that has no shape yet. The only way to understand what to build is to be inside.

We agree with Zhang's core criterion: each deployment must make the next one cheaper. The difference between an engineering approach and expensive outsourcing is where the processed pain goes. At Majento, it crystallizes into a platform and a catalog of skills. A skill file is a rules-and-tools file that an agent reads before starting a task - think of it as a briefing document the agent consults before each job. When an engineer returns from the field and updates a skill file, the next agent on the next project already knows how to handle a similar situation.

Several pieces of field work have already turned into reusable platform components: an engine for parsing client briefs, a generator for estimates and commercial proposals, branded-materials generation from a brand guide, dashboard creation from raw data, personal executive agents, and a financial planning module. Each one started as a custom solution for a specific client's specific pain.

Now, honestly, about mistakes - both of them are exactly the "field patch" Zhang describes. First: we fixed mechanics with urgent patches directly on a live client system instead of repairing the platform. The same problem surfaced on the next project, and the work had to be done twice. Second: we adjusted agent instructions for a specific project and did not carry those changes back into the shared skill file. Versions drifted apart, and agents began behaving differently across projects. Both mistakes cost more than the correct solution would have cost upfront.

We do not yet track the repeatability metric - how long each successive deployment takes compared to the first. We found no such data in public sources either; almost nobody appears to measure it. We will start with the next projects.

Handing the system over to the client is built into the model. Code, skill files, and documentation stay with the client. The system runs on their own servers in a closed perimeter. In our region that is a legal requirement, and we meet it by default.

If you want to see how [the six steps of AI transformation](/blog/ai-transformation-steps/) look in a real project, that piece includes a practical map of what happens before the first FDE engagement and after the last one.

![Diagram showing the crystallization path from field work to platform primitives](fig-crystallization.webp)


## Pain has to settle into a shared layer

There is one thing that separates crystallization from accumulated clutter. When an engineer returns from the field with new knowledge, that knowledge needs to settle into a shared company layer - not into another custom script - so that all agents use it as a foundation.

That shared layer is called a harness: the knowledge and rules infrastructure on top of which all of a company's agents operate. We wrote a separate piece on what a harness is and why a company needs one: [what an AI harness is and why your company needs it](/blog/company-ai-harness/).

FDE and the harness work as a pair. Without field work, the harness stays empty - there is nothing to put in it. Without a harness, field work does not accumulate - every project starts from zero. The two pieces complement each other.


## Discipline is what decides

For twenty years the mainstream called Palantir a consulting firm with a product label - and it was, until the pain turned into Foundry. Today OpenAI, Anthropic, Amazon, and Microsoft are all betting on the same model. The stakes are higher. The question is the same.

FDE is a way to learn what to build in a category where nobody knows yet. The trap is not starting that way. The trap is staying there - and continuing to call it a product company.


## Q&A

### What is an FDE in plain terms?

A Forward Deployed Engineer is an engineer sent by a software company to work physically inside a client company. They are not consulting remotely or writing code against a specification. They sit alongside the client's team, learn the real processes, and build a solution for a specific problem. The idea is that understanding what to build is only possible from the inside - especially in new product categories where the client has no ready description of the task.

### How is FDE different from outsourcing and consulting?

Outsourcing executes a known task to a known specification - write code, test a system, maintain infrastructure. Consulting analyzes and gives recommendations but carries no responsibility for a working solution. FDE in the original sense does a third thing: the engineer goes to the client to learn something unknown, builds a working solution, and converts that knowledge into a product primitive that then works for other clients. The line blurs when a company labels outsourcing as the FDE model - that is exactly what Zhang warns against.

### Why are FDE-model companies valued lower than product companies?

Because markets value companies through gross margin - how much revenue remains after direct costs. Services companies run around 30% margin: each new dollar of revenue requires roughly the same number of person-hours as the previous one. Product companies run around 80%: the product sells to the next client without proportional cost growth. Markets value services companies at 1 to 2 times annual revenue and product companies at 3.7 to 6 times. At identical revenue, the gap in business value is three to five times. An FDE-model company is valued like a services firm until it can demonstrate that pain is crystallizing into a product.

### How can you tell whether an implementation partner is building a product or creating dependency?

The main signal is the speed and cost of subsequent projects. If each new deployment takes the same time and headcount as the last one, the pain is not crystallizing. Specific questions: what from your project went into the product and now works for other clients? Which parts of the solution came from a ready-made platform, and which were written for you specifically? Does the engineer leave after deployment, or do they remain the only person who understands how the system works? If the system only functions while the engineer is nearby, you bought a dependency.


*Majento builds AI agents and deploys them inside companies using the FDE model. If you want to figure out whether this model applies to your situation, write on Telegram [t.me/shimaoz](https://t.me/shimaoz) or by email [hello@majento.ai](mailto:hello@majento.ai).*