What Is an FDE? Accountability for the Outcome Chain

Reading boundary: This chapter separates official facts, the FDE working framework, and claims that still require field evidence. The framework is not an industry certification or compliance standard.

1. One-sentence definition: start with accountability

Forward Deployed Engineer, Forward Deployed Software Engineer, Applied AI Architect, and Solutions Architect are used differently across companies. A title does not prove end-to-end ownership, and forward deployed work can exist under another title.

Handbook working definition, not an industry standard:

An FDE is an engineering role with end-to-end technical delivery ownership: under the real workflow, data, permission, and operating constraints of a customer or internal business team, the role carries a selected problem from discovery to stable production, real adoption, and measurable outcomes, leaving reviewable evidence that can be handed over.

The definition requires three things:

1. Work inside real constraints. The role enters the workflow, data boundary, permission model, systems, and operating environment.
2. Maintain delivery continuity. The responsibility does not stop at a proposal, prototype, or launch event; it connects production, adoption, outcomes, and transfer.
3. Prove delivery with evidence. A good demo or positive feedback is not enough to close the project.

Outcome-chain accountability does not make the FDE the sole owner of business results or the approval authority for security, legal, privacy, data, or operations. The role is accountable for delivery state, technical trade-offs it can control or drive, continuity of ownership, and completeness of evidence.

2. What current official sources show

Official fact: All dynamic sources in this section were checked on July 19, 2026.

• OpenAI’s current SF FDE role explicitly owns discovery, technical scoping, system design, build, and production rollout. It also covers delivery from prototype to stable production, adoption, feedback loops, and reusable patterns.
• OpenAI’s Deployment Company describes field work that connects models to customer data, tools, controls, and business processes to deliver measurable results.
• OpenAI Frontier describes FDEs working side by side with customer teams on production agent practices and feeding field signals back into research and product.
• Palantir’s current FDSE role combines user problem decomposition, engineering, end-to-end execution, and product feedback around a commitment to outcomes. Its 2019 Dev-versus-Delta article describes Delta’s mandate as technical outcomes measured by impact on customer goals.
• Anthropic’s Services Track distinguishes a successful pilot from a system a business can actually run, while its agent guidance recommends increasing complexity only when needed.
• Anthropic’s current Applied AI Architect role spans discovery, architecture, evals, integration patterns, and deployment guidance while remaining a pre-sales role. Adjacent titles can therefore overlap heavily with FDE work.

Handbook working definition: These sources support a delivery-centered synthesis. They do not establish a universal industry standard or validate this handbook’s five-layer evidence framework.

3. The outcome chain

Handbook working definition: The five gates below translate the official facts into a project review model. No cited company publishes this exact shared process.

Enterprise AI projects often compress several states into the phrase “we launched.” This chapter separates five delivery gates:

State	Question the FDE must drive	Minimum evidence	Insufficient substitute
1. Valid problem	Who has what loss in which workflow, and why act now?	Real users, workflow, baseline, volume, sponsor, owner, stop conditions	An executive slogan; “build an agent”
2. Valid production system	Can it operate with real data, permissions, integrations, and failures?	Representative evals, interfaces, permissions, release, rollback, audit, operating owner	A curated demo; temporary credentials
3. Real adoption	Do target users repeatedly use it in normal work and know when to review or reject it?	Usage, task completion, human review, drop-off, user feedback	Feature availability; one training session
4. Measurable outcome	Did quality, cycle time, cost, risk, or revenue change against the baseline?	Comparable metrics, denominator, observation window, limitations, side effects	“The business liked it”; one strong example
5. Transfer or continued operation	Who runs, evaluates, responds, updates, and decides whether to expand or stop?	Operating owner, test set, SLO, runbook, drills, transfer acceptance or renewed responsibility	Sending documentation; permanent dependency by default

The FDE does not need to perform every task. The role must make sure each gate has an owner, a decision condition, and reviewable evidence.

4. Role boundaries: inspect ownership, not a bundle of skills

Handbook comparison framework: The table describes common centers of gravity, not fixed definitions across all companies.

Use four dimensions to compare FDE work with adjacent roles:

1. Does responsibility begin with an ambiguous problem in the real workflow?
2. Does the role directly build or make critical production engineering decisions?
3. Does it own a delivery state across evals, integration, adoption, and operations?
4. Does it turn field learning into product feedback, reusable assets, or transferable capability?

Role	Common center of gravity	Boundary to verify
Product engineer	A reusable product for a class of users	Whether the role also owns one customer’s complete outcome chain
Solutions engineer, architect, or applied AI architect	Discovery, architecture, prototype, advice, sometimes deployment	Whether the role owns production implementation, operating evidence, and adoption; this varies widely
Implementation or professional services	Configuration, integration, migration, and launch within a defined scope	Whether the role may challenge problem selection, change the product, and own outcomes beyond scope completion
Customer success	Adoption, value realization, relationship, and renewal	Whether the role owns deep engineering delivery and production decisions
Technical program manager	Plans, dependencies, risks, and coordination	Whether the role owns architecture, implementation, and quality gates
FDE	High-value, field-specific work connecting problem, engineering, production, adoption, and feedback	Whether the role has authority, exit conditions, and a reuse mandate rather than unlimited customization

When an adjacent role owns all four dimensions, it is performing forward deployed work regardless of title. When an FDE title only covers demos, requirement relay, or indefinite onsite support, the title alone does not prove outcome-chain ownership.

5. Outcome accountability needs authority boundaries

Area	What the FDE should drive	Final approval or long-term owner
Business problem and success criteria	Reconstruct workflow, establish baseline, define measurable results and stop conditions	Business sponsor, process owner, acceptance authority
Technical delivery	Choose the minimum viable approach and drive implementation, evals, integration, rollback, and feedback	FDE plus platform, application, data, and operations teams under an explicit RACI
Data, privacy, and security	Expose gaps, design least privilege, and prepare validation evidence	Data owner, security, privacy, legal, and authorized decision makers
Adoption and workflow change	Put the system into real work and observe usage and failure	Process owner, team managers, and users
Operations and transfer	Define SLOs, incident response, test ownership, and handoff conditions	Named operating team or continuing service owner

An FDE can be accountable for delivery state and controllable decisions. The role cannot sign on behalf of authorities it does not hold or guarantee strategic, policy, or revenue outcomes outside project control.

6. Five layers of delivery evidence: a handbook framework

Handbook framework, not an industry standard: The five layers below are proposed for editorial review, project self-assessment, and future peer review. They are not an OpenAI, Palantir, Anthropic, standards-body, or certification framework.

Layer	Question	Typical artifacts
1. Problem evidence	Is the problem real, material, measurable, and owned?	Users, workflow, baseline, volume, loss, sponsor, owner, stop conditions
2. Solution evidence	Why this approach, under which constraints, versus what alternatives?	Architecture decisions, data and tool boundaries, option comparison, assumptions, risks, cost estimate
3. Quality evidence	What quality and risk level justify controlled production?	Representative cases, failure modes, graders, thresholds, permission tests, regression, known limitations
4. Operational evidence	Does the system run reliably and serve real users?	Release, rollout, SLOs, latency, cost, usage, human review, incidents, recovery, escalation
5. Outcome and transfer evidence	Did the original problem improve, and who can continue the work?	Comparable outcomes, observation window, side effects, ownership confirmation, drills, expand or stop decision

Layers 1-2 support discovery and solution validation. Layer 3 may support a controlled launch. Layer 4 proves operation, not automatically business impact. Claims about delivered outcomes and transfer require Layer 5.

The handbook’s separate E0-E4 scale rates the evidence behind published content and cases. It is not the same as these five project-delivery layers.

7. China context: six field questions instead of one stereotype

Hypothesis requiring field evidence: The six questions below are a delivery-screening framework. They are not industry statistics or universal claims about China enterprises.

There is no single China enterprise environment. State-owned enterprises, financial institutions, manufacturers, internet companies, smaller firms, and multinational operations differ substantially. Before delivery begins, the project should answer six questions:

1. Who authorizes, funds, owns, and accepts the result?
2. Who owns the data, processing purpose, access, retention, and deletion decisions?
3. Where will the system run, and how do cloud, private deployment, isolated networks, endpoints, and third-party model APIs change the design?
4. Which security, legal, privacy, audit, and sector requirements create approval gates?
5. Do procurement, vendor onboarding, IP, SLA, acceptance, and change terms support iteration?
6. Who owns adoption, model and rule changes, evals, incidents, and cost after launch?

Official fact: These dates and scope statements come from official legal and regulatory texts. Authorized specialists must still determine applicability for a specific project.

China’s Personal Information Protection Law was adopted on August 20, 2021 and took effect on November 1, 2021. The Data Security Law was adopted on June 10, 2021 and took effect on September 1, 2021. The Interim Measures for Generative AI Services were published on July 13, 2023 and took effect on August 15, 2023; Article 2 distinguishes public-facing services from internal research and application not offered to the public.

Projects should neither apply one filing or deployment conclusion to every internal AI system nor assume that internal use removes data, privacy, security, and audit obligations. This chapter is a delivery-screening guide, not legal advice.

An internal technical lead may perform FDE work without the title. The relevant test is whether the person has enough authority to cross organizational boundaries and is accountable for the outcome chain and its evidence.

8. Illustrative example: expense-package preparation, not “build OCR”

Hypothesis requiring field evidence: This is a framework example, not a verified success case.

Evidence layer	Project question
Problem	Where do time and returns occur when finance checks invoices, travel, approvals, and attachments? What is the baseline volume?
Solution	Should the system combine rules, OCR, policy retrieval, model judgment, and human confirmation?
Quality	How are field accuracy, package completion, missing-item recall, severe error, and launch thresholds defined?
Operations	Are permissions, audit, latency, unit cost, fallback, and peak capacity acceptable?
Outcome and transfer	Did cycle time, returns, review effort, and adoption improve, and who owns rules, tests, and exceptions?

The difference from an OCR demo is not necessarily more code. It is one accountability structure connecting problem, production, adoption, outcomes, and transfer.

9. When an FDE is unnecessary, and when the project is not ready

Handbook judgment requiring validation: These conditions are project-routing criteria that still need calibration against different real engagements.

9.1 Usually unnecessary

• The workflow is standardized and a mature product covers the important cases.
• Data, permissions, interfaces, deployment, and ownership are already clear.
• Users can validate value and reach production through self-service or ordinary implementation.
• Failure impact is low and the work does not require complex tool execution, continuous evals, or cross-functional governance.
• The customer team can deploy, operate, and improve the system independently.
• Project value, product learning, and reuse potential do not justify high-touch delivery cost.

A standard product, implementation team, or conventional engineering team is usually a better fit.

9.2 Potentially valuable, but not ready

• There is no business sponsor, process owner, or acceptance authority.
• The team cannot access real users, data, systems, or failure records.
• Stakeholders demand a build while refusing baselines, launch gates, or stop conditions.
• The project expects the FDE to bypass security, legal, procurement, or data approvals.
• No team will own operations, evals, and incidents after launch.

Individual skill cannot compensate for an organization that refuses ownership. FDE work has leverage when four conditions exist together: an important outcome, material field uncertainty, cross-boundary engineering work, and sufficient organizational authority.

10. Conclusion and reader action

Ask four questions before asking whether someone has “FDE” in the title:

1. Did they enter the real workflow rather than receive a polished requirement?
2. Did they move the system through eval, data, permission, integration, and operating constraints?
3. Did they measure adoption and outcomes rather than stop at launch?
4. Did they leave evidence that another team can review, operate, and inherit?

The chapter’s core proposition is:

An FDE is not a universal customer engineer. It is an engineering role accountable for technical delivery across the outcome chain, continuity of ownership, and completeness of evidence.

Write a one-page project accountability statement covering:

• the real user and workflow;
• baseline, volume, and cost of failure;
• sponsor, process owner, technical owner, and acceptance authority;
• minimum production outcome;
• quality gates, risk boundaries, and stop conditions;
• adoption and outcome observation window;
• long-term owner for operations, evals, incidents, and change;
• date for the expand, maintain, change, or stop decision.

Then mark each evidence layer as Missing, Planned, Observed, Verified, or Not publishable. The gaps are more useful than the title.

---

Sources and Evidence Boundaries

Current Primary Sources

1. Forward Deployed Engineer (FDE) - SF, OpenAI official dynamic job page. Publication date not shown; checked 2026-07-19 and open at time of review. Supports full-lifecycle technical delivery, adoption, field feedback, and reuse; it is one current role sample.
2. OpenAI launches the OpenAI Deployment Company, OpenAI. Published 2026-05-11; checked 2026-07-19. Supports field integration across customer data, tools, controls, and business processes, and the path to measurable results; it is one company’s deployment model.
3. Introducing OpenAI Frontier, OpenAI. Published 2026-02-05; checked 2026-07-19. Supports side-by-side production agent practices and a field-to-research-and-product feedback loop; it describes the Frontier product and service model.
4. Forward Deployed Software Engineer, New Grad - Commercial, Palantir official ATS dynamic job page. Publication date not shown; checked 2026-07-19 and open at time of review. A single entry-level commercial role sample.
5. Dev versus Delta: Demystifying engineering roles at Palantir, Palantir. Published 2019-04-08; checked 2026-07-19. Supports the historical framing of Delta around technical outcomes and impact on customer goals; it is not a current job description.
6. Introducing the Services Track and Partner Hub, Anthropic. Published 2026-06-03; checked 2026-07-19. Supports the distinction between pilots, production customers, customer success, and capability development; it is a partner-program framework.
7. Building effective agents, Anthropic. Published 2024-12-19; checked 2026-07-19. Supports minimum necessary complexity, not a definition of FDE.
8. Building a new enterprise AI services company, Anthropic. Published 2026-05-04; checked 2026-07-19. Supports hands-on implementation and long-term support as a current enterprise AI services pattern; it does not publish operating results for the new company.
9. Applied AI Architect, Industries, Anthropic official ATS dynamic job page. Publication date not shown; checked 2026-07-19 and open at time of review. Used only to show role overlap and organizational variation.
10. Personal Information Protection Law of the People’s Republic of China, official text. Adopted 2021-08-20; effective 2021-11-01; checked 2026-07-19.
11. Data Security Law of the People’s Republic of China, official text. Adopted 2021-06-10; effective 2021-09-01; checked 2026-07-19.
12. Interim Measures for the Management of Generative Artificial Intelligence Services, official text. Published 2023-07-13; effective 2023-08-15; checked 2026-07-19.

v0.3 Source Corrections

• The previous Palantir job URL with ID 9147f4c1-0f8a-4917-9a68-05f5e06ff9cc returned HTTP 404 on 2026-07-19 and was replaced with an official ATS role sample that was still open that day.
• The OpenAI phrase “transferring capabilities to their teams,” cited in v0.2, could not be found on the current Deployment Company page checked on 2026-07-19. The direct quotation was removed and replaced with wording supported by the current page.
• v0.2 attributed the statement that a successful pilot is not the same as a system a business can run on to Anthropic’s enterprise AI services company announcement dated 2026-05-04. The currently verifiable wording appears in the Services Track announcement dated 2026-06-03, and the attribution has been corrected.
• Palantir’s engineer diary dated 2020-11-02 remains useful as a historical personal narrative, but v0.3 no longer uses it as core evidence for the current role definition.

Evidence Gaps and Beta Limits

• This chapter does not yet include a public E2/E3 real-world China enterprise case.
• The expense-package preparation example is illustrative only; it has no real users, baseline, eval, adoption, or outcome data.
• The China-enterprise section currently has legal and institutional entry points, but still lacks segmented interviews and project materials from finance, manufacturing, state-owned enterprises, internet companies, and small and medium-sized enterprises.
• The five-layer delivery evidence framework still needs to be used in at least three different project types, with real participants confirming which fields are useful, redundant, or missing.
• The role boundaries still require review by three to five current FDE, FDSE, Applied AI, or internal enterprise project leads.
• During Beta, reports of source changes, factual errors, or unclear framework boundaries are welcome. Please identify the passage, supporting evidence, and suggested correction; confirmed changes will be recorded in a later correction log.