Internal FDE vs Customer-Embedded FDE: The Delivery Contract

“Forward Deployed Engineer” can describe work that feels similar at the keyboard: sit with users, map a workflow, build a narrow capability, make it reliable, and leave the next team stronger. The operating contract can still be very different.

Proposed method: the delivery-context card below is FDE Brief editorial synthesis, not a universal taxonomy or a claimed company process. Its purpose is to name the decisions that a title cannot answer before an operational rollout expands.

Why the title is not enough

Crunchyroll’s current Forward Deployed Engineer posting, checked October 15, 2026, describes embedding with teams across Crunchyroll, mapping real workflows, building AI solutions with users, transitioning successful work to a long-term owner, and creating reusable components. Anthropic’s current Forward Deployed Engineer posting describes embedding with strategic customers, working in customer systems, supporting enterprise deployment, delivering technical artifacts, and identifying repeatable patterns for Product and Engineering. OpenAI’s current Deployment Lead, Semiconductors posting likewise describes embedded customer delivery, workflow mapping, adoption, and packaging field signals.

These are current employer-authored role descriptions, not proof of a universal model, hiring volume, delivery outcomes, or that either form is better. They support a narrow observation: internal work and vendor/customer delivery can require different explicit answers about acceptance, access, ownership, and what is safe to generalize.

The five-question delivery-context card

Question	Record before scope expands	Why it matters
Who receives the outcome?	The internal business team or external customer team using the workflow.	A buyer or executive sponsor may not be the workflow beneficiary.
Who accepts or rejects the release?	A named person or forum with authority to decide that the bounded use is useful enough to expand.	A demo audience is not necessarily the acceptance authority.
Which environment governs the work?	Systems, data, access controls, integrations, and change rules.	Cross-organization work must not assume vendor access to customer infrastructure.
Who owns it after handoff?	A long-term operator, maintenance path, and person who can stop or revise the workflow.	“The FDE team” is rarely a durable operating answer.
Where does learning go?	An internal enablement pattern, customer artifact, product request, reusable integration, or documented exclusion.	A local success is not automatically reusable in another context.

Classify the engagement as internal, customer-embedded, or mixed. If it is mixed, name which decisions stay internal and which sit with the customer. A prototype may proceed while a field is unresolved; an operational rollout should not quietly rely on an unassigned acceptance, access, or maintenance decision.

Worked fictional example: two claims-triage assistants

Everything in this example is fictional. Two teams deploy the same narrow assistant: it drafts a claim-triage summary from approved case notes and leaves the final decision to a human reviewer. Both test retrieval, build an evaluation set, and add a human checkpoint.

The contract changes the delivery work

Internal FDE: an operations team inside the company receives the outcome; an operations director accepts it; the company’s identity, data, and IT teams govern access; a named operations-systems owner inherits it; and the AI Enablement group decides whether it becomes an internal pattern.
Customer-embedded FDE: a customer claims team receives the outcome; a customer-side workflow owner accepts it; agreed access and change channels govern the work; the customer owns the decision process and ongoing operation; and field learning remains a customer-specific record until evidence and permissions support broader reuse.

The scenario is not a model recommendation, a customer case study, or a claim about the cited companies. It illustrates why a vendor should not silently inherit a customer’s operating responsibility—and why an internal deployment still needs durable handoff.

Run the card before the work expands

Fill the five fields in one page. Use names or roles, not departments alone.
Find the missing owner. Treat an unassigned acceptance, access, or maintenance decision as a hold condition for operational expansion.
Match the artifact to the contract. Internal work prioritizes organizational adoption and shared enablement; customer-embedded work includes customer acceptance, approved change paths, and support boundaries.
Separate reusable learning from a reusable promise. Label the result local, candidate pattern, or documented exclusion.
Reopen the card when the boundary moves. Update it for a new customer, data source, integration, post-handoff owner, or release authority.

What to ask in an interview or hiring review

For candidates, a stronger question than “Is this customer-facing?” is: “Whose workflow am I accountable for improving, who accepts the outcome, and who owns it after I leave?” A credible FDE story distinguishes the engineering and coordination work you performed from authority held by a workflow owner, platform team, product partner, or customer.

For teams, publish the delivery contract early. A role description that says “embed” without explaining internal versus external users can create mismatched expectations about access, travel, support, stakeholder authority, and success measures.