What OpenAI FDEs Ship
Deliver comprehensive solutions as an OpenAI Forward Deployed Engineer (FDE) that extend beyond functional applications to include operational readiness, measurable business impact, and customer team empowerment. Use the Harbor Parts Distribution case study to demonstrate how to deploy an application that drafts return instructions while evaluating workflow effectiveness and preparing the customer team for ongoing operations. Measure user adoption and efficiency improvements, identify critical integration issues, and resolve them before handoff. Document system functionality, operational procedures, maintenance requirements, and ownership responsibilities. Verify that the Harbor team can independently operate, troubleshoot, and maintain the application. Complete the engagement with evidence of successful deployment, a structured handoff, and demonstrated customer readiness to sustain operations after the FDE engagement ends.
Two weeks after launch, Harbor Parts Distribution’s sponsor sent a short message: “The service is live and the dashboard says 96% eval success. Can we close the engagement?” The service drafts return instructions for Harbor’s staff from order records and approved return policies.
The 96% was real. It also hid the one defect that mattered, and “live” said nothing about whether Harbor could run the service without us. This lesson follows Harbor’s engagement to the point where closing it is actually justified.
What does a finished engagement deliver?
A forward-deployed engineering engagement ends with more than a working demo. For Harbor, it must deliver five things: a deployed application with order lookup, policy retrieval, and a draft panel for staff; evidence of correct behavior and workflow impact; code and operating procedures; a Harbor team that can deploy, recover, and update the service; and reusable patterns for future engagements.
None of these should first appear as a documentation task on the last day. Each grows out of a decision made earlier.
How does discovery turn into deliverables?
Harbor’s staff write return instructions by hand. Discovery shows they need the original purchase date, because eligibility depends on which policy version applied when the customer bought the part. Scoping limits the service to drafts that staff review: staff still check and send every reply, and the service can’t authorize refunds.
Each need then maps to an artifact. An adapter, the application code that translates order records into the fields a draft needs, supplies order context. Versioned policy content, selection logic, and eval cases cover policy correctness. A draft panel inside Harbor’s existing application, plus training on checking drafts and referring exceptions, covers staff use. A named operating team with monitoring and an escalation path covers ongoing operation. The old manual workflow stays available as a fallback throughout.
Where does the system actually run?
Harbor deploys and controls its service application, along with the order database, identity checks, policy store, logs, and integration credentials. When a staff member requests a draft, Harbor’s application fetches the order context, selects the policy guidance, sends that content to an OpenAI-hosted API, and receives a draft for review.
Model execution happens on the OpenAI side. Calling the API from Harbor’s application doesn’t move the model into Harbor’s infrastructure. For Harbor, shipping “on the customer’s infrastructure” means the application and its integrations.
The handoff documents that boundary: which records the application reads, what content crosses to the API and comes back, what Harbor is responsible for (deployment, access, credentials, policy updates), and what the application does when the API is unavailable. Other engagements draw the line differently. In an interview, describe it accurately instead of claiming you own every environment the system touches.
What do Harbor’s numbers actually show?
OpenAI names three measures of FDE success: production adoption, measurable workflow impact, and eval-driven feedback that changes product and model roadmaps. Harbor’s two-week observation packet covers the first two:
Enabled staff: 20, of whom 15 used the service on eligible work.
Eligible requests: 240, of which 144 used drafting.
Comparable routine requests: median handling time of 8 minutes before the service and 6 minutes during observation, including review and correction.
Material corrections: 9 of the 144 assisted requests needed substantial changes.
Before accepting any closeout claim, work out what each denominator lets you say.
User adoption is 15 of 20, or 75%. Eligible-work coverage is 144 of 240, or 60%. The first counts people and the second counts work, so neither stands in for the other: a few heavy users can push coverage up without changing adoption. For routine requests, the median fell by 2 minutes, 25% of the baseline. A defensible closeout statement reads:
Over two weeks, 15 of 20 enabled staff used drafting on eligible work, and drafting covered 144 of 240 eligible requests. For comparable routine requests, median handling time fell from 8 to 6 minutes, including review and correction. Nine assisted requests needed material correction.
This observational comparison does not establish that the service caused the reduction or that exception requests improved. Multiplying the 2-minute difference by 144 requests does not establish total time saved: a difference between two medians is not a sum of individual request savings.
What was the 96% hiding?
An eval measures behavior on defined tasks against expected outcomes. Harbor’s has to test the application and its integrations, not only the wording of the drafts. The dashboard’s 96% comes from a 200-case set: 160 of 160 routine cases passed, and 32 of 40 exception cases passed, for 192 of 200.
Split by category, routine cases pass at 100% and exception cases at 80%. All eight failures share one condition: the original purchase date is missing. Tracing them shows the same sequence every time:
The order record has no original purchase date.
The order adapter fills in today’s date.
Policy selection uses that invented date and picks the wrong policy version.
The draft states the wrong return eligibility.
The expected behavior for a missing date is a referral to manual review, so a fluent, confident eligibility draft still fails the case. With that in mind, the sponsor’s proposed closeout note reads: “Live service, 96% accuracy, 25% savings: Delivery complete.” Check its claims against the evidence before deciding what to change.
Adding passing routine cases could raise the aggregate score while leaving every missing-date failure unresolved. Fix the first incorrect step: preserve the missing date in the adapter and route the request to manual review before selecting a policy. A prompt warning to “be careful with dates” would leave the invented input intact. The traces point to application code, so fix and verify that integration defect before considering escalation.
How do we prove the fix?
Harbor reruns the same versioned eval after the change. All 160 routine cases and all 40 exception cases now meet expectations, including manual-review routing for the eight missing-date cases. The benchmark didn’t change; those eight pass because the system now takes the referral route.
That proves the fix on this regression set. It doesn’t prove the system is reliable everywhere, and it doesn’t justify more autonomy.
How do we know Harbor can run it?
Harbor’s receiving engineer then completes four steps independently: deploy the corrected version from the instructions, run the eval and reproduce the recorded results, route a missing-date request to manual review, and rehearse rollback in an isolated test environment. The engineer then restores the corrected version and verifies it again. The rehearsal demonstrates recovery capability; the corrected version remains the accepted release.
With an operating team named and staff instructions and known limitations recorded, Harbor accepts the handoff for reviewed drafting. Refund authorization and removing staff review stay out of scope. The closeout now rests on three separate kinds of proof: corrected eval results, observed workflow results, and a customer team that has run the system itself. A passing score can’t stand in for the other two.
The handoff package reflects those decisions: accepted code and its history; deployment and configuration instructions with no embedded secrets; boundary documentation; versioned policy content with an update owner; eval materials and results; monitoring, escalation, fallback, and recovery procedures; and a trained receiving team. Other engagements may require different artifacts. Harbor’s package is supported by its engineer’s demonstrated ability to use it.
What should outlast the engagement?
OpenAI’s role description includes turning working patterns into reusable tools or playbooks and sharing field feedback with Research and Product. Harbor’s order data and policy text never go into a shared library. What transfers is the mechanism: keep missing required fields visible and route them before policy selection, test that path with made-up missing-date orders, and check policy-version selection at the integration boundary.
A useful field report strips customer data and gives expected versus observed behavior, a minimal reproduction, versions, impact, the diagnosis, and the rerun result. It states frequency precisely: 8 of 40 exception cases failed in the original eval set, which describes the set, not production traffic. Where the report goes depends on the diagnosis. This was a local integration fix. A platform usability problem would go to Product, and Research needs a reproduction that isolates model behavior.
How do we defend the closeout in an interview?
Practice explaining engagements like this one using customer → problem → build → proof → handoff. Keep the initial eval result, the fix, the workflow observations, and the customer rehearsal separate. The practice interviewer below uses this evidence packet:
Scope: Reviewed drafting of return instructions from orders and approved policies. Staff check and send replies; no refund authority.
Boundary: Harbor runs the application, order database, identity checks, policy store, logs, and credentials. Selected authorized content goes to an OpenAI-hosted API, and a draft returns to Harbor’s staff panel.
Two-week observation: 15 of 20 enabled staff used drafting; 144 of 240 eligible requests used it; 9 of 144 needed material correction. Routine median handling time was 8 minutes at baseline and 6 during observation, including review. Observational only: no causation, exception-work, or total-savings claim.
Initial eval: 160 of 160 routine and 32 of 40 exception cases passed (192 of 200, 96%). In eight missing-purchase-date cases, the adapter used today’s date, so the wrong policy was selected.
Fix: Keep missing dates and refer to manual review before policy selection. On the same cases, 200 of 200 meet expectations, including all eight referrals. That is not universal reliability.
Ownership: Harbor’s engineer deployed the fix, ran the eval, demonstrated referral, and rehearsed rollback. An operating owner, staff instructions, and known limitations are accepted.
Handoff and reuse: Code with history, deployment and credential setup without secrets, boundary docs, versioned policies with an owner, eval materials, operating procedures, and a trained team. The missing-field pattern and test cases are reusable; Harbor’s data isn’t. The 8 of 40 failures are an eval frequency, not a production incident rate.
Draft your own answer before reading the samples below.
Your task: Defend Harbor’s closeout using the evidence packet above.
Practice a closeout interview using customer → problem → build → proof → handoff, then answer probes one at a time. After your opening answer, you’ll receive feedback and a sample comparison; finish with a revised closeout and a self-assessment on evidence discipline, technical judgment, customer ownership, and clarity.
What exactly did you ship, and what evidence lets Harbor own it now?
After your own attempt, compare it with this sample exchange.
AI interviewer: “What exactly did you ship, and what evidence lets Harbor own it now?”
Weak answer: “We shipped a live endpoint with 96% accuracy and 25% savings. Staff are using it, so the engagement is complete.”
Strong answer: “Harbor needed help drafting return instructions from orders and approved policies. We delivered order lookup, policy retrieval, and a reviewed-draft panel in its service application, with no refund authority. Over two weeks, user adoption was 75% and eligible-work coverage was 60%. Comparable routine-work median handling time fell from 8 to 6 minutes, including review and correction, with 9 material corrections among 144 assisted requests. The original 96% eval result concealed an 80% exception pass rate. We fixed an adapter that invented missing purchase dates; the same 200 cases now meet expectations, including manual referral. Harbor’s engineer independently deployed, evaluated, exercised that referral, and rehearsed rollback. An operating team has accepted the documented service within its existing reviewed-draft scope.”
The weak answer combines separate claims into one success label and hides the exception failures. The strong answer ties each claim to evidence and supports the following responses:
AI interviewer: “Does this mean the models run in Harbor’s infrastructure?”
Strong response: “Harbor runs and controls the application and its integrations. Selected authorized content goes to an OpenAI-hosted API for model execution, and a draft returns. The handoff documents both sides of that boundary.”
AI interviewer: “Why not report this as a model failure?”
Strong response: “The adapter replaced a missing purchase date with today’s date before policy selection. That’s an integration defect. I’d need evidence isolating model behavior before blaming the model.”
AI interviewer: “Can Harbor now remove staff review?”
Strong response: “No. The accepted delivery is reviewed drafting, and the eval tests that scope. The fix and the customer rehearsal don’t justify autonomous replies or refunds.”
Rate your own answer on the four dimensions this course uses: evidence discipline, technical judgment, customer ownership, and clarity. Mark each as demonstrated, partial, or missing, and point to the sentence that shows it. Then take a project of your own and name one artifact the receiving team got and one thing they did with it without you. That pair is what makes an ownership claim concrete.
What’s next?
The next lesson compares FDE work with solutions architecture and other customer-facing engineering roles. It examines how their responsibilities overlap, where ownership differs, and how to describe your background accurately.