Daily · Article 03 · 5 min read
- OpenAI
OpenAI explains FDE the work between an AI demo and daily operations
Official article dated October 22 · rechecked after 06:00 JST October 23
Summary
OpenAI's October 22 article explains how its FDE team works alongside customers, tests whether AI can do a real job, and makes successful solutions reusable. A fictional returns desk shows the connections needed between a convincing reply and a completed task.
A shop owner shows AI a returns request, and it writes a pretty good reply. Can it take over the job now? Getting as far as returning the customer's money means connecting the work that happens outside that reply.
Key facts
OpenAI, which makes ChatGPT and the coding tool Codex, described its FDE team in an article dated October 22. FDE stands for Forward Deployed Engineering: engineers work with customers on difficult workflows and bring what they learn back to product and research teams. This is an explanation of enterprise adoption, rather than a new model release. October 22 article
Its business guide describes discovery, prototyping, evaluation, going live and expansion to other teams. It also says FDE typically isn't needed when existing AI capabilities already solve the problem. FDE business guide
1. A good reply still needs a working business behind it
An AI model is the part that produces language or judgments from the information it receives. A prompt is an instruction such as “write a friendly reply.” But a shop also needs order records, returns rules and authority to move money. Good writing alone doesn't tell it who bought an item or whether that order has already been refunded.
For the examples below, imagine a fictional online shop called Sora Shop. A customer writes, “I'd like to return the clothes I bought yesterday.” AI can write “I'll help with your return,” but completing the task means answering these questions.
| What the shop needs | What can go wrong without it |
|---|---|
| Connect the person asking to the order | Looking up someone else's order |
| Check the purchase date and returns rules | Promising a return the rules don't allow |
| Read previous refund records | Paying back the same order twice |
| Assign responsibility and approval | Nobody clearly owns stopping or correcting a mistake |
The cat asks Q&A
The researcherCouldn't I just put all that in a really long prompt?
Pocket NotebookYou can include the rules. Reading a recently changed order or issuing a refund also needs a connection to the actual business systems. You must decide who can access each record and action, too.
2. From looking up an order to issuing a refund
Sora Shop starts by letting AI read an order and draft a reply. An employee reviews it and approves the refund; the payment system carries out the transaction. A “tool” here means a connected function, such as looking up an order, that AI can request. The system's permissions and procedures must decide whether an action is allowed, even when AI proposes it.
If the order system is unavailable or the buyer can't be identified, this example hands the request to a person instead of pretending it is being processed. If the connection drops after the refund button is pressed, the workflow needs to check the transaction record before trying again. These failure cases belong in the job design too.
The cat asks Q&A
- The researcher
If someone still approves it, is much being automated?
Pocket NotebookSaving the lookup and drafting work can leave the employee more time for judgment. You don't have to hand over permission to move money at the start. Expand the scope according to the consequences of failure and the results of testing.
3. Testing more than “it seems to work”
An evaluation, or eval, compares results on tasks chosen to represent the work. OpenAI's evaluation guide recommends task-specific cases, human judgment and continued testing after changes. Evaluation design guide
Imagine a practice set for Sora Shop: 20 routine returns and 10 exceptions, including missing order numbers and orders already refunded. The following invented results illustrate the calculation; they are not measurements from running a product.
| Compare the same 30 cases | Draft A | Revised draft B |
|---|---|---|
| Correct replies on 20 routine cases | 19 | 18 |
| Correct handling or handoff on 10 exceptions | 4 | 9 |
| Total | 23/30, about 76.7% | 27/30, 90% |
The totals are (19 + 4) ÷ 30 for A and (18 + 9) ÷ 30 for B. B's overall result improves, but it gets one fewer routine case right. Look at the work that gets worse as well as the overall score. Errors such as exposing another person's information or refunding twice can be separate reasons to block deployment, even with a high average score.
The cat asks Q&A
- The researcher
B got 90%. Can we put it in front of customers now?
Pocket NotebookThese 30 cases aren't enough to establish that. Look at which three it missed and whether the results hold up on actual inquiries. Here, 90% compares two drafts; it isn't a passing grade.
4. What to keep when another shop adopts it
After building the first shop's workflow, how much must be rebuilt for the next? The order connection, permission checks and transaction records may be reusable, while return deadlines and exceptions may differ. Separating shared foundations from local decisions changes where the second deployment starts.
| Examples of reusable foundations | What the next shop must check |
|---|---|
| The pattern for connecting an order lookup | Data location, fields and access permissions |
| Approval and transaction logging | Who may approve which amounts |
| Tools for repeating inquiry tests | That shop's rules and real exceptions |
OpenAI's real example includes test generation and root-cause analysis for a semiconductor team: work such as writing tests to check whether a chip design behaves as intended. The company describes moving individual implementations onto a common foundation built around Codex. Field example
Those results don't give another company a reliable forecast of savings. For a small team like Sora Shop, a practical starting point is seeing whether existing tools can handle one bounded task.
The cat asks Q&A
- The researcher
Do we need an FDE contract before we can start?
Pocket NotebookNo, you can start with a small task existing tools can do. For example, generate return-reply drafts for staff to review, without permission to send them externally. Before using real customer data, check your organization's data rules and the tool's contract terms.
To close
What happens after the reply
At Sora Shop, an employee needs more than a report that AI wrote a friendly answer. They need a record of which order was checked, which rule was used and who approved the action. Designing AI into a job means carrying the workflow through to that next scene.
Sources
- Field exampleopenai.com
- FDE business guideopenai.com
- Evaluation design guidedevelopers.openai.com