What FDE Means at OpenAI: Forward Deployed Engineering and the Deployment Gap

OpenAI's Forward Deployed Engineering (FDE) team exists to close "the deployment gap" — the distance between what models appear capable of and what people can reliably use to do their work — and the team measures its own success by making itself obsolete as products and models improve. In a first-person post published on 2026-10-22, the team's founder explains how FDE engagements with customers such as John Deere, a large semiconductor manufacturer, a telecommunications company, and Thrive Holdings turn hard, unsolved problems into production systems, reusable Codex-based packages, and concrete capability gaps for OpenAI Research to close.

What FDE means at OpenAI, in one paragraph

Forward Deployed Engineering at OpenAI is the function that works alongside customers to understand their hardest problems and build solutions they can depend on in production. The team was founded in early 2025 to close the deployment gap: model capabilities have moved faster than the systems and processes needed to put them to use. Sometimes the missing piece is a product; sometimes a model performs well on a benchmark but cannot do the job with real-life variables and constraints. What FDE learns is fed back into OpenAI's products and gives Research concrete problems to solve.

The team's stated goal is that each engagement leaves the next customer with a better starting point. As the post puts it: "if we raise the floor to the point our customers don't need FDEs to solve this class of problem the next time, we have done our job well."

Why OpenAI says FDE work is supposed to become obsolete

The post opens with a question a colleague asked when Codex shipped: "What do we do when Codex can just one-shot the use cases we spent the last few months building?" The author's answer is that this is progress, not a threat.

If we make ourselves obsolete every couple of months, our FDE team is doing its job.

The post identifies two distinct ways the team makes itself obsolete. The first is when a better product lets OpenAI replace custom implementation while keeping the value it delivered. The second is when FDE helps turn a problem today's models cannot solve into a capability that future models can deliver.

The operating principle: start with the outcome

Every FDE team session opens with a slide carrying one core value: "Start with the outcome, do what it takes to succeed, then follow with scale." The rationale is that an impressive demo can go a long way before anyone asks whether it works in the real world, and that the team's job is to solve the customer's problem to a standard it can stand behind in production.

The post is blunt about why this is hard: the problems are often wide open, there may be no established ground truth, and there is no playbook. "Everyone wants to build something that has never existed. Fewer people want to do what it takes to get there."

Case study: semiconductor verification with ~15 FDEs on 10+ use cases

In mid-2025, around 15 OpenAI FDEs worked with a large semiconductor customer on more than 10 use cases, with the ambition of making the customer's verification process AI-native. Verification can account for roughly 70% of a project's effort in that industry. The work covered three areas:

• Directed test generation
• Root cause analysis and debugging
• An architecture assistant

Some FDEs had joined OpenAI just days earlier and had never worked in semiconductors. They embedded with the customer's verification team, studied chip design in their spare time, and built evals with the customer's engineers to test whether the AI could generate useful tests and correctly diagnose chip failures. Alongside that learning, OpenAI built custom harnesses for the individual use cases. Over the first 3–6 months, all of them reached production and early user adoption.

The reported results were:

• Approximately 48% time saved through AI-based directed test generation
• 22% median performance improvement through kernel optimisation
• Weeks of debugging compressed into hours

When the results were played back, the customer's Chief Hardware Officer asked, "Did you guys work as chip designers before coming here?" The post's conclusion: "Our FDEs don't need to know the industry on day one but it is their responsibility to learn it."

Domain expertise is treated as a hiring requirement, not a nice-to-have

The post argues that as coding assistants make software faster to build, understanding the customer's business becomes even more important. OpenAI builds FDE teams with a mix of generalists and domain experts, on the reasoning that you need enough knowledge to make sound judgments and enough curiosity to question assumptions about the status quo.

In life sciences, for example, FDEs' scientific backgrounds help them earn trust with researchers working on pre-clinical drug discovery tasks such as target validation and prioritization, gene-expression analysis, and chemical synthesis-route reconstruction. That expertise lets them contribute informed judgment about how those workflows could improve.

How FDE made success repeatable with Codex, skills, and MCP

Once the semiconductor workflows delivered value, each still required too much custom integration to extend to another team. The next challenge was to preserve the results while making the software easier to deploy and maintain.

By that point Codex had grown in capability. One FDE tested rebuilding their application around it, then worked with the team to move the use cases onto a common harness with Codex at its core. Custom applications became plugins and skills built on common Codex primitives. Codex also became the interface, allowing OpenAI to retire the separate terminal UIs and CLIs it had written for individual use cases.

The team was able to remove roughly 90% of the custom code from each project. According to the post, this changed how the workflows were built, maintained, and scaled in three ways:

• Centralized improvements to Codex reduced the amount of glue code required for each individual use case.
• Key functionalities were bundled as skills and plugins, making them easier to share and to be centrally controlled by the customer's AI CoE. Extending from one team to the next could be as simple as swapping in new connectors or MCP servers, building fresh evals (for which the team also had a skill), and getting up and running.
• Onboarding accelerated sharply. In one August 2026 example, the initial deployment took two months while extending the solution to a second team took one day.

The post summarizes the sequencing principle behind this: "LLMs let us build fast. Use that speed to get something valuable into users' hands, learn what holds up in practice, and then scale what works."

OpenAI Presence grew out of customer deployments

OpenAI Presence, the company's product for enterprise voice and chat agents, grew out of real customer deployments. The work began with Swarm and evolved through the Agents API. Today, one customer handles more than half of its calls with AI.

Getting those deployments into production taught OpenAI which problems needed a custom solution and which building blocks other teams could use. Those building blocks were brought into Presence, making it easier for developers to automate regulated workflows without rebuilding the underlying infrastructure.

Case study: Tax AI at Thrive Holdings processed 7,000 returns in pilot

With Thrive Holdings, OpenAI FDEs and researchers worked alongside engineers and accountants to build Tax AI for Crete's accounting firms. During its pilot, Tax AI processed 7,000 tax returns and increased throughput by about 50%.

One of the hardest challenges was automating rental-property returns, which required six weeks of engineering and practitioner review to reach 90% precision and recall. That work created reusable patterns that made it easier to extend Tax AI to other complex tax schedules. The teams are now applying the same approach to bookkeeping, audit, and IT support, building systems that improve through practitioner feedback and real-world use.

Case study: closing a voice-model intelligence gap from ~60% to 90%+

Sometimes a better product lets FDE simplify what it built; sometimes the model itself cannot yet do the job. The post argues that if OpenAI only built what today's models already make possible, it would not uncover the intelligence gaps Research needs to close next. Many important engagements therefore start at those limits, with the customer, FDE, and Research committed to working through them together.

A large telecommunications customer had already developed a customer-service platform with OpenAI and wanted to extend it to voice. Voice accounted for around 90% of that customer's customer-service volume, those cases were more expensive to contain than chat, and they brought new technical challenges in getting accents, tone, and latency/accuracy up to production grade.

During scoping, the model scored around 60% on the key evals used to assess whether it could do the job in production — the limits of its capabilities. Function calling and instruction following in customer-service scenarios needed to improve. OpenAI explained this to the customer and brought Research into the work: FDE built the platform with the customer and defined what the model needed to do, while Research worked on closing the capability gaps, with successive model snapshots letting the team test progress against the customer's requirements.

Over six months, performance on the key evals rose from around 60% to 80% and then to 90%+, reaching the levels needed for production. The post also cites Audio Big Bench accuracy rising across five model snapshots, from 65.6% in December 2024 to 92.29% in May 2026.

The resulting voice model now supports that customer's deployment, other custom customer-service deployments, and managed deployments through Presence. A problem encountered in one customer's business helped identify improvements that could serve many others.

What the FDE model implies for how AI gets deployed

The post draws a clear division of labor for hard deployments: the customer commits to working on a problem the model cannot yet solve, FDE stays close enough to frame that problem, build the platform, and drive the engagement from start to finish, and Research improves the underlying model capabilities. The return on that work extends beyond the hours spent with any one customer.

The author's stated engineering bias is toward simplicity: "in most cases in LLM development, Occam's Razor applies—the simplest solution is the best." In a company defined by cutting-edge research and an industry "tainted by hyperbole," the stated aim is to build things that work reliably and that people in the field can depend on.

The goal for each engagement is to improve what comes next — a product that is easier to deploy, a model that can handle a harder task, or less custom work for the next customer. And the answer to the question that opened the post is the post's closing line: when Codex can handle the work the team spent months building, "Go find the harder problem."