OpenAI's current Seattle Forward Deployed Engineer posting describes an end-to-end contract: discovery, technical scoping, system design, build, production rollout, adoption, measurable workflow impact, and evaluation-driven product feedback. It also asks engineers to recognize risks, make delivery tradeoffs, write production-grade code, and codify working patterns into reusable tools or playbooks.
Current employer-controlled postings from Amari and Cartesia show the same broad shape in different environments. They connect technical discovery and customer-facing production code with integration architecture, staging and deployment safety, ambiguous requirements, complex infrastructure, rollout, failure resolution, and platform leverage.
A demo proves that you can construct the happy path. A deployment dossier makes the judgment around the path inspectable.
The seven links in a deployment dossier
1. Workflow truth
Name the operator, trigger, inputs, decisions, handoffs, exceptions, and outcome before showing the software.
2. Acceptance truth
Define the benchmark that separates an impressive output from a usable system: quality, latency, cost, permissions, review, or recovery.
3. System truth
Show data flow, identity, permissions, integrations, observability, human escalation, and rollback—not only the model call.
4. Failure truth
Expose failed eval cases, ambiguous inputs, stale data, dependency failures, partial writes, and operator confusion.
5. Adoption truth
Document onboarding, workflow fit, ownership, runbooks, feedback, and the signal that distinguishes durable use from a polite trial.
6. Learning truth
Show one decision that changed after evidence arrived. A flawless retrospective often hides the judgment the role needs.
7. Generalization truth
State what remains local, what became a documented pattern, and what deserves a reusable component or product request.
Turn a feature demo into an operating story
“I built an agent that summarizes support tickets” is a feature description. A deployment story explains that the operator needed to route urgent tickets without losing account context; the first benchmark missed entitlement and escalation facts; a failure-led eval forced a retrieval and citation change; and permission testing exposed an account-isolation problem before rollout.
The rollout then stayed human-in-the-loop until error classes were observable. The failure taxonomy became reusable, while routing rules remained local. The same project now reveals code, customer reasoning, evaluation, risk, rollout, and product judgment without pretending a side project equals a high-stakes customer deployment.
Build one dossier in six passes
- Choose a workflow with a real operator. Map the repeated task, exceptions, handoffs, sensitive data, and observable end state. If no operator is available, label the workflow as a hypothesis.
- Write the acceptance contract before building. Pick three to five conditions the system must meet and one explicit non-goal.
- Build the smallest complete production path. Cover identity, permissions, integrations, structured logging, failure handling, human escalation, and recovery for one workflow.
- Create a failure-led evaluation. Start with cases that would harm the user or invalidate the workflow, then record the threshold and what changed.
- Plan or run a bounded rollout. Name the initial user, exposure limit, stop conditions, operator, rollback path, and evidence required to expand.
- Package the evidence for inspection. Use a short index linking the workflow map, architecture, eval report, decision log, rollout plan, runbook, and local-versus-reusable note.
Be precise about the boundary of your proof
A project used only by you is not a production deployment. Call it a tested prototype. If there was no real operator, label the workflow assumptions. If reuse has not happened, call it a candidate pattern rather than platform leverage. Do not invent business impact, adoption, uptime, or customer approval.
Never disclose customer secrets, protected data, proprietary code, private performance metrics, or security details. Anonymized evidence or a safe independent project can still demonstrate disciplined discovery and production judgment.
A 15-minute hiring-team review
- Which workflow fact changed the build?
- Which production component did the candidate own?
- What separated acceptable from merely impressive?
- Which failure threatened the deployment?
- Which tradeoff protected the outcome?
- What showed adoption or bounded the adoption claim?
- Which decision changed after evidence?
- What stayed local, and what became reusable?
Weight the review against the actual role. A coding-heavy FDE, a deployment lead, and an integration specialist should not be scored as the same operating contract.
Sources and evidence limits
- OpenAI — Forward Deployed Engineer, Seattle
- OpenAI — Forward Deployed Engineer, Gov
- Amari — Founding Forward Deployed Engineer
- Cartesia — Forward Deployed Engineer
Sources were checked August 13, 2026. They are point-in-time employer evidence. The source set overrepresents AI companies and does not prove a universal FDE contract, hiring velocity, interview rubric, or portfolio requirement.
The FDE Brief
Get the next operator playbook.
Source-backed field notes for engineers and teams turning ambiguous workflows into stable production systems.
Reader question
Which part of your FDE story is hardest to prove?
Discovery, production code, evaluation, rollout, adoption, or reusable leverage—which evidence is missing?