On September 14, TechCrunch published three agenda pieces for Disrupt 2026: an invitation to hear how AI can engineer nature's comeback with the founder of a de-extinction startup valued in the billions, a session on what happens when OpenAI ships your roadmap, and a reminder that applications for expo tables close on September 18, in front of more than 10,000 founders, investors, and technical leaders. All three are selling tickets: there's no technical content inside. Two days earlier, Latent Space published Vinoo Ganesh's analysis of Forward Deployed Engineers, and that one is worth reading closely.
Why it matters
The session titles at a conference are a good thermometer for market anxiety. The fact that TechCrunch built an entire session around the question what if the model lab ships exactly what you were about to build? tells you the worry stopped being hypothetical. The piece puts it plainly: the question isn't whether foundation models will keep evolving, but whether your company will keep generating value while that happens.
Ganesh's text is the other half of the same conversation. He built the forward deployed function three times over more than a decade: at Palantir, where he led Project Frontline and around 250 engineers rotated through it; at Citadel, where the only criterion was whether the software helped portfolio managers generate alpha; and today at Kepler, where the role lives inside product, not inside sales. His central observation is uncomfortable: almost nobody agrees on what that engineer is supposed to accomplish. At a dinner with fellows from the a16z program, he found that the same label described — depending on the seat — a sales engineer who joins on the second call, a quota-carrying salesperson who knows Python, and a consultant with a laptop and a statement of work.
My read: the FDE isn't a job-title fad, it's the labor-market answer to the commoditization of the thin layer. When the model does more and more, what's left as defensible is the customer's context: their dirty data, their weird process, their particular definition of "correct." Putting an engineer inside that operation is an architecture decision disguised as a hiring decision.
What changes in practice
If you work on top of a model API every day, the concrete change is where you put the effort. Polishing the wrapper stops paying off, and everything the model can't guess starts paying off: the customer's data schemas, unwritten business rules, deterministic validation of outputs. Ganesh describes Kepler's domain as one where a plausible but wrong answer is worse than no answer at all. That sentence should be taped to the wall of any team wiring LLMs into a flow with consequences.
The distinction that helps most when deciding is which of these three roles you're actually hiring. Ganesh's material separates them like this:
| Axis | FDE | Consulting | Sales engineer |
|---|---|---|---|
| Who they report to | Product (the Kepler case) | Services, against a statement of work | Sales |
| Where they work | Inside the customer's operation | On a scope agreed up front | In the sales cycle |
| What they leave behind | Capability that can flow back into the product | A closed deliverable | A closed deal |
| How they're measured | Whether the customer's problem got solved | Contract fulfillment | Quota |
The column that decides everything is the first one. If the role hangs off sales, the incentive pushes toward promising what the product doesn't do, and the engineer ends up patching the hole with code that exists at exactly one customer. If it hangs off product, every implementation has to answer an extra question: is this a generalization that flows back into the core, or a fork we'll maintain forever? That question is what saves you from waking up with twelve product branches and a single team.
When it's NOT worth it
First, the obvious: if you can't write in one line what that engineer delivers, don't hire one yet. The article itself shows the market hasn't even agreed on the definition. Hiring an ambiguous role with a trendy title is the most expensive way to discover you actually wanted a consultant.
Second, team size. On a small team, the FDE is the engineer who isn't improving the product. If you have three people and you put one inside the customer, you dropped core velocity by a third to raise one account's satisfaction. Sometimes it's worth it; decide it with your eyes open and don't call it strategy.
Third, honesty about the data. There isn't a single number in this material on retention, margin, implementation time, or comparative success. There's firsthand experience from someone who built the function three times, and that counts for something, but it isn't quantitative evidence. Anyone selling you the FDE as a proven model with numbers is adding data that isn't in the source.
Fourth, and this applies to the event itself: the three TechCrunch posts are promotion. The de-extinction one doesn't offer a single technical detail about how AI gets applied to the problem. Treating them as analysis would be a mistake; they're the table of contents, not the content.
What I'd do today
If I'm building on third-party models, I'd spend this week on a single question: if the provider shipped 80% of what I do tomorrow, what's left? If the answer is "the integration with the customer's data and process," you're on track and the forward deployed pattern works as a way to organize the work. If the answer is "the interface," you have an architecture problem, not a hiring problem, and no new job title fixes it.