OpenAI's FDE: Deploying AI in Production, Then Making Itself Obsolete

OpenAI's Forward Deployed Engineering (FDE) team, formed in early 2025 under Colin Jarvis, exists to close the "deployment gap" — the distance between what models can do in demos and what they reliably deliver in customer production environments. FDE engineers embed directly inside client companies, working alongside domain experts to move AI from "runs a demo" to "runs in production." The team's mandate has three modes: where the model can already do the job, make the solution repeatable; where the model falls short, define the gap and drive Research to close it; and after each engagement, raise the starting point for the next customer so that eventually FDE is no longer needed for that problem class.

Case Study: John Deere — Scaling Personalized Agronomy

John Deere, a 200‑year‑old agricultural equipment maker, needed to scale personalized advice to farmers. Its See & Spray precision‑weeding system uses cameras and ML to target herbicide only at weeds, cutting chemical use by up to 70%. However, value realization depended on farmers correctly configuring equipment, planning seasons, and adjusting to conditions. After integrating OpenAI's API, the AI assistant answers farmer questions in natural language, guides configuration, detects under‑utilized equipment, and helps farmers understand the value they are extracting — continuously across the entire customer journey.

Principle: Ship Results First, Then Scale

Jarvis gives the team a guiding principle: "make it work, then make it scale." He illustrates this with Harrison's marine chronometers: H1 (1735) proved the concept could exist; H4 (1759) made it practical. In mid‑2025, roughly 15 FDEs partnered with a large semiconductor manufacturer on 10+ use cases aimed at making chip verification AI‑native — covering directed test generation, root‑cause analysis and debugging, and architecture assistance. Verification consumes about 70% of project effort in that industry.

Several FDEs had joined OpenAI only days earlier and had no semiconductor background. They embedded with the client's verification teams, studied chip design on their own time, and co‑designed Evals (evaluation suites that judge whether AI output meets business requirements) and Harnesses (frameworks to run those evaluations) to measure whether AI could generate useful tests and correctly diagnose chip failures.

Within the first 3‑6 months, multiple scenarios reached production:

Directed test generation reduced time by ~48%.

Kernel optimizations delivered a 22% median performance improvement.

Debugging cycles that took weeks were compressed to hours.

At the retrospective, the client's chief hardware officer asked whether the team had prior chip‑design experience. Jarvis's response: FDEs don't need to know the domain on day one, but learning it is their responsibility. As coding speed increases, understanding the customer's business becomes the differentiator. The same pattern holds in life sciences, where FDEs with scientific backgrounds build trust with preclinical drug‑discovery researchers on tasks like target validation, gene‑expression analysis, and chemical‑synthesis route reconstruction.

Making Success Repeatable: Deleting 90% of Custom Code

Shipping to production is only step one. Jarvis breaks FDE work into three phases: (1) take an unsolved hard problem and build a zero‑to‑one solution; (2) when technical conditions mature, turn that solution into a reusable package; (3) as the underlying model (Codex) improves, migrate custom applications onto a shared Harness as Skills and plugins. Codex itself becomes the interaction surface, and the per‑scenario terminal UIs and CLI tools are retired.

In the semiconductor engagement, roughly 90% of the custom code was deleted. Three consequences followed: centralized improvements in Codex immediately benefit all use cases; critical capabilities are packaged as Skills and plugins governed by the customer's AI Center of Excellence, enabling easy sharing across teams; and expanding to a new team requires only swapping connectors and MCP servers, then generating a new Eval with a Skill — the first deployment took two months, the second team was up in one day.

Jarvis calls this "making yourself obsolete" — the work done to reach production defines what actually matters; once the base product is strong enough, most custom implementation can be swapped out while the value remains. The sequence matters: LLMs let you build fast, so deliver value quickly, learn what survives contact with reality, then scale.

The ability to delete 90% of the code is itself a goal: continuously reduce others' dependence on FDE. A community observation captures the mechanism: Evals that cleanly define the boundary give confidence to refactor; adding negative cases to the regression suite makes deletion faster. Previously, deletion was risky because regression suites only covered happy paths. Code can retire, but the lessons learned (the pits fallen into) must not be forgotten.

What persists in enterprise agent projects are the Evals, the failure cases, and the business knowledge distilled into Skills. Glue code written to compensate for model gaps should be re‑examined on every model upgrade and deleted when possible. If every new client still requires writing a fresh stack from scratch, the work has not yet graduated from bespoke application to reusable capability.

Filling Capability Gaps: Driving Model Improvements from Production Pressure

Sometimes the blocker is not that the product can be simplified, but that the model simply cannot do the task yet. Only by pushing on problems the current model fails at does the team discover what Research needs to tackle next.

With a large telecom client that already had a text‑based support platform, the goal was to expand to voice — which carries ~90% of support traffic and is more expensive, with challenges in accents, prosody, latency, and accuracy. Initial evaluation on critical benchmarks scored ~60%; function‑calling and instruction‑following were insufficient. FDE built the platform and defined model requirements; Research closed capability gaps; each model snapshot was tested against the client's real needs.

Over six months, the key Eval score rose from ~60% to 80%, then to 90%+.

That voice model now powers the telecom deployment, other custom support deployments, and Presence's hosted deployments. One customer's production pressure yielded improvements that serve many. Jarvis frames this as another form of "making yourself obsolete": turning a problem today's model cannot solve into a capability tomorrow's model can deliver — a return far exceeding the time invested in any single client.

OpenAI Presence and Tax AI: Reusable Patterns from Real Deployments

OpenAI Presence, the enterprise voice and chat agent product, grew directly out of real customer deployments. Starting from Swarm, evolving through the Agents API, it now handles over 50% of inbound calls for some customers. Each production deployment reveals which problems truly need custom solutions and which building blocks are reusable. Those blocks are folded into Presence so developers can automate regulated workflows without rebuilding infrastructure. Every deployment shapes the product, giving the next customer a better starting point.

Tax AI, built with Thrive Holdings for Crete accounting firms, processed 7,000 tax returns during pilot, boosting throughput ~50%. The hardest challenge was automating rental‑property tax returns — six weeks of engineering plus practitioner review to reach 90% precision and recall. The reusable patterns left behind now accelerate expansion to other complex tax forms, and the same method is being applied to bookkeeping, audit, and IT support, with the system continuously improving from practitioner feedback and real usage.

Go Find Harder Problems

Jarvis repeatedly tells the team that in LLM development Occam's razor usually applies — the simplest solution is best. Despite the company's cutting‑edge research reputation and an industry full of hype, the goal is systems that run reliably in human hands. Every engagement must either make the product easier to deploy, make the model handle harder tasks, or reduce the custom code the next customer must write.

The article concludes with a single answer to the opening anxiety: go find harder problems. FDE is essentially human scaffolding — temporary assistance while AI is not yet strong enough. As one commenter noted, being able to delete code proves the architecture has truly solidified. Another asked what the team spent months writing if 90% gets deleted; the answer: they wrote the understanding of business boundaries, which ultimately became Evals and Skills.

For anyone doing enterprise AI adoption, the article is a reference on what in FDE is durable versus temporary. Only with that boundary can accumulation happen. If you are still writing a fresh stack for every new client, you are stuck at the bespoke‑application layer and haven't yet distilled reusable assets.

Original article: https://openai.com/index/forward-deployed-engineering-means