The FDE Delivery Workflow: From Field Discovery to Reusable Production Systems

The FDE Delivery Workflow: From Field Discovery to Reusable Production Systems

Forward Deployed Engineering is not simply a job title.

It is a delivery mechanism for situations in which learning from the real operating environment materially changes what should be built.

A conventional implementation can work well when requirements are stable, integrations are known, the product is mature, and rollout follows a repeatable playbook. FDE becomes useful when those assumptions break: users cannot fully describe the workflow, important rules live in practice rather than documentation, production systems impose hidden constraints, and every deployment can reveal a pattern worth adding to the product.

A compact model is:

FDE = field understanding × engineering execution × business closure × reusable learning

The multiplication signs matter. A team that misses any one factor can produce a polished prototype without creating a durable result.

This guide turns that model into a complete delivery workflow with artifacts, stage gates, stop conditions, and a seven-day starting plan.

When does a problem actually need FDE?

Use three dimensions:

FDE fit = uncertainty × integration depth × feedback value

1. Uncertainty

The business problem is important, but the exact workflow, requirements, exception rules, or technical approach cannot be specified confidently in advance.

The signal is not merely that stakeholders disagree. The signal is that observing real users and real cases is likely to change the design.

2. Integration depth

The useful solution must connect to authoritative data, identity, permissions, existing applications, approval paths, or operational controls. A standalone demo cannot deliver the outcome.

3. Feedback value

The engagement can generate reusable knowledge: a connector, workflow pattern, evaluation set, policy control, deployment method, or platform requirement that reduces the cost of later deployments.

These dimensions are multiplicative in spirit, not a literal financial formula. A project with high uncertainty but almost no integration may be a discovery sprint. A deeply integrated but fully standardized rollout may be ordinary implementation. FDE is strongest when all three are material.

Ask three questions:

1. Would direct field observation change the problem definition?
2. Must the solution enter a real system of record or operating workflow?
3. Can the resulting learning improve a platform or future delivery?

The more confidently the answer is yes, the stronger the FDE case.

FDE engagement or standard delivery?

FDE is not the premium answer to every project.

Use standard delivery when a mature product already solves the problem. Adding an FDE can increase cost, create unnecessary customization, and weaken product discipline.

Use FDE when proximity to users is necessary to discover the correct system and when the learning has a credible path back into the product.

The unit of FDE work is a scenario loop

Traditional project management often decomposes work into tasks: build an endpoint, add a screen, migrate documents, or configure a model.

An FDE should manage a scenario loop:

real user and trigger
→ data and system context
→ AI or software action
→ human decision or downstream action
→ measurable outcome
→ captured failure and product learning

A task can be complete while the scenario still fails. The endpoint may work, yet the user cannot access it. The answer may be accurate, yet it arrives too late. The model may produce a recommendation, yet no one trusts the evidence enough to act.

That is why the FDE unit is not a ticket. It is a workflow that has survived contact with reality.

The seven-stage FDE delivery workflow

The workflow is iterative. A team may return to an earlier stage when evidence changes. The stages still provide useful control points.

Stage 0: select the scenario

Start with one important workflow, not a general mandate to “bring AI into the business.”

Capture:

• target user and operating moment;
• current process and baseline;
• costly failure or bottleneck;
• measurable desired outcome;
• executive and operational owner;
• access to representative users and cases;
• reason FDE is more appropriate than standard software delivery.

Gate: Is the problem valuable, observable, and owned?

Do not proceed if no accountable business owner exists, users are inaccessible, or success cannot be distinguished from failure.

Stage 1: discover the field reality

Observe the work rather than relying only on interviews. Follow several normal cases and several exceptions. Identify who makes decisions, which tools they use, where data originates, how handoffs occur, and what informal workarounds keep the process running.

The primary artifact is a current-state workflow map containing:

• actors and responsibilities;
• triggers and outputs;
• systems and data sources;
• decisions and exception paths;
• delays, rework, and escalations;
• tacit rules and unresolved assumptions.

Gate: Can the team explain the workflow well enough for a domain expert to correct it?

Discovery is not complete because a workshop ended. It is complete when disagreements and unknowns have become visible.

Stage 2: model constraints and risks

Translate observations into engineering boundaries.

At minimum, map:

• data availability, quality, ownership, and retention;
• identity, authorization, and least-privilege access;
• system APIs, rate limits, and failure behavior;
• latency, volume, availability, and cost expectations;
• harmful errors and unacceptable actions;
• required human review and escalation;
• audit, compliance, and change-control obligations.

NIST’s AI Risk Management Framework is useful here because it treats governance, context mapping, measurement, and risk response as an iterative system rather than a one-time checklist.

The key artifact is a constraint register with an owner and a proposed test for every material uncertainty.

Gate: Is there a safe and testable boundary for a first release?

Stop or rescope if the system requires unavailable data, unauthorized access, unacceptable autonomy, or a level of reliability that the proposed architecture cannot support.

Stage 3: build the smallest closed-loop prototype

The prototype should answer the riskiest question, not demonstrate the largest number of features.

A useful prototype includes enough of the real loop to test:

• representative inputs;
• the core model or rules;
• evidence and citations where required;
• a user decision or action;
• error capture;
• a basic evaluation set;
• a manual fallback.

Keep high-risk actions read-only or approval-gated until evidence justifies more autonomy.

Gate: Does the prototype produce useful behavior on representative cases, and have the team’s largest uncertainties become smaller?

If users reject the workflow even when the technology works, do not hide the result by adding features. Revisit the problem or stop.

Stage 4: integrate the production path

A prototype becomes a system only when it respects the operating environment.

Production integration commonly requires:

• enterprise authentication and authorization;
• governed data ingestion and synchronization;
• tool or API contracts;
• validation and idempotency for write actions;
• logging, tracing, and cost attribution;
• environment separation and release controls;
• timeout, retry, fallback, and degradation behavior;
• incident ownership and rollback.

Google Cloud’s production AI guidance similarly frames deployment as an operating lifecycle, including evaluation, observability, reliability, and rollback—not merely model hosting.

Gate: Can the bounded workflow run safely, repeatedly, and supportably with real users?

“It worked once” is not an acceptance criterion.

Stage 5: validate the business loop

Evaluate four layers together:

Offline evaluation cannot prove adoption. A usage dashboard cannot prove answer quality. A business result cannot excuse uncontrolled risk.

Define thresholds before interpreting the result. Record segments and failure distributions rather than hiding them behind one average.

Gate: Is there enough evidence to stop, revise, standardize, or expand?

Stage 6: productize the learning

The engagement compounds only when field learning becomes an organizational asset.

Useful outputs include:

• reusable connectors and permission patterns;
• workflow and UI components;
• golden datasets and evaluation harnesses;
• policy, review, and escalation templates;
• reference architectures and deployment automation;
• runbooks, discovery guides, and acceptance criteria;
• product requirements supported by repeated evidence.

Not every project-specific workaround belongs in the core product. Classify each learning:

1. customer-specific configuration;
2. reusable delivery asset;
3. shared platform capability;
4. core product requirement.

Gate: Is there an owner, destination, and adoption plan for each reusable asset?

A retrospective document that no one uses is not productization.

The FDE translation layer

FDE connects two forms of truth that rarely line up automatically.

This translation layer is why an FDE cannot be only a communicator or only a coder. The role must preserve meaning while converting field constraints into executable system behavior.

A seven-day FDE starting plan

This is a kickoff sprint, not a promise to deploy a complete production system in one week.

Day 1: choose one real scenario

Identify the target user, business owner, workflow trigger, current pain, and desired outcome.

Day 2: map the current workflow

Observe or reconstruct normal cases, exceptions, decisions, systems, and handoffs.

Day 3: name the three hardest constraints

Prioritize data access, system integration, user collaboration, risk, or another constraint that can invalidate the project.

Day 4: define the smallest closed loop

Choose one narrow user journey and the smallest system behavior that can test value.

Day 5: agree on evidence

Set one or two measures for AI quality, system operation, adoption, and business outcome. Define what would count as failure.

Day 6: test with real users or representative cases

Capture wrong answers, missing data, latency, confusion, refusal, workarounds, and unexpected value.

Day 7: make an investment decision

Choose explicitly:

• continue toward production;
• revise the workflow or architecture;
• reduce scope and test again;
• hand off to standard delivery;
• or stop.

The week succeeds when uncertainty falls enough to support a better decision, even if the decision is not to build.

The FDE control panel

Four controls keep speed from turning into uncontrolled customization.

Speed

How quickly can the team convert an assumption into observable evidence?

Depth

Does the team understand the business process, data, systems, and consequences deeply enough to design the right boundary?

Boundary

Can the team say what will not be built, which actions require review, and when the project should stop?

Compounding

Does each engagement improve the next one through components, evaluations, methods, or product changes?

A mature FDE team optimizes all four. Speed without depth creates demo theater. Depth without boundaries creates endless consulting. Delivery without compounding creates a custom-development queue.

Common failure modes

Coding before observing

The team implements the stated request before seeing the actual workflow. It optimizes the wrong unit of work.

Treating the prototype as proof

The demo uses curated inputs, administrator permissions, and an expert operator. Production introduces noisy data, real identities, exceptions, and support obligations.

Measuring only model quality

The evaluation reports answer scores but ignores latency, task completion, adoption, harmful errors, and operational cost.

Automating before defining control

The agent can write to systems before approval boundaries, idempotency, audit, and rollback are designed.

Confusing customization with product learning

Every request is accepted as a product feature. The platform becomes a collection of one-customer branches.

Finishing without an operating owner

The FDE team leaves, but no business or platform owner maintains the workflow, evaluation set, incident response, and adoption process.

What good FDE delivery leaves behind

A successful engagement should leave five kinds of evidence:

1. Problem evidence: a verified workflow, baseline, constraints, and success definition.
2. System evidence: a controlled production path, not only a demo.
3. Quality evidence: evaluations, failure analysis, and acceptable limits.
4. Outcome evidence: user behavior and business results within a stated scope.
5. reuse evidence: assets and product decisions that make future delivery faster or safer.

OpenAI’s current FDE descriptions emphasize ownership from discovery and technical scoping through system design, build, and production rollout. That end-to-end responsibility is the defining thread.

The deepest principle is still simple:

FDE does not sell the possibility of a feature. It turns a real scenario into an operating system path—and turns the learning from that path into reusable capability.

References

• OpenAI — Forward Deployed Engineer, Seoul
• OpenAI — Technical Deployment Lead, Forward Deployed Engineering
• NIST — AI Risk Management Framework
• NIST AI Resource Center — AI RMF Core
• Google Cloud — Deploy and operate generative AI applications
• Google Cloud — AI and ML operational excellence
• AWS — Architecting production feedback loops