What FDE Means at OpenAI: From Impressive Demos to Dependable Production Systems
OpenAI's Colin Jarvis explains the deployment gap through semiconductor verification, Tax AI, telecom voice, reusable Codex primitives, and the research feedback loop.
Forward deployed engineering is not a polished demo team. Its job is to close the distance between what a model can appear to do and what an organization can depend on in production.
When Codex arrived, someone on Colin Jarvis's team asked a question that exposes the strange economics of applied AI: what happens when Codex can one-shot the use cases the team spent the past few months building? Jarvis is the head of Forward Deployed Engineering at OpenAI, and his answer is not to protect the old work. It is to treat obsolescence as evidence that the team is doing its job.
That question sits at the center of What FDE means at OpenAI, published on October 22, 2026. OpenAI's forward deployed engineers work beside customers, find the hardest problems inside the customer's actual workflow, and build something reliable enough to survive contact with production. Their field work also feeds Product and Research: repeated failures become product requirements, and problems that current models cannot solve become concrete research targets.
This is a different mandate from traditional solution consulting. The output is not a strategy deck or a proof of concept. The output is a system that works, a repeatable deployment pattern, and when necessary, a better model. The team's success condition is unusual: each engagement should leave the next customer with a better starting point. If a class of work becomes easy enough that the next customer no longer needs a forward deployed engineer, the previous engagement succeeded.
The deployment gap is an execution problem, not just a model problem
Jarvis founded the team in early 2025 to close what OpenAI calls the deployment gap: the space between apparent model capability and reliable use at work. Models can improve faster than the surrounding products, evaluation systems, integrations, and operating processes. A model may perform well on a benchmark and still fail when exposed to real variables, exceptions, organizational constraints, and consequences.
The gap has at least two forms. Sometimes the model already has the necessary capability, but the customer lacks the product and system around it. Sometimes the model genuinely cannot do the job yet. Treating those cases as the same problem produces bad outcomes: teams either keep prompting a model that has reached a hard limit, or they overbuild infrastructure for a capability that is about to become a product primitive.
OpenAI's operating rule is therefore to start with the customer's hardest problem, not with a preferred technology. If today's model can do the work, the forward deployed engineer, Product team, and customer make the solution repeatable. If it cannot, the engineer and customer define the missing capability with Research. Either way, the engagement must produce reusable knowledge for the next deployment.
Start with the outcome, not the demo
At the beginning of every team session, Jarvis shows a slide with a simple sequence: start with the outcome, do what it takes to succeed, then follow with scale. It borrows a useful idea from John Harrison's clocks. The H1 of 1735 established that the problem could be solved. The H4 of 1759 made the solution good enough to work in practice. Making something exist and making it dependable are separate achievements; a demo can celebrate the first while avoiding the second.
The customer example is John Deere. Its See & Spray system uses cameras and machine learning to identify weeds and spray them rather than treating an entire field. OpenAI says the precision approach can reduce chemical use by up to 70%. But the hardware alone does not create the benefit. Farmers still need to configure the equipment correctly, plan a season, and adapt their practices when field conditions change.
John Deere used OpenAI's APIs to provide more personalized, scalable support. A farmer can ask questions in natural language, receive setup guidance, get recommendations tailored to the situation, and find out when equipment may not be delivering its full potential. The important shift is from a single answer to guidance across the customer journey. That requires the model to work inside product knowledge and operating context, not just generate a plausible paragraph.
This is where the economic meaning of forward deployment becomes clear. The value is not that an AI can discuss precision agriculture. The value is that a farmer can make a better decision about a physical system under real constraints. The interface, evidence, recommendations, and escalation path all matter.
Production value is learned on the customer's ground
In mid-2025, roughly 15 OpenAI forward deployed engineers worked with a major semiconductor customer on more than ten use cases. The objective was to make verification AI-native. Verification can consume about 70% of a chip project's effort, so even small reductions in cycle time matter. The initial scope included directed test generation, root-cause analysis and debugging, and an architecture assistant.
Some of the engineers had joined OpenAI only days earlier and had never worked in semiconductors. They embedded with the customer's verification team, studied chip design outside working hours, and built evaluations with the customer's engineers. This was not a process of asking users for prompts. The team had to learn what a useful test was, how a failure should be diagnosed, and which result a chip designer could trust.
The custom harnesses reached production and early user adoption within the first three to six months. OpenAI reports that AI-based directed test generation saved about 48% of time, kernel optimization produced a 22% median performance improvement, and debugging tasks that once took weeks were compressed into hours. The Chief Hardware Officer's reaction, as quoted in the article, was to ask whether the engineers had previously worked as chip designers.
OpenAI's forward deployed engineers do not need to know the industry on day one, but they are responsible for learning it.
That distinction is important for every applied AI team. Domain expertise cannot be replaced by faster code generation. As coding assistants make implementation cheaper, understanding the customer's business becomes a larger fraction of the job. A team needs enough knowledge to make sound judgments and enough curiosity to challenge the current process rather than automate it uncritically.
OpenAI uses a mix of generalists and domain experts for this reason. In life sciences, engineers with scientific backgrounds can contribute to work such as target validation and prioritization, gene-expression analysis, and chemical synthesis-route reconstruction. Deep enough expertise lets them question how a workflow should change, not merely translate its existing steps into software.
Make success repeatable before trying to scale it
The semiconductor workflows demonstrated value, but each one still carried too much custom integration. That is a common failure point in enterprise AI: a strong first deployment becomes a collection of bespoke scripts, CLIs, prompts, and connectors that only the original team can maintain. The system works in the reference account and becomes harder to reproduce everywhere else.
As Codex became more capable, one engineer tested rebuilding an application around it. The team then moved the semiconductor use cases onto a common harness centered on Codex. Bespoke applications became plugins and skills built on shared Codex primitives. Codex also became the user interface, allowing the team to retire separate terminal interfaces and command-line tools written for individual use cases.
OpenAI says this removed roughly 90% of the custom code from each project. The result was not merely less code. Central improvements to Codex now reached every deployment. Shared skills and plugins made capabilities easier to distribute and let the customer's AI center of excellence govern them centrally. Extending a workflow to another team could become a matter of changing connectors or MCP servers, building evaluations for the new environment, and getting users started.
In one example from August 2026, the initial deployment took two months; extending the solution to a second team took one day. The article says later teams started even faster. This is the practical meaning of a reusable deployment: the expensive first engagement produces knowledge and primitives that reduce the marginal cost of the next one.
The order matters. Large language models make it possible to build quickly, but speed should first move a valuable system into users' hands. Production reveals which assumptions hold, which exceptions dominate, and which parts deserve to become platform capabilities. Only then does scaling preserve something real. Scaling a demo preserves the demo's weaknesses.
A deployment can become a product, and a product can change the next deployment
OpenAI Presence, its product for enterprise voice and chat agents, followed this path. It began with customer deployments and the open-source Swarm project, then evolved through the Agents API. OpenAI says one customer now handles more than half of its calls with AI.
Production deployments exposed which problems needed a custom solution and which pieces could be reused. Those reusable pieces became product infrastructure. Presence makes it easier for developers to automate regulated workflows without rebuilding the underlying system for each customer. Every deployment adds evidence to the next customer's starting point.
Tax AI, built with Thrive Holdings for Crete's accounting firms, offers another concrete example. OpenAI forward deployed engineers and researchers worked alongside engineers and accountants. During the pilot, Tax AI processed 7,000 tax returns and increased throughput by about 50%.
Rental-property returns were especially difficult. Automating that work required six weeks of engineering and practitioner review to reach 90% precision and recall. The result was not just one automated schedule. It created reusable patterns for extending Tax AI to other complex schedules. The team is now applying the same approach to bookkeeping, audit, and IT support, with practitioners feeding real-world corrections back into the system.
This is a more mature view of enterprise AI than the usual pilot-to-production funnel. A deployment is also an instrument for discovering the product. It finds the repeated integration work, the missing evaluation, and the control surface that customers actually need. Packaging those findings changes the cost structure of every future engagement.
When the model is the bottleneck, close the intelligence gap
Not every problem can be solved with better integration. If forward deployed engineers build only what today's models already make possible, they will never expose the capability gaps that Research needs to solve next. Some of the most valuable engagements therefore begin at the model's limit, with the customer, the forward deployed engineer, and Research sharing responsibility for progress.
A large telecommunications customer had already built a customer-service platform with OpenAI and wanted to add voice. Voice represented around 90% of its customer-service volume. Those interactions were more expensive to contain than chat, and accents, tone, latency, and accuracy raised the technical bar. Success would materially change the economics of the business.
During scoping, OpenAI's model scored around 60% on key evaluations for the production job. Function calling and instruction following in customer-service scenarios needed to improve. OpenAI explained the limit to the customer and brought Research into the work. The FDE team built the platform and defined the required behavior with the customer; Research worked on the model gaps. Successive model snapshots let the team test progress against the customer's actual requirements.
Over six months, performance on the key evaluations rose from around 60% to 80% and then above 90%, reaching the level required for production. The chart OpenAI published also shows Audio Big Bench accuracy rising across five model snapshots, from 65.6% in December 2024 to 92.29% in May 2026. The two measures should not be collapsed into one: one is the customer-specific production bar, while the other is a broader audio-reasoning benchmark.
The resulting voice model supports that customer's deployment, other custom customer-service deployments, and managed deployments through Presence. A problem found in one business became a capability that can serve many. This is the second kind of obsolescence: the customer no longer needs the original custom work because the underlying model has absorbed the hard part.
A compact reading of the evidence
The cases in the article differ in industry and maturity, but they share a pattern. The numbers below are the ones OpenAI reports; they are not normalized across customers and should not be treated as a universal benchmark.
| Case | Observed change | Time scale | What made it reusable |
|---|---|---|---|
| Semiconductor verification | About 48% less time for directed test generation; 22% median kernel-performance gain; weeks of debugging compressed to hours | 3-6 months to production | Customer-specific evaluations and a common Codex harness |
| Second-team rollout | Initial use case took two months; a second team took one day in an August 2026 example | 2 months to 1 day | Shared skills, plugins, connectors, MCP servers, and a reusable evaluation pattern |
| Tax AI pilot | 7,000 tax returns; about 50% higher throughput; rental-return automation reached 90% precision and recall after six weeks | Pilot and six-week hardest-case buildout | Practitioner feedback and patterns reusable across complex tax schedules |
| Telecom voice service | Key production evaluations rose from about 60% to 80%, then above 90% | 6 months | Customer-defined evaluation, an FDE-built platform, and Research improving the model |
Two caveats matter. First, these are supplier-authored case reports, not independent audits. The article provides useful operational detail and quantified outcomes, but not the underlying datasets, evaluation rubrics, failure rates, or full cost accounting. Second, the same team can report a high success rate on the cases it selected while selection itself remains invisible. The strategic lesson is still strong because multiple cases show the same mechanism: production evidence changes what gets built next.
What robotics and physical-AI teams should take from this
The following is RobotWorld's analysis, not a claim from OpenAI. Robots make the deployment gap harder in several ways. A language-model failure may produce a bad document; a physical-AI failure can damage equipment, stop a line, or create a safety event. The environment is partially observable, the hardware changes over time, and the data needed to evaluate a policy is expensive to collect.
That makes the FDE mindset more relevant, not less. A robot deployment cannot stop at a compelling teleoperation demo or a high score in a fixed simulation. The team needs to define the operational outcome, instrument the deployed system, and connect field failures back to model, data, integration, and workflow changes.
| Deployment stage | Question to answer | Evidence that earns the next stage |
|---|---|---|
| Zero to one | Can the robot complete the task at all in the target environment? | Repeatable task completion under representative perception, lighting, object, and operator conditions |
| Production | Can the system sustain the required rate and quality with safe recovery paths? | Cycle time, first-pass yield, intervention rate, failure taxonomy, recovery success, and uptime |
| Reuse | Which parts are specific to this cell, site, or fleet, and which are primitives? | Shared skills, adapters, telemetry schemas, simulation scenarios, and evaluation suites |
| Research feedback | Which failures are integration issues, and which are genuine capability gaps? | Field-derived evaluation sets that can distinguish a product fix from a model or policy improvement |
For robot-learning teams, the most useful idea in the article is the common harness. A single successful manipulation policy is valuable, but the reusable layer is the system around it: calibrated sensors, task specifications, failure capture, replayable episodes, simulation and real-world evaluations, deployment controls, and a way to distribute improvements across robots. Without that layer, every new customer site becomes another bespoke integration. With it, each deployment can raise the floor for the next one.
The second idea is that evaluation must encode the customer's real job. In semiconductors, that meant useful directed tests and correct failure diagnosis. In tax automation, it meant precision and recall on difficult returns. In telecom voice, it meant function calling and instruction following under production constraints. A generic benchmark can guide model selection, but it cannot decide whether a particular work cell or customer workflow is ready.
Go find the harder problem
Jarvis describes himself as motivated by making AI useful in everyday work. In an industry prone to hyperbole, the team's stated preference is for the simplest solution that works reliably. Occam's razor is not a slogan about model size; it is a discipline for deciding what must be custom, what can be packaged, and what should disappear as the platform improves.
The goal of each engagement is to improve the next one: a product that is easier to deploy, a model that can handle a harder task, or less custom work for the next customer. That is a better measure of forward deployment than the number of impressive demos produced.
So when Codex can handle the work that took months to build, the FDE does not defend the old implementation. The working system has become a primitive, and the team moves to the next unsolved problem. The same test applies to robotics: the best proof that a deployment worked is not that the original engineering team remains indispensable. It is that the next robot, line, or site can start from a higher floor.
Source: OpenAI, "What FDE means at OpenAI" by Colin Jarvis, Head of Forward Deployed Engineering, published October 22, 2026 (openai.com/index/forward-deployed-engineering-means). This bilingual article is a complete translation and adaptation of the source, with an explicitly labeled RobotWorld analysis section. All figures are from the original article.