Closing the gap between a model and dependable work
OpenAI has published a detailed account of its forward deployed engineering team, which works beside customers on difficult production problems. The group was created in early 2025 to address what OpenAI calls the deployment gap: the distance between a capability demonstrated by a model and a system people can rely on in everyday operations.
That distinction is important. A benchmark or polished demonstration can show that a model sometimes performs a task, while production requires repeatability, access controls, error handling and evidence that the result serves a business outcome. OpenAI says each engagement should improve the starting point for the next customer, either through a reusable product, a stronger model or less custom work.
Outcome-led work replaces technology-first pilots
The team begins with the intended result and then builds the evaluations, integrations and operating process needed to reach it. In one semiconductor engagement, roughly 15 engineers worked across more than 10 verification use cases, including directed test generation, root-cause analysis and architecture assistance.
OpenAI reports about 48 per cent time saved through AI-based directed test generation, a 22 per cent median performance improvement through kernel optimisation and debugging work compressed from weeks into hours. These are company-reported customer outcomes, so other organisations should reproduce the measurement method against their own baseline before treating the figures as transferable.
Codex turned bespoke applications into shared building blocks
As Codex improved, OpenAI rebuilt several custom applications around common primitives. Separate terminal interfaces became plugins and skills, while connectors and Model Context Protocol servers supplied customer-specific access. OpenAI says this removed about 90 per cent of the custom code from each project.
The company gives an example where an initial deployment took two months but extension to a second team took one day. That is a meaningful scaling pattern if the shared harness preserves the original controls and evaluations. Reuse should not mean copying permissions, prompts or acceptance thresholds into a department with different data and consequences.
Customer problems also direct model research
Forward deployment is not limited to packaging capabilities that already work. OpenAI describes a telecommunications voice project where initial performance was around 60 per cent on key evaluations. FDE, the customer and researchers refined the platform and the model until results passed 90 per cent, according to the post.
This feedback loop can make product development more grounded, but customer-specific data and failures need careful governance. Organisations should know what operational evidence can be used for research, how it is de-identified and which improvements become generally available rather than remaining a private advantage.
Practical value depends on disciplined replication
Other examples include personalised guidance for John Deere customers and a tax workflow that processed 7,000 returns while increasing throughput by about 50 per cent during a pilot. The tax team reportedly spent six weeks reaching 90 per cent precision and recall for rental-property returns before reusing the pattern elsewhere.
The lesson is less about immediate autonomy than about deliberate iteration. Domain experts define what counts as correct, engineers expose real constraints and researchers close model gaps. Organisations considering this model should budget for the embedded learning and evaluation work, not only the final interface that users see.
Production checks
For implementation, teams should record the exact model, software, connector and policy versions behind every result. Representative evaluation must include normal work, boundary cases, deliberate misuse and component failure, with outcomes separated by user role, data sensitivity and consequence. A strong average should never hide a serious failure in a critical path. Changes should pass the same regression set before promotion, and operators need a documented fallback that preserves evidence rather than silently broadening access or lowering quality.
Procurement should account for the human work required to review exceptions, maintain controls and investigate incidents. Published performance or economic claims are useful starting points, but production confidence comes from evidence collected in the organisation’s own environment. A named owner, measurable acceptance threshold, cost model and tested shutdown path turn a promising release into a service that can be governed over time. Where decisions affect safety, rights, money or regulated records, accountable professional review remains essential.
Security review should map every identity, credential, network destination, stored artefact and administrative access path involved in the workflow. Logs need enough context to reconstruct who initiated an action, which evidence was consulted, what the system proposed and what ultimately executed. Sensitive prompts and traces should not be retained merely because they are useful for debugging. Retention, redaction and access must follow the underlying data classification, with a practical process for correcting or removing material when policy or law requires it.
Operational monitoring should measure quality and service behaviour together. Latency, throughput and availability matter, but so do unsupported claims, missed constraints, unsafe tool calls and the rate at which people overturn recommendations. Teams should rehearse dependency outages and partial failures before unattended operation. If a model, connector or external service becomes unavailable, the workflow should fail predictably, preserve its state and tell the user what remains unfinished. Clear degradation is safer than an agent improvising around a missing control.
Finally, organisations should publish the scope and limitations of the deployed capability to the people affected by it. Users need to know when automation is involved, how to challenge an outcome and where a human can intervene. That transparency improves feedback and prevents a pilot result from being interpreted as blanket approval for broader autonomy. Expansion should follow demonstrated evidence, not novelty or pressure to match a competitor announcement.