OpenAI Forward Deployed Engineering: How FDE Closes the Deployment Gap

OpenAI has published a long description of what its Forward Deployed Engineering (FDE) team does, written by Colin Jarvis, who founded the team in early 2025 and leads it. The short version: FDEs embed with customers on hard problems, get a solution into production, then turn what worked into Codex skills, plugins and products, and send what did not work to Research. OpenAI's own phrase for the target is the deployment gap, "the distance between what models appear capable of and what people can reliably use to do their work."

The post, What FDE means at OpenAI, is unusual because it comes with concrete numbers from named deployments. This article summarizes them, separates what OpenAI claims from what outsiders can check, and explains what it means if you build with or hire for AI. For the role itself, see our earlier explainers on the forward deployed engineer as the hottest tech role and what a frontier deployed engineer is.

TL;DR: OpenAI's FDE playbook

What is the deployment gap?

A bridge spanning a gap, illustrating the OpenAI forward deployed engineering deployment gap between models and real work

Jarvis argues that model capability has moved faster than the systems and processes needed to use it. Sometimes the missing piece is a product. Sometimes a model scores well on a benchmark but cannot handle the variables and constraints of a real workflow. That second case matters: it is why vendor benchmark charts and production reality diverge, a theme we track in our FDE-Gym benchmark coverage, where frontier models solved only a small share of realistic forward-deployed tasks.

OpenAI's FDE answer has two branches. Where models can already do the job, FDEs work with Product and the customer to make the solution repeatable. Where they fall short, FDEs and the customer define the gap precisely and hand it to Research. The stated aim is that each engagement leaves the next customer a better starting point.

Principle one: start with the outcome

Jarvis puts one value on a slide at the start of every team session: "Start with the outcome, do what it takes to succeed, then follow with scale." His warning is that an impressive demo can go a long way before anyone asks whether it works in the real world. The job is to reach a standard "we can stand behind in production."

The semiconductor example

In mid-2025, around 15 FDEs worked with a large semiconductor customer on more than ten use cases, aiming to make chip verification AI-native. Verification can account for roughly 70% of a project's effort in that industry, according to the post. The use cases included directed test generation, root cause analysis and debugging, and an architecture assistant.

Several FDEs had joined days earlier and had never worked in semiconductors. They embedded with the verification team, studied chip design on their own time, and built evals with the customer's engineers to test whether the AI could generate useful tests and diagnose chip failures. Custom harnesses were built per use case. Within three to six months all of them reached production and early adoption.

OpenAI reports about 48% time saved through AI-based directed test generation, a 22% median performance improvement through kernel optimization, and weeks of debugging compressed into hours. Jarvis says the customer's Chief Hardware Officer asked whether the FDEs had worked as chip designers before. His point: engineers need not know the industry on day one, but learning it is their responsibility, and as coding assistants make software faster to build, understanding the customer's business matters more.

Domain experts on the team

The team mixes generalists with domain experts. In life sciences, FDEs with scientific backgrounds work on pre-clinical drug discovery tasks such as target validation and prioritization, gene-expression analysis and chemical synthesis-route reconstruction. The post frames this as the knowledge needed to make sound judgments and to question assumptions about the status quo.

Principle two: make success repeatable with Codex

An enterprise rollout scaling from one team to many, showing how FDE work moves onto shared Codex skills

The most useful section for builders is about what happened next. Each semiconductor workflow worked, but each needed too much custom integration to extend to another team. By then Codex had grown in capability, and one FDE rebuilt their application around it. The team moved use cases onto a shared harness with Codex at the core.

• Custom applications became plugins and skills built on common Codex primitives.
• Codex became the interface, so the separate terminal UIs and CLIs written per use case were retired.
• Roughly 90% of custom code was removed from each project.
• Centralized improvements to Codex reduced glue code, and bundled skills could be shared and centrally controlled by an AI center of excellence.

Extending to a new team became a matter of swapping connectors or MCP servers, building fresh evals (the team has a skill for that too) and starting. OpenAI gives one August 2026 example where the first deployment took two months and the second team took one day, with later teams onboarding faster.

If you work with agent harnesses, this is the pattern to copy: keep domain logic in portable skills and connectors, keep evals as first-class artifacts, and let the platform carry the rest. Our coverage of Codex as an open agent platform and our guide to agent skills go deeper on the mechanics, and the MCP primer explains the connector side.

Customer deployments that became products

Jarvis says OpenAI Presence, its product for enterprise voice and chat agents, grew from real deployments. The work began with Swarm, moved through the Agents API, and today, the post says, one customer handles more than half of its calls with AI. See our OpenAI Presence launch coverage for the product itself.

The Thrive Holdings example is about accounting. FDEs and researchers worked with engineers and accountants to build Tax AI for Crete's accounting firms. In the pilot it processed 7,000 tax returns and raised throughput by about 50%. Rental-property returns were the hardest case: six weeks of engineering and practitioner review to reach 90% precision and recall. The patterns were reusable for other tax schedules, and the teams are now applying them to bookkeeping, audit and IT support.

A third example, John Deere, is lighter on numbers. OpenAI says Deere used its APIs to give farmers personalized setup guidance and recommendations for its See & Spray weed-control technology, which the post says can cut chemical use by up to 70%. No adoption metric for the AI layer is given.

Principle three: close the intelligence gaps

Sometimes a better product lets the team simplify. Sometimes the model itself cannot do the job. Jarvis says many important engagements deliberately start at those limits, with the customer, FDEs and Research committed to working through them.

The case study is a large telecom customer that wanted to extend a customer-service platform to voice. Voice made up around 90% of its customer-service volume and was more expensive to contain than chat. During scoping, OpenAI's model scored around 60% on the key production evals, with function calling and instruction following in customer-service scenarios as the weak spots. FDEs built the platform and defined what the model needed to do, while Research worked on the capability gap, testing successive model snapshots against the customer's requirements. Over six months the evals rose from around 60% to 80% and then above 90%, the level needed for production.

The resulting voice model now supports that customer, other custom customer-service deployments, and managed deployments through Presence. This is the second version of "making ourselves obsolete" in Jarvis's words: turning a problem today's models cannot solve into a capability future models can. It also connects to OpenAI's voice work such as GPT-Live-1 for voice agents.

What is claimed and what can be checked

Every figure above comes from OpenAI's own post. We could not find customer-side confirmations for the percentages, and the post does not name the semiconductor or telecom customers. Treat the numbers as vendor-reported case studies, useful for the shape of the work rather than as benchmarks.

Why it matters for people who build with AI

First, it shows where a frontier lab thinks enterprise value is made: not in the model alone but in evals, harnesses and domain knowledge around it. Second, it is a sign that the labs are competing on embedded engineering, a pattern also visible in Databricks deploying GPT-6 Astra across 3,500 engineers and in Anthropic's Claude Frontier Academy. Third, the Codex consolidation story suggests custom agent code written today may be deleted by platform features tomorrow, so invest in evals and connectors that survive the swap.

What to do if you want the job

Jarvis's hiring signals are consistent: pick the hard problem, learn the customer's business, favor simple solutions ("Occam's Razor applies"), and build things people can depend on, in an industry he calls "tainted by hyperbole." Our FDE preparation guide, interview questions and analysis of how the role reshapes work cover how to prepare. Practice building evals first; it is the skill the post repeats most.

Limits and open questions

• The post is a recruiting and positioning piece as well as a description, and ends with an invitation to work with or join the team.
• No cost data is given: how much FDE time, and at what price, did the semiconductor deployment need?
• The 90% custom-code reduction measures lines removed, not effort saved overall.
• It is not stated how many customers got FDE support versus self-serve, or how the team scales.

The closing line of the post is the thesis: when Codex can handle the work you spent months building, "go find the harder problem."

Related reading

• Forward deployed engineer: the hottest tech role
• What is a frontier deployed engineer?
• FDE-Gym benchmark
• Codex as a platform
• OpenAI Presence
• Databricks and GPT-6 Astra
• Official: OpenAI, What FDE means at OpenAI and Codex developer docs

Details are accurate as of October 22, 2026, and come from OpenAI's published post. Figures are vendor-reported.