The FDE Mission Playbook: Scoping, Running and Landing Forward-Deployed AI Work

Most enterprise AI work stalls in the space between a promising demo and a system that people rely on every day. The forward-deployed engineering (FDE) model was built for exactly that space: a senior engineer works inside the customer's environment, on the customer's data and workflow, until the system is in production and proven. This playbook sets out how to scope, run and land an FDE mission, from the first working session to a clean handover.

Why the forward-deployed model exists

The term comes from Palantir, which split its engineering organization into two roles. Product engineers focus on "one capability, many customers," building the core platform. Forward Deployed Software Engineers, known internally as Deltas, focus on "one customer, many capabilities," deploying and customizing the software at the customer site to solve a specific business problem, and building missing features when that is what stands between the customer and a successful outcome¹.

The model has since moved to the center of generative AI delivery. OpenAI's own FDE job description asks engineers to "embed closely with customer teams," to "own technical delivery across multiple deployments from first prototype to stable production," and to measure success "through production adoption, measurable workflow impact, and eval-driven feedback"². Those three phrases are a compact definition of the job: embedded, accountable for production, and measured on outcomes.

The reason this matters is the scale of the gap between pilots and production. MIT NANDA's The GenAI Divide: State of AI in Business 2025 reports that despite $30–40 billion in enterprise investment, 95% of organizations are getting zero return from generative AI, and only 5% of custom enterprise AI tools reach production³. The same research found that external partnerships with learning-capable, customized tools reached deployment about 67% of the time, compared with about 33% for internally built tools³⁴. RAND's interviews with 65 experienced data scientists and engineers identified the leading root cause of failure as a misunderstanding or miscommunication of the problem that AI is meant to solve⁵. An engineer who sits with the people doing the work closes that gap directly.

An FDE mission is measured by one thing: whether a real workflow runs differently, in production, with numbers that the business accepts.

The shape of the team

An FDE mission works best with a small, senior team and a short line of accountability. At Quantabase this unit is the Mission Pod: a senior forward-deployed engineer paired with a delivery lead, drawing on specialists from a vetted expert network when the work calls for them.

The defining feature is that the engineer who builds the system is the same person who sits with its users. Feedback does not travel through a requirements document; it travels across a desk.

The week-by-week plan

A typical mission runs six to twelve weeks, with the first production release inside two weeks. The early release is deliberately narrow: a real slice of the workflow, live on real data, used by a small group, with monitoring in place. Everything after that widens coverage and raises confidence.

Week 0: the working session

Before any contract is finalized, the pod and the customer spend a half day working through the target workflow together. The goal is a shared, written view of the problem rather than a sales presentation.

1. Walk the workflow. Observe or replay ten to twenty real cases end to end, noting every system touched, every judgment call and every handoff.
2. Size the economics. Record volume per month, minutes per case, cost per case and the current error or rework rate.
3. Locate the data. Identify where inputs live, who owns them and what access will require.
4. Agree the business owner. One person who will own the outcome after launch.
5. Draft the definition of done. A first version of the accuracy bar, coverage target and adoption target.

Week 1: scope and foundations

• Finalize the mission charter: in-scope case types, excluded case types, success metrics and milestone gates.
• Secure data and system access through the customer's normal security process.
• Build the gold evaluation set: 100–300 real, labeled cases that represent the workload, including known hard cases.
• Stand up the evaluation harness so every change is scored against the gold set before it ships. OpenAI's FDE team and its customers have used this eval-first approach in production; Morgan Stanley, for example, ran summarization evals graded by advisors and daily regression tests before scaling its assistant, which is now used by over 98% of advisor teams⁶.
• Agree the exception path: what happens when the system is unsure, and who receives those cases.

Week 2: first production release

The first release goes live for a limited group of users on a limited slice of cases. It runs in the customer's environment, behind the customer's authentication, with logging, cost tracking and an exception queue in place. In many missions the first release runs in shadow or assisted mode, where the system drafts and a person decides, so value and accuracy can be measured without operational risk.

Weeks 3–8: widen, harden and prove

Longer missions of up to twelve weeks usually add a second workflow or a deeper integration, following the same rhythm.

Definition of done

"Done" is written down in week one and approved by the business owner. A useful definition has five parts:

1. Accuracy: the system meets or exceeds the agreed bar on the gold set and on a sample of live production cases.
2. Coverage: a stated share of incoming cases is handled by the system, with the rest routed to people through the exception path.
3. Adoption: a stated share of target users rely on the system in their daily work.
4. Unit economics: cost per task is measured and within the agreed range.
5. Operability: monitoring, alerting, runbooks and an accountable owner are in place.

Evidence gates per milestone

Each milestone closes only when its evidence clears, and at Quantabase milestone payments follow the same rule. This keeps both sides focused on results rather than activity. The table below shows representative gates; the specific thresholds are set with the customer for each workflow.

Roles and RACI

Clear accountability prevents the most common slowdowns: waiting for access, waiting for labels and waiting for decisions. R = Responsible, A = Accountable, C = Consulted, I = Informed.

Risks and how to handle them

Independent research points to a consistent set of failure modes. Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, escalating costs and unclear business value⁷. S&P Global Market Intelligence found that the average organization scrapped 46% of AI proofs of concept before they reached production⁸. Each of these causes has a practical countermeasure inside a mission.

Handover and knowledge transfer

A mission is landed when the customer can run the system without the pod. MIT NANDA's research notes that successful organizations treat AI vendors more like business service partners than software providers and empower frontline managers rather than centralized labs³. Handover puts that principle into practice.

1. Pair from week five. A customer engineer pairs with the FDE on every change, so the code and its reasoning are familiar before the final week.
2. Document the operating model. Runbooks cover deployment, rollback, prompt and model updates, evaluation reruns and exception handling.
3. Transfer the evaluation harness. The gold set and scoring scripts are the most valuable artifacts; the customer team should be able to rerun them on demand.
4. Hand over dashboards. Accuracy on sampled live cases, coverage, exception volume, latency and cost per task, each with an owner and an alert threshold.
5. Confirm ownership. The business owner and operating team accept the system in writing, or an operating partner takes on monitoring. At Quantabase, Operate provides this ongoing coverage for accuracy drift, cost per task and exceptions.

Metrics that matter

McKinsey's 2026 State of AI survey found that only about 6% of respondents qualify as AI high performers, and that nearly three-quarters of those high performers have fundamentally redesigned workflows because of AI⁹. High performers are also twice as likely to report defined processes to measure the impact of their AI initiatives⁹. Measurement is part of the work, not an afterthought.

These metrics map naturally onto the NIST AI Risk Management Framework's Measure and Manage functions, which provide a voluntary, widely recognized structure for tracking trustworthiness across the AI lifecycle¹⁰.

A short checklist for mission leads

• Is there a single business owner with authority to approve the accuracy bar?
• Are baseline volume, time and cost per case recorded?
• Is there a labeled gold set that reflects real cases, including hard ones?
• Does every change run through the evaluation harness before release?
• Is the first release in production, with real users, within two weeks?
• Does each milestone have a written evidence pack reviewed by someone outside the build team?
• Has the system been adversarially tested before wider rollout?
• Are runbooks, dashboards and ownership confirmed before the pod steps back?

The forward-deployed model works because it removes distance: between the engineer and the user, between the build and production, and between activity and evidence. Run with discipline, it turns a promising pilot into a system the business depends on.