Michael JohnsonOn October 22, OpenAI published an account of FDE’s work—the work of its forward-deployed engineering team, which adapts AI to specific processes alongside enterprise customers. Colin Jarvis, who leads the group, explains how engineers study a customer’s work, agree on quality criteria, and turn individual solutions into reusable components.
That is how the company describes the gap between a model’s performance on a test prompt and a system’s ability to reliably perform a task in a real-world environment. When the bottleneck lies in the product or integration, the team refines the solution with the customer; if the model cannot meet the task’s requirements, OpenAI researchers join the work.
From a customer problem to a measurable result
In one example, dating to mid-2025, about 15 OpenAI engineers worked with a large semiconductor manufacturer on more than ten use cases: generating directed tests, finding the causes of failures, and assisting with design. According to the company, the use cases reached production and early use within the first three to six months. OpenAI reports saving about 48% of the time spent generating tests and reducing debugging from weeks to hours.
These figures relate to the specific customer processes described by OpenAI. The method itself is relevant to deployment: agree on success criteria with practitioners in advance, gather real cases, and measure the outcome of the entire workflow, including human review.
Reuse instead of one-off integrations
The initial solutions for the manufacturer required a lot of custom code. OpenAI writes that, when it rebuilt the applications around Codex, it replaced individual interfaces with shared tools, plugins, and skills. The company estimates that this reduced custom code by about 90% for each project described. In an example from August 2026, the first deployment took two months, while onboarding a second team took one day.
For an in-house pilot, it is useful to track the effort for the initial deployment separately from the effort to onboard the next department. If connectors, instructions, and quality checks can be reused, transferring the solution may require less custom development. The timelines cited by OpenAI describe its specific example, not a guaranteed pace for every project.
From a customer pilot to a tax product
Another OpenAI example is Tax AI for accounting firms Crete, developed in partnership with Thrive Holdings. According to the company, the system processed 7,000 tax returns during a pilot, and throughput increased by about 50%. One challenging use case—returns for rental properties—required six weeks of engineering work and specialist review to reach 90% accuracy and completeness in identifying information.
OpenAI writes that the resulting templates later helped expand Tax AI to other complex tax schedules. To evaluate such a pilot in practice, consider not only the share of correct results but also the amount of manual review, processing speed, and the work needed to transfer the solution to the next document type.
When to change the integration and when to change the model
In a separate project with a large telecom operator, the team developed voice support. According to OpenAI, the system initially scored about 60% on key internal tests that assessed whether the use case was ready for production. The score rose to 80% over six months, then exceeded 90% after deployment engineers, the customer, and the research team worked together. OpenAI attributes the improvement to testing speech recognition, instruction following, and function calling in customer-service scenarios.
This process helps determine where work is needed: in the integration and interface, or in the model’s ability to perform the specified function. OpenAI describes its internal evaluations and customer projects; these results show how it organizes deployments, not a universal forecast for other customers.
What to check in your pilot
Before expanding a deployment, document the baseline process, the amount of manual review, and the acceptance criteria. Test the system on real cases, including rare errors, and measure time to an accepted result, the rate of corrections, and the cost of maintaining the integration. When transferring it to another team, compare the same metrics and separately calculate the effort to connect data sources and configure access.
OpenAI’s account offers a practical guide: start with a measurable task, test the solution under real working conditions, and build components so the next deployment can draw on the previous one. That is what connects an individual pilot to repeatable deployment.