Google's current Forward Deployed Engineer, Core, DevAI posting applies forward-deployed language to an internal boundary. The role partners with Google product areas, builds production agent workflows, codifies repeatable deployment patterns, and turns isolated agents, skills, and connectors into shared capabilities.
OpenAI's current Platform Engineer role inside Forward Deployed Engineering describes a complementary leverage function. Platform engineers embed with customer-tagged FDE pods to shape architecture, refactor and harden repeated patterns, and build reusable abstractions—while the pod keeps ownership of customer understanding and day-to-day execution.
Keep the outcome local until the workflow is proven. Move the repeated capability—not the unresolved problem—across the platform boundary.
The useful interpretation
Two job descriptions do not prove that every company needs a team called “internal FDE.” They do expose a reusable operating model: embed with a real team, prove a workflow under production constraints, identify what repeats, and return a hardened capability to more teams.
The title is less important than the boundary. Local ownership protects context and accountability. Platform leverage prevents every team from rebuilding the same connector, evaluation harness, guardrail, or agent primitive.
A six-step field-to-platform loop
- Name the local outcome. Define the workflow, user, failure cost, and success measure before discussing reuse.
- Embed through production. Build beside the operating team until permissions, data, latency, evaluation, and recovery are real.
- Collect repetition evidence. Require the same need or failure mode to appear in more than one context.
- Write the generalization contract. Separate stable interfaces and guardrails from team-specific policy and workflow detail.
- Harden with an owner. Add evaluation, observability, security boundaries, documentation, versioning, and long-term ownership.
- Return leverage without removing agency. Let teams adopt the capability while keeping responsibility for their own outcomes.
The promotion test
A local solution deserves platform investment when four things are true: demand repeats, the interface is stable enough to name, reuse creates measurable leverage, and a durable owner accepts the maintenance burden.
If any one is missing, keep learning locally. A platform team measured only by components shipped will generalize too early. An embedded team measured only by its immediate outcome may accumulate permanent one-offs. The promotion test gives both sides the same decision rule.
What this means for an FDE portfolio
Show both halves of the loop. Document one production workflow you owned locally, then show the connector, evaluation harness, guardrail, or abstraction you extracted from repeated evidence. The strongest artifact explains the boundary decision: what stayed local, what generalized, what evidence justified the move, and who owns it now.
Sources
- Google Careers — Forward Deployed Engineer, Core, DevAI
- OpenAI — Platform Engineer, Forward Deployed Engineering
- OpenAI — Forward Deployed Engineer, Seattle
Sources checked August 18, 2026. Compensation and market-size claims are intentionally omitted.
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 is your platform boundary?
Which deployment fix should stay local, and which repeated capability is ready to be shared?
