OpenAI currently describes Forward Deployed Engineer roles in Tokyo and Seattle with a closely matched technical contract: discovery, technical scoping, system design, production build, adoption, and field-to-product learning.
The regional requirements are more concrete. The Tokyo posting requires Japanese and English fluency, includes interviews in both languages, and expects travel mainly within Japan. The Seattle posting requires travel up to 50 percent.
EY has also announced senior Forward Deployed Engineer roles in the UK and Ireland, placing technical builders inside regional client delivery teams. Together, these sources show the FDE label being used across regions. They do not prove that every global FDE team works the same way.
The stack can be standardized. The path from prototype to trusted workflow usually cannot.
A shared technical core, a local operating edge
The most useful interpretation is a two-layer role. The shared core contains the capabilities that keep deployments secure, observable, evaluable, and supportable. The local edge is where those capabilities meet the real language, workflow, authority, governance, and adoption behavior of one organization.
“Local” is not merely interface translation. It is learning how decisions, risk, and work move through a specific operating environment.
Global core
Identity boundaries, audit events, eval harnesses, telemetry, rollback mechanics, and reusable platform capabilities.
Local edge
Workflow sequence, domain language, approval path, human-review triggers, exception ownership, training, and adoption.
Product feedback
Repeated local constraints that have enough evidence to become configuration, documentation, tooling, or a shared capability.
This three-way classification prevents two expensive errors. Standardize every local detail and the platform becomes rigid. Customize every deployment and the FDE organization becomes a permanent one-off factory.
The six-step global-core / local-edge canvas
1. Map the workflow in the operator's language
Ask the people doing the work to narrate one recent case from trigger to resolution. Capture their vocabulary, trusted artifacts, handoffs, and exceptions. When the conversation crosses languages, confirm meaning with examples instead of assuming direct translation preserves the operating concept.
2. Draw the authority map
For each consequential action, identify who can request it, approve it, perform it, stop it, and reverse it—and who is accountable when it fails. Reporting lines rarely reveal the whole production authority path.
3. Define the global invariants
Name what cannot vary without unacceptable risk: identity and access, auditability, evaluation methodology, observability fields, incident handling, rollback, data handling, and minimum operator controls. Give every invariant an owner and a reason.
4. Name the local decisions
Record vocabulary, workflow order, approval thresholds, review triggers, exception owners, training, integrations, and in-person working moments in a decision register. Tie each choice to observed workflow evidence, policy, a failure case, or an accountable owner.
5. Test adoption as local behavior
“In production” is not an adoption measure. Test whether operators can use the system without the deployment engineer, explain an escalation, inspect and reverse an action, and resolve a known failure from the runbook.
6. Run the generalization review
Ask what was truly local, what exposed a hidden global requirement, and which constraint has repeated enough to justify configuration or product work. Produce at least one explicit keep-local decision. Knowing what not to generalize is part of good deployment judgment.
What this means for FDE careers
International readiness is not demonstrated by saying you are comfortable with travel and ambiguity. A stronger portfolio case preserves one technical invariant while adapting the operating design across two contexts.
- Keep the eval, audit, observability, and rollback core consistent.
- Vary approval ownership, domain vocabulary, exception thresholds, and operator training.
- State what you do not know and the discovery questions you would use to replace assumptions with evidence.
- Explain which difference should stay local and which repeated constraint might become a configurable product capability.
For bilingual and regionally experienced engineers, language matters when it improves discovery fidelity, prevents a technical failure, or enables real operator behavior. Make that consequence legible rather than treating fluency as a decorative resume line.
How to organize a global FDE team
Do not design a central engineering group with regional translators attached at the end. The local operator needs enough technical ownership to change the deployment plan when discovery reveals a real constraint.
But regional autonomy should not force teams to solve the same infrastructure, evaluation, and observability problems independently. Central teams can own minimum platform standards and shared harnesses; regional FDEs can own workflow evidence, representative eval cases, adoption behavior, and the packaging of repeated field constraints.
Sources and evidence limits
- OpenAI — Forward Deployed Engineer, Tokyo
- OpenAI — Forward Deployed Engineer, Seattle
- EY — EY launches Forward Deployed Engineer AI roles
These are employer-defined roles and requirements, not verified practitioner time studies. The comparison centers on two postings from one company, and it should not be read as a universal regional pattern.
The FDE Brief
Get the next operator playbook.
Source-backed field notes for engineers and teams turning AI prototypes into trusted production workflows.
Reader question
Where did the local workflow change the plan?
What looked standard from headquarters but became different once you worked with local operators?