How OpenAI defines FDE: consolidating customer-customized Harness into a unified Codex

Turning customer-customized Harness into a unified Codex: How OpenAI defines FDE

OpenAI's FDE has to fill the gap of "deployment gap": the gap between what the model appears able to do and what customers can reliably use under real constraints. The approach is to first get results into production, then turn customized solutions into reusable products; if the model itself is not sufficient, use evaluations to hand the gap to Research. The goal is to make itself less necessary on such problems every few months. https://t.co/X1E2WtaMbe

What OpenAI's FDE does · The team was founded in early 2025. The deployment gap is sometimes a product gap, and sometimes the model looks good on benchmarks but cannot do it under real variables and constraints. · After Codex was released, some asked: we spent months on use cases; when Codex can handle them with one click, what will FDE still do? The author's answer is: that is progress; if every few months you make yourself "obsolete," it shows FDE is doing its job.

Start from outcomes · Core principle: "Start from the outcome, do everything needed to succeed, then talk about scale." A demo is not enough; it must stand up in production. · Semiconductor customer case (around mid-2025, about 15 FDEs, 10+ use cases): make the verification process AI-native, covering directed test generation, root cause analysis and debugging, and architecture assistant. In the industry, verification can account for about 70% of project workload. Some FDEs had only been onboard a few days and had never done semiconductors, yet embedded in the customer's verification team, self-taught chip design, and built evaluations with engineers. Within 3–6 months, use cases went live one after another; self-reported results include: directed test generation saved about 48% of time; median performance improvement in kernel optimization was about 22%; debugging compressed from weeks to hours. · The author emphasizes: you are not required to know the industry on day one, but you are responsible for learning it; the team should mix generalists and domain experts. In life sciences, FDEs with research backgrounds gain trust more easily in workflows such as target validation and gene expression analysis.

Make success reusable (core!) · Early on, every use case required a lot of customized integration and was hard to replicate to the next team. After Codex became stronger, some first tried rebuilding the application on Codex, then pushed use cases to migrate to a unified harness centered on Codex. · Custom applications became plugins / skills based on Codex primitives; Codex itself became the interface, and the terminal UI and CLI originally written for each use case were retired. Self-reported results: about 90% of custom code per project was removed. Benefits include: benefiting from Codex's centralized improvements and writing less glue; capabilities packaged as skills / plugins, easy to share and centrally governed by the AI CoE; when expanding to the next team, often only connectors / MCP need to be swapped and new evaluations added (evaluations also have a skill). · Scaling example: a use case in August 2026, the first team deployed in about 2 months; the second team in about 1 day. Subsequent teams continued to get faster.

Close the loop when intelligence gaps appear · Sometimes a product upgrade can simplify customization; sometimes the model itself still cannot do it. If you only do what today's model can already do, you cannot uncover the next problem Research should tackle. · Telecom customer service voice case: voice accounts for about 90% of customer service volume. At project start, the model was at about 60% on key evaluations. FDEs co-built the platform with the customer and defined requirements, and Research used continuous model snapshots against customer requirements to fill capability gaps. After about six months, key evaluations went from about 60% to 80%, then to 90%+, reaching a deployable level. The results fed back into that customer's deployment, other customer service customizations, and Presence managed deployments.

Other productization examples · Presence (enterprise voice and chat agent) grew out of real deployments: from Swarm to Agents API; one article says more than half of one customer's calls are already handled by AI. · Thrive Holdings / Crete tax AI: the pilot processed about 7,000 tax returns, with throughput improved by about 50%. Automating tax filing for rental properties took about six weeks of engineering and practical review to reach about 90% precision / recall; the pattern was then reused for bookkeeping, audit, and IT support.