OpenAI's FDE team: Making our earlier work unnecessary means we've done our job well

OpenAI has a dedicated engineering team that works directly alongside enterprise customers: Forward Deployed Engineers, or FDEs. Their job is to integrate models into customers' day-to-day operations and build systems that employees can reliably use.

How demanding is this work? In an engagement with a major semiconductor customer, AI was tasked with helping engineers generate chip tests, diagnose root causes of failures, and assist in understanding system architecture. Whether generated tests were actually useful and whether diagnosed failure causes were accurate had to be validated directly with the customer’s chip engineers. The team also had to wire up tooling, orchestrate model execution, and construct supporting harnesses for different use cases.

OpenAI deployed around 15 FDEs across more than 10 use cases. Some team members had no prior semiconductor background, requiring them to learn chip design while embedded within customer teams. It took an initial 3 to 6 months to bring all of these use cases into production and secure early user adoption. Debugging workflows that previously consumed weeks were compressed to hours.

Yet advances in Codex presented these engineers—who had just gotten everything working—with a new dilemma: If Codex can now effortlessly handle the use cases we spent months building, what do we do next?

They proceeded to let a more mature Codex take over earlier implementations, migrating individually developed applications onto a shared harness and ultimately eliminating roughly 90% of the custom code across related projects.

In the view of team lead Colin Jarvis, making their earlier work unnecessary is precisely what shows FDE got it right. Why would an engineering team view replacing the systems they labored to build as a mark of success?

The Deployment Gap: If the Model Can Do It, Why Can't Enterprises Run It Reliably?

Advances in model capabilities outpace the systems and workflows needed to deploy them into actual work. A model may perform brilliantly on standardized benchmarks, yet struggle with real-world variables and constraints once dropped into production business environments. The distance between what a model appears capable of doing and what people can reliably accomplish with it is what OpenAI calls the "deployment gap."

Agricultural equipment maker John Deere offers a clear illustration. Its See & Spray precision weeding technology uses cameras and machine learning to distinguish weeds from crops, spraying herbicide only where needed and cutting chemical usage by up to 70%. But realizing those savings still requires growers to properly calibrate equipment, plan planting seasons, and adjust operations as field conditions change.

John Deere used the OpenAI API to deliver personalized support to more growers: answering questions in natural language, offering situation-specific configuration advice, flagging when equipment might be underutilized, and helping farmers understand the value the technology delivers. Precision spraying cuts indiscriminate chemical use, while AI-powered support helps people actually put that technology to good use.

There is no standardized manual for this kind of work. At times, even the ground truth for evaluating output accuracy must be established collaboratively with the customer. FDEs must first clarify what business outcome is required, then diagnose whether the blocker stems from application-level software or the model's inherent limitations.

Outcome First: Deliver in the Field, Then Make Success Repeatable

Jarvis’s guiding principle for the team is straightforward: start from the desired outcome, do whatever work is necessary to achieve it, and then scale that success.

Chip verification checks whether a design functions as intended and can account for roughly 70% of an entire project's workload. Even a fractional time saving here carries substantial real-world value.

The team established business evaluations (Evals) with the customer, testing whether AI successfully completed tangible tasks rather than simply evaluating whether responses sounded plausible.

Execution harnesses constructed for each use case orchestrated model runs, tool calls, and result handling. OpenAI disclosed two tangible metrics:

• AI-assisted directed test generation saved approximately 48% of time.
• Compute kernel optimization delivered a median performance gain of 22%. (Compute kernels are low-level code routines that execute specific computational tasks.)

Teams blend generalists with domain specialists. In life sciences engagements, FDEs with scientific backgrounds can consult with researchers on preclinical target validation and prioritization, gene expression analysis, and chemical synthesis-route reconstruction, using those discussions to determine how workflows can be improved. Rapid learning and domain-specific judgment must both have dedicated owners.

Architectural Overhaul: Why Eliminate Roughly 90% of Custom Code?

Even when use cases demonstrated clear value, scaling remained difficult: each workflow required substantial custom integration, demanding considerable deployment and maintenance effort whenever extended to another team.

The original root-cause analysis architecture diagram illustrates the complexity at the time: a hypothesis-generation agent, an incident analysis agent, a specification expert, a code analysis agent, and an interactive triage agent worked together across logs, specs, and code, with specialized tools wired up at various points. The team had also written separate terminal UIs and command-line interfaces for different use cases.

As Codex's underlying capabilities expanded, an FDE experimented with rebuilding the application around it. The team subsequently migrated use cases onto a shared execution harness centered on Codex. Codex served both as the common execution engine and the primary user entry point, allowing the bespoke terminal UIs and CLIs to be retired.

Custom applications were decomposed into plugins and Skills running on the shared platform: reusable operating procedures were packaged into Skills, with corresponding functional capabilities delivered via plugins. The customer’s internal AI Center of Excellence (CoE—the team centrally managing enterprise AI capabilities) could then govern and distribute these capabilities uniformly.

MCP is a connectivity protocol designed to plug external tools into model applications. Specialized tools and specification experts in the diagram continue to participate through MCP, while codebases and task artifacts remain essential inputs to Codex. Architectural simplification does not mean industry expertise, specialized tools, or all expert agents vanish.

Centralized improvements to Codex flow downstream to these use cases, reducing the volume of bespoke glue code the team has to maintain independently.

Scaling still requires connecting to the systems a new team relies on and building fresh evals tailored to their tasks. The original account provides an example: an initial deployment took two months, but extending to a second team took just one day. This demonstrates the leverage of reuse, though it is not a guarantee that every subsequent project will deploy in a single day.

The team's upfront work to get into production was far from wasted: it helped validate which behaviors delivered value and which requirements were non-negotiable. As the underlying product progressed, custom scaffolding could be swapped out while the verified business value continued to reach users.

Is the Application Scaffolding Incomplete, or Can the Model Not Yet Do It?

The original text describes two distinct directions of work. When the model can already perform the task, FDEs partner with customer and product teams to make the solution easier to deploy and reuse; when the model cannot yet perform the task, they collaborate with the customer and research teams to articulate capability gaps and iterate until closed. In any given engagement, both dynamics may be intertwined.

Distilling Reusable Capabilities from Repeated Field Deployments

Presence, OpenAI’s enterprise voice and chat agent product, grew directly out of accumulated field experience. The lineage evolved from Swarm to the Agents API, and eventually crystallized into Presence: through live deployments, teams identified which problems required bespoke solutions and which foundational building blocks warranted broader distribution, sparing future developers from rebuilding the same scaffolding. OpenAI also disclosed that one customer is already handling over half of incoming calls with AI.

The Tax AI project developed with Thrive Holdings and its accounting subsidiary Crete also shows how professional practices translate into reusable methodologies. OpenAI FDEs and researchers worked side-by-side with engineers and accountants to construct the system. During the pilot, Tax AI processed 7,000 tax returns, driving a throughput increase of approximately 50%.

Within that project, rental property returns required six weeks of engineering effort and practitioner review to achieve 90% precision and recall. Precision tracks how many of the system's flagged determinations are accurate; recall tracks whether any items that should have been identified were missed. The source text does not detail which specific fields or determinations were scored in this evaluation, so 90% should not be interpreted as meaning an identical proportion of entire tax returns can run completely unattended.

Cracking that workflow established reusable patterns that made it easier for the team to expand into other complex tax schedules. The team is currently applying the same methodology across bookkeeping, auditing, and IT support. This case highlights how engineering and professional domain feedback compound together; available details do not permit attributing the challenge solely to either product scaffolding or model capability.

Real-World Business Evals Surface Model Shortcomings Directly to Research

Jarvis believes that if you only take on tasks existing models can already handle, it is difficult to identify what capabilities research teams need to build next. Consequently, many high-impact partnerships deliberately tackle unsolved problems beyond the model's current reach, driven jointly by the customer, FDEs, and Research.

Another major telecommunications customer already operated a customer support platform and wanted to expand into voice. Voice accounted for roughly 90% of its customer support volume, introducing stringent production requirements around accents, tone, latency, and accuracy.

During project scoping, the model scored roughly 60% on key evals, with function calling and instruction following needing substantial improvement. Function calling allows the model to trigger external tools required to complete business operations; if this step is unreliable, even a dialogue that sounds natural will fail to resolve customer inquiries.

FDEs laid out the capability gap to the customer and brought the research team directly into the engagement. The customer was willing to jointly push through unsolved territory; FDEs built the platform, specified the tasks the model needed to accomplish, and drove delivery; Research improved the model, supplying continuous fresh snapshots for the team to test against customer requirements.

Over six months, performance on key evals rose from roughly 60% to 80%, and ultimately surpassed 90%, meeting production standards. The resulting speech model not only powers this customer but also supports other bespoke customer care deployments and hosted Presence environments.

Here, field delivery served another vital purpose: crystallizing "the model isn't good enough" into concrete, testable, and iteratively verifiable problem statements. As research gains cycled back to the field for validation, challenges encountered by one customer helped smooth the path for those who followed.

When Is FDE Needed? Look at Customer Capabilities and Reuse Potential

OpenAI's case studies encompass both types of engagements: "the model can do it, but the solution is hard to deploy" and "the model cannot yet meet requirements." A single co-development case should not be misconstrued as a requirement that every FDE project must begin at the outer boundary of model capabilities.

Deciding whether your own organization needs an FDE team comes down to evaluating whether the customer can execute implementation independently, and whether modules built on-site can be reused across other clients. The site's FDE Selection Guide explores both questions in depth.

As Products Replace Custom Scaffolding, Keep Seeking Harder Problems

Jarvis favors choosing simpler architectures for most LLM development—provided they solve the problem reliably in the field. System complexity should be dictated solely by task demands.

Every collaboration ought to leave behind a better starting point for subsequent work: a product that is easier to deploy, a model capability equipped for harder tasks, or less custom engineering that needs to be reinvented from scratch.

Therefore, when Codex becomes capable of handling use cases that originally took months to build, teams do not need to cling to legacy scaffolding to justify their value. Lock in the validated outcomes, let the general-purpose product absorb what it is ready to shoulder, and move on to tackle the next harder problem.

Further viewing: Official OpenAI FDE Team Interview Replay, covering the team's day-to-day work, how customer feedback shapes product direction, and the skill sets best suited for the role. The official page requires login to view.