# zhang-decagon-fde-produit-2026-08-11

## Veille

Long-form article published on **X** on **August 11, 2026** by **Jesse Zhang**, CEO of **Decagon** (customer-service AI agents), under a dilemma-shaped title — *« To FDE, or not to FDE? »* — devoted to the **Forward Deployed Engineer**, which has become *« the answer to almost every hard question in AI go-to-market »*. Starting observation: Anthropic and OpenAI have built enterprise deployment arms explicitly modeled on Palantir, *« every seed-stage company »* advertises an FDE offering, and job postings for the title are said to be up several hundred percent in a year. **(A) The Palantir genealogy** supplies the framework: **Shyam Sankar**'s (CTO) formula, *« FDEs eat pain and excrete product »*, and **Joe Lonsdale**'s reminder that Palantir spent nearly two decades being called a *« glorified consultancy »* on the basis of an accurate observation. **Gotham**'s bespoke deployments (CIA, NSA, military intelligence) were encoded into platform primitives — ontology, object models, permissions, workflow engines, provenance tracing — which became **Foundry**, then Apollo and AIP; standardization pushed gross margin into the 80% range and Palantir moved from an FDE motion to account-based selling, with many FDEs migrating into core engineering. *« The pain was the input to the product, not a cost of sale. »* **(B) The criterion proposed** is not to give up on FDEs but to know when to stop: go early, then ask whether one is still **discovering** — *« The trap is not starting. It's not stopping. »* **(C) A distinction few make: FDE ≠ implementation.** *« Building that integration into their ticketing system »* is real work, but it is execution against a known spec, not discovery of an unknown one; conflating the two *« is how a company convinces itself that a growing services org is a product investment »*. Closing line: *« If your FDEs are eating pain and excreting more pain, you don't have an FDE team. You have a services business. »* Two figures are put forward about Decagon — *« two-thirds of deployment work is now done autonomously via Duet »* and *« a few days on average to launch the first AOP, even for large banks, airlines, telcos »* — without the "deployment work" denominator being defined or the AOP acronym spelled out.

## Titre Article

To FDE, or not to FDE?

## Date

2026-08-11

## URL

https://x.com/thejessezhang/status/2087198484093149421

## Keywords

Forward Deployed Engineer, FDE, engineer embedded with the client, AI go-to-market, deployment motion, last mile, last mile, discovery vs. execution, discovery problem, delivery problem, unknown spec, implementation, integration, services org, services business, glorified consultancy, glorified consultancy, product-led approach, services-led approach, product-led, services-led, Palantir, Gotham, Foundry, Apollo, AIP, platform primitives, ontology, object model, permissions, workflow engine, provenance tracing, gross margin, cost to serve, cost to serve, margin ceiling, hiring-bound growth, eight-figure deals, Decagon, Duet, AOP, customer service, customer support, AI agent, autonomous deployment, configuration, tuning, iteration, iteration speed, vendor lock-in, vendor lock-in, sovereignty, escalation turned into requirement, patch vs. requirement, product debt, product trade-off, configuration surface, Jesse Zhang, Ashwin Sreenivas, Shyam Sankar, Joe Lonsdale, Anthropic, OpenAI, Accenture, new category, nonexistent workflow, SaaS 2015, accounting, banks, airlines, telcos

## Authors

**Jesse Zhang** — cofondateur et **CEO de Decagon** (agents IA de service client, San Francisco), 85 000 abonnés sur X, site personnel `jessezhang.org`. Il cite son cofondateur **Ashwin Sreenivas**, **ex-Palantir**, d'où la profondeur du récit Palantir. Publié le **11 août 2026**.

Dirigeant d'éditeur argumentant pour le modèle économique de son propre produit, dans un débat où l'alternative est incarnée par des concurrents et des cabinets. Trois conséquences pratiques : les chiffres Decagon sont **auto-déclarés au public d'X, sans définition ni audit** ; l'auteur reconnaît lui-même que son marché (*« service client : gros volume, répétable, décomposable »*) est particulièrement favorable à l'approche produit, ce qui limite la portabilité de la conclusion ; et le récit Palantir est reconstruit rétrospectivement à partir de sources publiques et d'une expérience de seconde main. La partie conceptuelle — le test découverte/absorption, la distinction FDE ≠ implémentation — est indépendante de ces réserves ; la partie empirique ne se cite qu'attribuée.

## Ton

**Profile**: operator essay, **argumentative and normative** register, published as a long-form article on X (~1,500 words). Audience: founders, go-to-market executives, investors. Thesis openly stated, counterargument anticipated. This isn't an engineering post: no technical detail, no architecture — the subject is the **delivery model**.

**Style**: five traits.

1. **The dilemma-title and the false binary it sets up only to dismantle.** *« To FDE, or not to FDE? »* poses an alternative; the conclusion rejects it (*« Go forward-deployed early »* **and** *« start taking the FDEs out »*). The real answer is a **sequence**, not a choice.
2. **The opening concession as a credibility device.** Zhang starts by validating the use of FDEs (*« yes, send engineers. Sit in the room »*) before bounding it. The target isn't the practice — it's **its permanence**.
3. **The borrowed formula as pivot.** *« FDEs eat pain and excrete product »* isn't his own line — it's **Shyam Sankar's** — and it serves as an **operating criterion**: it gets flipped at the end of the piece to produce the test (*« eating pain and excreting more pain »*). The whole rhetorical architecture rests on that one sentence.
4. **The closing volley of questions.** Five questions in one paragraph — *is the bespoke work in the customer's environment or in the holes in your product? is the last mile irreducible or just unbuilt? are your FDEs discovering something or absorbing something? what got put into the product the last time one of them came back from the field?* — a **checklist format**, directly reusable in review.
5. **The admission of economic tension, slipped in without emphasis.** *« Nothing about the underlying economics has changed »*: the model was rehabilitated by fashion, not by the numbers. It's the hardest sentence in the piece, and it isn't underlined.

**Marker phrases**: *« FDEs eat pain and excrete product »* · *« The trap is not starting. It's not stopping. »* · *« The pain was the input to the product, not a cost of sale »* · *« Every bespoke fix in the field is a product decision you chose not to make »* · *« Each deployment should make the next one easier »* · *« Is the last mile irreducible, or just unbuilt? »* · *« Are your FDEs discovering something, or absorbing something? »* · *« customers who just wanted Accenture with better software »* · *« you don't have an FDE team. You have a services business. »*

**Epistemic stance**: **a stakeholder arguing a case**, not an observer. Solid on the concepts, self-interested on the numbers.

## Pense-betes

- **Date / source**: **August 11, 2026**, long-form article on **X** by **Jesse Zhang**, CEO of Decagon.
- **Key framing**: the rule fits in one sentence — *« The trap is not starting. It's not stopping. »* ### The four-question test Value that transfers beyond the article, independent of Decagon — quarterly-review format: | Question | What it discriminates | |---|---| | Is the bespoke work in **the customer's environment** or in **the holes in your product**? | legitimacy of custom work | | Is the last mile **irreducible** or **simply unbuilt**? | fate vs. debt | | Are your FDEs **discovering** or **absorbing**? | discovery vs. amortization | | What was **put into the product** the last time an FDE came back from the field? | proof, not intent | The fourth is the only **verifiable** one: the first three answer themselves favorably, this one demands an artifact. ### The mechanics of drift Keeping the FDEs is easier sprint by sprint taken in isolation: the FDE lets a company *« avoid every hard product trade-off »* — one never decides what the product does, which of two customer requests wins, where the configuration surface stops. *« No one has to say no to anyone. »* The drift comes from no single bad decision but from the repeated absence of one. Associated cost: *« Every bespoke fix in the field is a product decision you chose not to make. »* ### FDE ≠ implementation | | FDE | Implementation | |---|---|---| | Object | **discovery** of an unknown spec | **execution** against a known spec | | Example | sitting in the room, watching the product break | *« building the integration into their ticketing system »* | | Expected output | **product primitives** | a **customer deliverable** | *« Lumping the two under one title is how a company convinces itself that a growing services org is a product investment. »* Inventory test: count, within a team labeled FDE, the share of work that is actually implementation. Zhang adds that this is the half models are absorbing — *« a good part of what an implementation team did in 2023 becomes something the product does itself »*. ### The Palantir genealogy, a textbook case of "services → product" Bespoke **Gotham** deployments (CIA, NSA, military intelligence, mid-2000s) → encoding the problems encountered into **platform primitives** (ontology, object models, permissions, workflow engines, provenance tracing) → **Foundry**, commercially sellable → Apollo, AIP → standardization, **gross margin in the 80% range**, shift to account-based selling, FDEs reabsorbed into core engineering. Two details that make the case: Palantir carried the *« glorified consultancy »* criticism for nearly twenty years — Lonsdale acknowledging the observation was accurate — and **turned down contracts** where the customer just wanted *« Accenture with better software »*. Line worth keeping: *« The FDE team wasn't the business model. It was how you built the right product. »* ### Counter-test: the same indicator, two readings In May 2026, [[mollick-roon-asi-consulting-forward-deployed-engineering-2026-05-10]] argued we'd know the labs believed in ASI the day they **dissolved** their FDE teams — and observed that they were hiring them instead. Zhang describes, three months later, the reverse movement at startup scale: the product eats the deployment work. Both texts use the same indicator — the size of the FDE org as a measure of what the product still can't do — one to cast doubt on a narrative, the other to claim progress. They don't contradict each other: Zhang confirms the FDE-hiring trend and himself notes that Anthropic and OpenAI have built deployment arms modeled on Palantir. ### Why now, and the expiration date In 2015, building a SaaS CRM required no workflow discovery — twenty years of practice had already defined what a pipeline, a stage, a lead handoff was. In 2026, an AI agent for accounting has no established workflow, *« because literally no one has ever used one »*. Corollary: the customer can't say what they want, because the thing they'd want doesn't have a shape yet. The FDE is therefore justified only by **the category's novelty**; as soon as the shape stabilizes, the justification falls away. ### The two figures, and how to cite them | Stated figure | What's missing | Acceptable usage | |---|---|---| | *« Two-thirds of deployment work is now done autonomously via Duet »* | definition of the denominator (hours? tickets? steps?), scope, period, method | *« Decagon states »*, never *« Decagon measured »* | | *« A few days on average to launch the first AOP, even for large banks, airlines, telcos »* | the **AOP acronym is not spelled out**; no starting point for the clock, no sample size | a dated commercial claim | These are executive assertions on X, made the day he's defending his model: the source and the date are part of the figure. ### The two constants heard from enterprise customers 1. **Iteration speed** — *« Shipping an AI agent isn't a one-shot; it has to be tuned and updated continuously. If every adjustment requires engineering, it'll be far too slow and expensive to scale. »* Structural argument against the permanent FDE: a question of loop latency, not margin. 2. **Vendor lock-in** — *« Given organizations' experience with SaaS, no one wants to be locked into a vendor and dependent on its resources. »* An FDE org **is** a dependency, from the customer's point of view. ### The declared trade-off and its limit Decagon says it chose not to hack fixes in the field when that would have been faster, and instead to **turn escalations into requirements rather than patches** — *« which takes time in the short term »*. Formula worth keeping in architecture review: escalation → requirement, not escalation → patch. Honest counterpart: *« very few startups can sign the eight-figure deals Palantir landed from the start »*, which makes the FDE economics even less sustainable for them. **Limit of applicability stated by the author**: the product-led approach holds for Decagon because customer service is *« high-volume, repeatable, and decomposable »*. Those three adjectives are the condition — a low-volume, non-repeatable, non-decomposable domain doesn't tip the same way. Don't carry the conclusion without carrying the condition.

## RésuméDe400mots

Long-form article published on **X** on **August 11, 2026** by **Jesse Zhang**, CEO of **Decagon** (customer-service AI agents).

**The starting observation.** The *Forward Deployed Engineer* has become the default answer to every AI go-to-market difficulty: painful deployments, customers unable to self-serve, product not ready. **Anthropic and OpenAI** have built enterprise deployment arms **explicitly modeled on Palantir**; job postings for the title are said to be up several hundred percent in a year. Yet, Zhang notes, until recently this was **a point of criticism** — lower-quality revenue, structurally capped margins — and *« nothing about the underlying economics has changed »*. What has changed: in the AI era, companies don't know the path to the outcome but they believe in the outcome, and **the FDE delivers the outcome**.

**The Palantir precedent.** Shyam Sankar, CTO: ***« FDEs eat pain and excrete product. »*** Joe Lonsdale acknowledges that the "glorified consultancy" reputation rested on an accurate observation. **Gotham**'s bespoke deployments were encoded into primitives — **ontology, object models, permissions, workflow engines, provenance tracing** — which became **Foundry**, then Apollo and AIP. With standardization, **gross margin climbed into the 80% range** and Palantir left the FDE motion behind. *« The pain was the input to the product, not a cost of sale. »*

**The thesis.** Sending engineers is justified **when the category is new**: an accounting agent in 2026 has no established workflow, and the customer cannot even describe it. **But once the paths are known, the FDEs have to come out — and no one will want to**, because keeping them is easier sprint by sprint: one never has to settle a product trade-off, say no, or make a painful architecture choice. That leaves **all the drawbacks of the model with none of the discovery benefit**. Zhang further distinguishes **FDE from implementation**: one discovers an unknown spec, the other executes a known one; conflating the two lets a services org pass for a product investment.

**The Decagon case.** A deliberate product-led approach, driven by two constant enterprise demands: **iteration speed** and **refusal of vendor lock-in**. Cost: turning escalations into requirements rather than patches. **Self-reported** benefit: *« two-thirds of deployment work »* now done autonomously via **Duet**, and *« a few days »* to launch the first **AOP** at large banks, airlines, or telcos. Figures that are undefined and unverifiable.

**The closing line**: *« If your FDEs are eating pain and excreting more pain, you don't have an FDE team. You have a services business. »*

## GrapheDeConnaissance

- Jesse Zhang —dirige→ Decagon (ORGANISATION, 0.97)
- Ashwin Sreenivas —travaille_chez→ Decagon (ORGANISATION, 0.95)
- Ashwin Sreenivas —travaille_chez→ Palantir (ORGANISATION, 0.92)
- Jesse Zhang —recommande→ d'engager un motion forward-deployed tôt pour découvrir les parcours utilisateurs, puis d'en retirer les ingénieurs une fois ces parcours connus (AFFIRMATION, 0.95)
- Jesse Zhang —affirme_que→ le piège n'est pas de commencer un motion FDE, mais de ne pas s'arrêter (CITATION, 0.96)
- Forward Deployed Engineering —permet→ de découvrir des parcours utilisateurs qui n'existent pas encore, dans une catégorie où ni l'éditeur ni le client ne savent à quoi ressemble le workflow (AFFIRMATION, 0.93)
- Forward Deployed Engineering —s_oppose_à→ l'implémentation, qui exécute contre une spec connue au lieu de découvrir une spec inconnue (AFFIRMATION, 0.92)
- Forward Deployed Engineering —observé_dans→ un plafonnement structurel des marges, un coût de servir qui ne décline pas et une croissance bornée par le recrutement lorsque le motion est maintenu au-delà de la phase de découverte (AFFIRMATION, 0.9)
- Shyam Sankar —affirme_que→ les forward deployed engineers digèrent de la douleur et excrètent du produit (CITATION, 0.95)
- Shyam Sankar —travaille_chez→ Palantir (ORGANISATION, 0.95)
- Joe Lonsdale —affirme_que→ Palantir a longtemps été vue comme un cabinet de conseil déguisé, sur la base d'une observation exacte : ses ingénieurs passaient beaucoup de temps chez les clients (CITATION, 0.92)
- Palantir —utilise→ Forward Deployed Engineering (METHODOLOGIE, 0.96)
- Palantir —publie→ Gotham (TECHNOLOGIE, 0.94)
- Foundry —est_basé_sur→ les primitives encodées depuis les déploiements Gotham sur mesure : ontologie, modèles d'objets, permissions, moteurs de workflow et traçabilité de provenance (AFFIRMATION, 0.93)
- Palantir —mesure→ une marge brute montée dans les 80 % une fois les déploiements standardisés autour de Foundry (MESURE, 0.88)
- Palantir —réduit→ son recours au motion FDE au profit d'une vente par comptes, une fois Foundry mature (AFFIRMATION, 0.9)
- Anthropic —utilise→ Forward Deployed Engineering (METHODOLOGIE, 0.9)
- OpenAI —utilise→ Forward Deployed Engineering (METHODOLOGIE, 0.9)
- Decagon —publie→ Duet (TECHNOLOGIE, 0.93)
- Decagon —mesure→ deux tiers du travail de déploiement réalisés de façon autonome par Duet — configuration, itération et longue traîne du tuning (MESURE, 0.9)
- Decagon —mesure→ quelques jours en moyenne pour lancer le premier AOP, y compris chez de grandes banques, compagnies aériennes et télécos (MESURE, 0.85)
- Decagon —recommande→ de transformer les escalades client en exigences produit plutôt qu'en correctifs sur le terrain (AFFIRMATION, 0.92)
- Decagon —s_oppose_à→ un modèle de livraison piloté par les services ou par les FDE, au profit d'un modèle piloté par le produit (AFFIRMATION, 0.94)
- test discovery vs absorption —permet→ de décider s'il faut maintenir une équipe FDE, en demandant ce qui a été intégré au produit au retour du dernier terrain (AFFIRMATION, 0.88)
- vitesse d'itération —s_oppose_à→ un modèle où chaque ajustement d'un agent IA nécessite une intervention d'ingénierie (AFFIRMATION, 0.9)
- verrouillage fournisseur —s_applique_à→ une organisation de déploiement chez le client, perçue par l'entreprise cliente comme une dépendance aux ressources de l'éditeur (AFFIRMATION, 0.85)
- agents de codage —réduit→ la part du travail d'implémentation autrefois réalisée par une équipe de services, désormais absorbée par le produit lui-même (AFFIRMATION, 0.87)
- service client —permet→ une approche produit plutôt que services, parce qu'il est à gros volume, répétable et décomposable (AFFIRMATION, 0.9)

---
Canonical: https://www.thekb.eu/en/fiches/zhang-decagon-fde-produit-2026-08-11/