Introduction
OpenAI published Colin Jarvis's account of its forward deployed engineering team on October 22, 2026. It describes the distance between an impressive demonstration and a workflow people can depend on. The article concerns deployment practice, rather than a model launch or a standard small-business service package.
What the account describes
OpenAI describes working alongside customers to define outcomes, build repeatable systems and identify model capability gaps. It also describes replacing some custom applications with shared Codex components as those tools improved. These are OpenAI's accounts of its own engagements; their results do not establish a delivery schedule or expected saving for another company.
For a smaller project, the transferable question is what evidence allows a team to move from one stage to the next. A good answer in a chat is one artifact. A saved record, an authorized send and a recoverable failure each need different evidence.
What this means for a smaller project
Use an evidence ladder for a hypothetical service-enquiry reply assistant. The intended path is enquiry, draft, human review and approved reply. Each stage should have a concrete exit condition:
- Define the outcome: write a short task card identifying the reader, approved service information and prohibited commitments. Completion means the owner agrees what the assistant may prepare; it does not mean the integration is ready.
- Evaluate the draft: assemble fictional enquiries covering normal work, an unsupported service, a missing location and a requested date the business has not accepted. Keep expected responses and rejection reasons beside each case.
- Inspect the integration: follow one request from its source record into the review queue. Verify that the reviewer sees the original enquiry, draft, source-information version and unresolved questions together.
- Review the external action: require the approved content and destination to match the item being sent. A changed recipient or attachment should require another review under this proposed policy.
- Prepare the operating handoff: name who handles failed delivery, how to disable the integration and where unresolved enquiries remain visible. Preserve a manual reply route.
Keep an evidence record for the ladder: stage, artifact, check performed, result and remaining limit. A draft-only evaluation cannot be marked as a delivery test. A provider accepting a send request does not establish that the recipient received it.
One useful failure rehearsal is an interruption after approval but before delivery status is recorded. The expected response is to inspect the existing request and delivery state before retrying. The implementation needs a defined duplicate-prevention strategy and a visible unresolved state; simply asking the model to be careful is insufficient.
Keep the stage record with the operating handoff. It should make clear which checks passed, what remains unresolved and who owns the next decision.
Availability and limits
OpenAI's account is publicly readable. It does not publish standard engagement pricing or announce a self-service FDE package. Use it to frame implementation questions, then assess the selected products, access requirements and operating responsibilities for the actual project.
