FORWARD DEPLOYED ENGINEERING
9 SRC
Forward Deployed Engineering
This synthesis records claims and practices from the cited sources; reported outcomes and product capabilities have not been independently verified.
FDE anchors AI production value in a specialized integration layer bridging raw model capability to enterprise workflows through process reengineering, context aggregation, human-in-the-loop design, change management, domain-specific evals, and governance. Greater model capability amplifies rather than reduces this layer's importance—more powerful models enable more complex tasks, raising integration costs. Palantir's expand-stage accounts improved from -43% to +35% contribution margin, and scale-stage accounts reached 55% (top quartile 87%), demonstrating that year-one losses convert into durable relationships. Yet the UK Dept for Business and Trade's Microsoft 365 Copilot trial (1,000 licenses, 3 months) achieved only 1.14 actions/user/day despite 72% satisfaction, confirming that companies automate broken processes rather than redesign them. Success requires consolidating process definition before deployment via process mining and 10–20 domain expert interviews; skipping either is the biggest discovery failure mode. A critical risk: letting model providers route enterprise tokens creates a conflict of interest. Current production workaround deploys small LLM classifiers for routing, citations, tool use, and escalation—described as 'hacky' pending better calibration methods like RLCD. Application roadmaps for law firms target matter selection, associate staffing, and billing dispute prediction.
Insights
forward-deployed-engineering
- OpenAI's Forward Deployed Engineer (FDE) roles pay up to $785K/year; per OpenAI's Head of FDE, the discipline's differentiator is making AI work reliably in production for real companies (e.g., Morgan Stanley was their first FDE case), using eval-driven development — contrasted with most developers who only build demos. (from harness loop graph engineering)
eval-driven-development
- OpenAI's FDE team practices eval-driven development: evals are built before demos, inverting the typical engineering workflow where measurement happens only after something breaks in front of a customer. (from eval driven fde gate development)
AI vs traditional software implementation
- AI agent deployment differs from traditional SaaS implementation because AI introduces a non-deterministic, rapidly changing system into workflows that have never been automated before — customers can't specify what they want because the workflow 'doesn't have a shape yet.' (from fde ai agents 2026)
- Unlike deterministic software (uniform upfront implementation, stable post-launch), AI agents require constant evals, model updates, harness changes, and business-process changes on the customer side — meaning FDE-style work doesn't shrink as capabilities improve, it can get more complex as customers throw harder processes at agents. (from fde ai agents 2026)
FDE-to-product conversion
- Palantir CTO Shyam Sankar's mantra 'FDEs eat pain and excrete product': bespoke early Gotham deployments (CIA, NSA, Army) were encoded into platform primitives (ontology, object models, permissioning, workflow engines, provenance tracking) that became Foundry — the pain was input to product, not a cost of sale. (from fde ai agents 2026)
- As Palantir's Foundry matured, standardized deployments cut custom work, gross margins climbed into the 80s, and the company shifted from FDE-led motion to account-based selling — migrating many FDEs into core engineering and declining deals that were essentially 'Accenture with better software.' (from fde ai agents 2026)
- Decagon's Duet product now autonomously handles two-thirds of deployment work (configuration, iteration, long-tail tuning), enabling first-agent launch in a few days even for large banks, airlines, and telcos — achieved by treating field escalations as product requirements rather than one-off patches. (from fde ai agents 2026)
FDE risk and misuse
- The FDE trap isn't starting, it's not stopping: keeping FDEs indefinitely feels easier each sprint (avoids hard product tradeoffs, delights customers) but caps margins, bounds growth by hiring, and turns every bespoke field fix into a forgone product decision. (from fde ai agents 2026)
- FDE (discovering an unknown workflow) is distinct from implementation (executing a known spec, e.g. 'integrate with their ticketing system') — bundling both under one title lets companies mistake a growing services org for a product investment. (from fde ai agents 2026)
- Diagnostic questions to evaluate an FDE team's health: Is the bespokeness in the customer's environment or your own product gaps? Is the last mile irreducible or just unbuilt? Are FDEs discovering something new or just absorbing repeat problems the product should solve? (from fde ai agents 2026)
organizational-change-management
- Claire Vo's proposed fix for the employee-creativity gap: internal FDEs (forward-deployed engineers), hack weeks, and dedicated investment in internal tools. (from ai adoption stalls human systems)
business-model-taxonomy
- Palantir is defined as a vertically-integrated outcome-based software provider combining tech-consulting-style solution selling with a real horizontal software platform (Foundry), unlike the market's default split between infra vendors (Databricks/Snowflake), operational software (SAP/Salesforce), and systems integrators (Accenture/Deloitte). (from why you cant copy palantir)
- Palantir's outcome/account-based pricing (fixed, multi-year, tied to anticipated customer value) removes the misaligned incentives of usage-metered software (Databricks/Snowflake, which lose revenue when they reduce customer consumption) and hours-metered consulting (Accenture/Deloitte, which can't justify losses on a single engagement). (from why you cant copy palantir)
- Per Palantir's 2020 S-1 'acquire, expand, scale' model: 2019 expand-stage accounts ran -43% contribution margin, reaching +35% in H1 2020; 2019 scale-stage accounts hit 55% contribution margin (top quartile 87%) — evidence that heavy year-one losses convert into highly profitable durable software relationships. (from why you cant copy palantir)
talent-selection
- Palantir's FDE talent model stacks independent filters (real software-engineering interview + elite-school optionality + willingness to travel/live in customer environments + operational interest + joining when the company was low-status) to produce engineers who both deliver customer outcomes and feed learnings back into reusable product primitives — a selection process traditional consultancies and software cos don't replicate. (from why you cant copy palantir)
product-architecture
- Foundry's differentiation is 'ontology' as an object-first, read-write operational semantic layer unifying analytical infrastructure (Databricks/Snowflake territory), operational/transactional systems (Salesforce/ServiceNow/UiPath/Retool territory), and on-prem/air-gapped deployment — a gap the modern data stack (metrics layers, dbt, Snowflake's Open Semantic Interchange) and automation stack (Zapier/UiPath) never bridged from either side. (from why you cant copy palantir)
deployco-competition
- Prediction: no current 'deployco' (lab deploycos OpenAI/Anthropic, neo-palantirs like Percepta/Distyl, holdcos Long Lake/Thrive/Sequence, CX cos Sierra/Decagon, cloud deploycos AWS/GCP) will meaningfully compete with Palantir in the next 5-10 years, because they lack both the patient capital for a 10+ year R&D cycle and genuine understanding of why Palantir's model worked. (from why you cant copy palantir)
- Structural incentive misalignment prevents incumbents from copying Palantir: Databricks can't divert R&D to build Salesforce-like transactional capability while competing with Snowflake on data processing, and Deloitte's partner-driven model can't sustain multi-year losses to build and staff an engineering team at Palantir's bar. (from why you cant copy palantir)
agentic integration building
- Ramp's agentic system lets customers describe a desired integration in natural language; the system builds and completes it automatically, without engineering involvement per request. (from ramp agentic integration factory)
applied-ai-failure
- UK Dept for Business and Trade's Microsoft 365 Copilot trial (1,000 licenses, 3 months) found only 1.14 Copilot actions/user/day; PowerPoint went from 18 to 11 minutes but at half the quality score; Excel analysis got slower and worse; official conclusion found no robust evidence of productivity gains, yet 72% of users were satisfied. (from applied ai doesnt work)
process-reengineering
- Michael Hammer's 1990 HBR insight: heavy IT investment delivers disappointing ROI because companies use technology to speed up existing broken processes ('paving the cow paths') rather than redesigning them — the same critique applies directly to AI adoption today. (from applied ai doesnt work)
- In Hammer's insurance case study, an application took 22 days to move through a business but only 17 minutes of actual work was done on it — meaning even doubling work speed via AI only saves ~8 minutes; the real waste is in queues, handoffs, and waiting periods, not the work itself. (from applied ai doesnt work)
- Consolidating systems first (one ERP/CRM/data platform) before applying AI is a costly trap: TSB spent £318M+£200M in incidents+£48.65M in fines on a core banking migration; Zimmer Biomet filed a $172M claim against Deloitte after a botched migration broke shipping and invoicing. Agents tolerate disagreeing systems better than deterministic integrations did, so unify process definition, not systems. (from applied ai doesnt work)
- Recommended process-mapping method: work at department level (not single workflow, not whole business), capturing 7 details per workflow bundle: happy path, exceptions (volume share/cycle time/cost), upstream/downstream dependencies, systems of record and conflict resolution, regional/entity variance, touch time vs elapsed time gap, and each person's AI-ability/ownership potential. (from applied ai doesnt work)
- Discovery requires both process mining (systems of record: timestamps, throughput, edits) and operator interviews (10-20 people who know where the real pain is) — doing only one produces an incomplete picture and is the biggest cause of AI discovery failure; AI-only interviews or engineer-led interviews don't work. (from applied ai doesnt work)
applied-ai-layer
- Applied AI value lives in a layer that connects raw model intelligence to enterprise workflows: reengineering processes, aggregating context/data, designing human-in-the-loop experiences, driving change management, running domain-specific evals, and managing security/governance. (from aaron levie applied ai layer gap)
- As models get more capable, the applied/workflow layer becomes MORE important, not less—greater capability enables more complex tasks, which amplifies the cost of not building the integration layer well. (from aaron levie applied ai layer gap)
- Letting model providers route your enterprise's tokens/traffic creates a 'fox guarding the henhouse' conflict of interest—application companies should be wary of ceding routing control to the labs whose models they depend on. (from aaron levie applied ai layer gap)
model-calibration
- Current production workaround for calibrated categorical decisions: small LLM classifiers deployed for routing, citations, parts of a knowledge vault, tool use, and user escalation — described as 'hacky' pending better calibration methods like RLCD. (from jev rlcd calibrated probabilities)
legal-ai-applications
- Longer-term application roadmap for law firms using calibrated categorical AI: matter selection, associate staffing decisions, and predicting billing disputes. (from jev rlcd calibrated probabilities)
Voices
8 contributors
Aaron Levie
@levie
ceo @box - your business lives in content. unleash it with AI
vas
@vasuman
Founder and CEO of Varick Agents. Make your company AI native @varickagents
Hanako
@hanakoxbt
claire vo 🖤
@clairevo
Gabe Pereyra
@gabepereyra
Lunar
@LunarResearcher
Tanay Jaipuria
@tanayj
ethan ding 📊
@TheEthanDing