FDE Isn't On-Site Development: Why Enterprise AI Needs Ownership from Problem to Production

FDE (Forward Deployed Engineer) is often mistranslated as front-line deployment engineer. The common misunderstanding is that an FDE is simply a senior developer who understands business, writes code, and works long-term on-site. If merely renaming an engineer sent to the customer site to gather requirements, modify code, and handle issues, the FDE concept would be unnecessary — only the work location and delivery mode change, not the responsibility boundary.

The real problem FDE solves is a frequently broken responsibility chain in enterprise AI projects:

This chain spans business, product, architecture, development, data, security, operations, and the customer organization. Every link may have participants, but without someone owning the complete loop, projects stall at the proposal, prototype, acceptance, or long-term shadowing stage.

The FDE discussed here is first a closed-loop responsibility model, second a job title. "Someone is responsible" does not mean one person does all the work; it means the organization makes clear who continuously drives this responsibility chain and which professional roles and authorized parties jointly complete it.

On-Site Is a Collaboration Mode, FDE Is a Responsibility Model

"On-site" only describes where a person works, not what results they own. On-site personnel can handle requirements communication, system configuration, interface development, troubleshooting, and daily support — all important, but physical presence alone cannot determine whether someone is an FDE.

Beijing's Measures for Accelerating Development Led by Intelligent Agents lists FDE as a mode innovation to accelerate intelligent agent deployment, using the phrase "on-site co-creation, continuous iteration feeding back to intelligent agent capability improvement." This shows policy attention to tighter engineering collaboration among model providers, software firms, and industry customers, yet "on-site co-creation" remains a collaboration mode, not a unified role definition or professional standard.

OpenAI's description of its Deployment Company gives a more complete engineering chain: FDEs work with business owners, technical leads, operations staff, and front-line teams to identify high-value processes, then enter the customer organization to design, build, test, and deploy production systems, connecting models to the customer's data, tools, controls, and business processes.

Together, the key of FDE is not on-site duration but whether field facts are continuously converted into runnable, verifiable, and handover-ready production capabilities.

The article adopts this definition:

FDE is an engineering role or responsibility model accountable for "from ambiguous problem to production-ready, from production feedback to product learning."

It can be carried by a dedicated position, a front-line squad, or a combination of existing roles. Organizational form may vary, but the following responsibilities must not be fragmented without an owner.

Closed-Loop Stages and Required Outcomes

Field Facts: Fact sources, business constraints, unknowns, and non-goals are verifiable — not replaced by interview notes, feature wishes, or sales promises.

Engineering Boundaries: System boundaries, data and transaction authority, permissions, interfaces, and human-in-the-loop points are confirmed — not replaced by an architecture diagram without trade-off rationale.

Production Integration: The solution enters real data, identity, processes, tools, monitoring, and exception-handling chains — not replaced by a runnable prototype or a single successful tool call.

Result Verification: Value, quality, operations, and risk have explicit definitions, evidence, and owners — not replaced by feature counts, offline accuracy, or subjective evaluations.

Handover and Feedback: The customer or agreed handover party can operate independently within defined boundaries; field experience enters handover materials, internal knowledge bases, or formal products — not replaced by training completion, project acceptance, or long-term dependence on the original team.

"Responsible" here means ensuring every critical question has an owner, a deliverable, evidence, a decision, and can proceed to the next stage. FDE is not a pure coordination role; within authorized boundaries, it personally participates in key design, build, test, and deployment while driving other owners to produce their deliverables.

Why Enterprise AI Is Prone to Responsibility Breakpoints

Traditional software projects also cross business and technology, but enterprise AI amplifies uncertainty further.

Problems are initially unclear. Customers may ask for "an intelligent Q&A," "an Agent to auto-process orders," or "an enterprise knowledge base," but the real need may be cross-system lookup, anomaly detection, expert judgment, approval waiting, or result feedback loops. Function names cannot directly become engineering boundaries.

Model effectiveness ≠ system usability. A model generating correct answers does not mean it knows which data version to read, whose permissions to inherit, when to call tools, who takes over on failure, or which source system confirms the final result.

Production feedback loops back to change the solution. After go-live, new expressions, exceptional samples, permission conflicts, process exceptions, and user behaviors emerge continuously. Original eval sets, business rules, interaction modes, and product capabilities may all need adjustment. Go-live is not the end of project learning but the start of production learning.

Value often spans multiple teams. Business outcomes may depend simultaneously on data quality, process changes, system integration, user adoption, and management actions. No single party can easily prove "what AI brought," nor can all concurrent improvements be attributed to the model or one engineering team.

Previous articles on business research, PoC graduation criteria, and capability package scaling discussed opportunity discovery, production readiness judgment, and reuse of validated capabilities. This article does not repeat those methods; FDE's added responsibility is continuously preparing evidence, driving reviews, closing gaps, and distinguishing field specifics, domain commonalities, and product capabilities.

These issues won't disappear by adding more developers. What's truly missing is a role that continuously drives problem convergence, engineering implementation, production validation, and responsibility transfer.

An Abnormal Order Scenario to Clarify FDE's Position

The following synthetic scenario is designed for this series; it does not correspond to a real client project nor represent achieved production results.

A manufacturing enterprise wants AI to assist with abnormal orders. When an order may miss its delivery date, the system must aggregate order and procurement info from ERP, capacity and scheduling from MES, inventory from WMS, transport status from TMS, plus customer commitments and approval rules, to form impact analysis and handling recommendations.

This is not a problem solved by "developing an order Agent."

Pre-sales can explain product capabilities, solution architects can design overall solutions, business analysts can map processes, AI engineers can handle models and evaluation, data engineers can build data pipelines, test engineers can verify quality, SREs can ensure operations, and project managers can manage schedules.

Yet the project still needs continuous answers to:

When ERP, MES, WMS data conflict, which system is authoritative?

What recommendations can AI make, and which actions must retain human judgment?

Who has authority to modify scheduling, procurement plans, and customer commitments?

What model performance threshold allows entry into real processes?

How to handle rejected recommendations, execution failures, or state changes?

Who monitors, rolls back, reconciles, and handles escalations after go-live?

Which experiences belong only to this customer, and which can enter the general product?

FDE does not replace every professional role in answering all questions, nor does it accept business risks on behalf of the customer. Its responsibility is to organize these questions into a continuously converging engineering chain: confirm facts and owners, form boundaries and contracts, drive controlled implementation, obtain production evidence, complete operational handover, and feed reusable experience back to the product team.

Without this responsibility chain, projects easily fall into a state of apparent busyness but actual loss of control: every team completes its own tasks, yet no one can answer whether the whole system truly solves the problem, runs stably, or who handles issues when they arise.

FDE Is Not Merging All Roles Into One Person

"Understands both business and technology" is not a precise enough definition. Pre-sales, architects, implementation, and SREs may all understand business and technology; FDE's distinction must land on success signals and responsibility endpoints.

The table below compares only the most easily confused roles. It is this article's analytical framework, not an industry-wide role standard.

Role Comparison

FDE — Success signal: Field problems enter production, form verifiable results, and complete handover or stop. Core boundary: Drives cross-boundary closure but holds only minimal necessary authority.

On-Site Developer — Success signal: Completes development, modifications, and support per agreed scope. Core boundary: Work location does not automatically extend to value validation, handover, and product feedback responsibility.

Pre-Sales Engineer — Success signal: Purchase decision has sufficient technical basis. Core boundary: Can evaluate and demo solutions but usually not responsible for production closure.

Solution Architect — Success signal: Solution and technical approach are feasible under constraints. Core boundary: Responsible for architectural trade-offs but does not thereby gain production operation rights or full-loop accountability.

Professional Services / Implementation — Success signal: Contracted product and scope pass acceptance and handover. Core boundary: May obtain controlled configuration and deployment permissions but does not gain business decision authority.

SRE — Success signal: Service meets agreed reliability and operational targets. Core boundary: Owns continuous operation within service boundaries, feeds incidents and reliability issues back to engineering and product, but does not carry the full loop from business problem to product learning.

These boundaries do not imply FDE is superior to other roles, nor that one FDE can replace architecture, security, quality, operations, and product teams. FDE's uniqueness lies not in any single professional capability, but in ensuring the responsibility chain does not break at role handovers when problems still cross multiple boundaries.

In one sentence, the sharpest distinctions are: success signals cannot stop at on-time project acceptance; they must form measurable, auditable business result evidence with attributed boundaries. Work cadence cannot stop at delivery end; it must extend to production learning, handover, or stop. These two points are the benchmarks for FDE's responsibility boundaries revisited in later articles.

Project managers, business analysts, product managers, platform, AI, data, and quality engineers still own their respective professional outcomes. FDE does not replace these roles but personally completes key engineering work needed for closure and ensures responsibility does not fracture during handovers.

Five Signals That FDE Is Degrading Into On-Site Development

Whether FDE truly bears closed-loop responsibility cannot be judged by title alone. Any of the following signals warrants re-examining project boundaries; if multiple persist long-term, stop expanding scope and fix the responsibility chain first.

Boundless Requirements: Whatever the customer asks for gets scheduled.

Private Branches: Custom code keeps growing without judging product boundaries.

No Production Evidence: Development, demos, or acceptance replace real validation.

Cannot Independently Handover: Release, troubleshooting, and rollback keep depending on the original team.

No Product Feedback: Similar problems are repeatedly solved from scratch across different customers.

These signals are not demands to immediately terminate projects, but to stop piling on features. Teams need to reconfirm problem, scope, product boundaries, production gates, and exit criteria; if value hypotheses remain invalid or key risks cannot be closed, the project should end per stop conditions rather than packaging failure as long-term on-site demand.

When Is FDE Needed?

Not every enterprise AI project needs a dedicated FDE role.

OpenAI's FDE page positions FDE for complex, real, and highly ambiguous scenarios. Its public John Deere case shows the team reviewing hundreds of real samples with domain experts, building custom evaluations, and iterating continuously; the customer story also mentions a three-week planting window, real-time equipment data, and cross-functional business-technical collaboration constraints.

These facts illustrate the scenario's need for deep on-site collaboration and custom engineering, but do not prove FDE is the only organizational way to achieve results, nor can all business effects be attributed to a single FDE system.

Conversely, Stripe Payment Links provides hosted pages, console configuration, and no-code usage paths for defined online payment scenarios. Stripe's official materials prove standardized, self-serve enablement paths can exist; thus, when requirements fall entirely within that standard boundary and customers can independently enable and complete daily use, a dedicated FDE is usually unnecessary.

Therefore, judging the need for FDE should not depend on company size, contract amount, on-site duration, or whether LLMs are used, but on continuously answering three questions: Is the problem highly ambiguous? Does it cross data, permissions, and production? Can existing teams bear the full closure?

FDE is not the default answer for complex projects. Only when cross-boundary responsibility genuinely exists and the current organization has no one to own it does introducing FDE become a value investment; otherwise, it may just add an expensive coordination and delivery layer.

FDE's Responsibility Must Have an Upper Bound

Emphasizing closed-loop responsibility can easily push FDE to the opposite extreme: since they know the field best and can drive engineering, should they decide everything?

The answer is no.

FDE can gather facts, design solutions, participate in building, expose risks, drive validation, and organize handover, but cannot decide on behalf of the rightful authorities:

Business goals and priorities;

Budget, headcount, and organizational changes;

Data usage and security policies;

High-risk production actions and residual risk acceptance;

Source system transaction writes and final business state;

Whether customer assets can be anonymized, abstracted, or reused across customers;

Whether supplier product capabilities enter the roadmap and when they release.

Business, security, operations, and source system owners are designated by the customer organization; the customer decides its own asset usage scope; the supplier product owner decides whether field experience enters the product roadmap. FDE can provide evidence and recommendations but cannot concentrate these powers. Budget, organizational changes, and risk acceptance remain with the customer's internal authorized parties. A later concept, FDX (Forward Deployed Executive), will discuss organizational driving responsibility; it cannot replace the customer's ultimate responsible party, nor can FDE act as an unauthorized "external CEO."

Contracts cannot change these engineering facts. Even if FDE participates in pre-sales, they cannot promise business outcomes, implementation schedules, or production feasibility without field evidence; even with production permissions, they cannot interpret technical access as business authorization.

FDE must design their own exit from project start, not become permanent external aid. If the agreed handover party cannot independently release, troubleshoot, roll back, and escalate within their responsibility boundaries, the loop is not truly closed; if responsibility and risk have no owner, FDE cannot use "project accepted" as a reason for silent departure.

FDE's Value: Keeping the Responsibility Chain Unbroken

Enterprise AI lacks not solutions, models, platforms, or demos — what's truly scarce is the engineering capability to plug them into real work and continuously own the results.

FDE is not on-site development, nor a simple merge of pre-sales, architect, implementation, product manager, AI engineer, and SRE. It is a responsibility model that organizes engineering collaboration around complete outcomes:

Not "which segment of tasks did I complete,"
but "has this responsibility chain from problem to production truly closed."

This also means FDE does not necessarily need to become a new position in every enterprise, but as long as an enterprise AI project has the cross-boundary responsibilities described above, someone must be explicitly accountable for that closure. If the answer is "everyone shares responsibility," the outcome is often that no one truly owns it.

With role boundaries clarified, the next question is: after FDE enters the customer site, how to distinguish wishes, facts, constraints, risks, and unknowns, and find the truly engineerable problems.

That will be the topic of the next article in this series.

References

OpenAI launches the OpenAI Deployment Company

Forward deployed engineering at OpenAI

OpenAI: AI helps John Deere transform agriculture

Beijing Measures for Accelerating Development Led by Intelligent Agents

Stripe Payment Links

GitLab Solutions Architect

Google Site Reliability Engineering

U.S. Bureau of Labor Statistics: Sales Engineers

UK Government Digital and Data Capability Framework: Solution Architect

AWS Professional Services

ExplainThis: What is FDE? Why does the software industry need FDE?

Front-line Deployment Engineering Practice Guide