01 · The boundary problemA deployment can work and still be structurally broken

The pilot looks impressive on Friday. By Monday morning, the only engineer who knows why it works is repairing a brittle connector, renewing a personal token and explaining a prompt exception from memory. Users call that person instead of an operating owner. Product leaders celebrate adoption. Security sees standing privilege. The platform team sees code it cannot release. The business owner sees a new dependency but no durable capability.

This is the problem a forward-deployed AI engineer can either solve or deepen. The useful version of the role enters a consequential workflow because ordinary discovery cannot surface enough context. It observes how decisions are really made, converts local language and exceptions into testable requirements, connects authorised systems, evaluates behaviour with domain users and sends repeatable learning back to a supported product. The dangerous version becomes the permanent interpreter, maintainer, approver and rescuer for a bespoke local system.

Employer descriptions help explain why organisations are interested. OpenAI describes a role spanning discovery, technical scoping, system design, production rollout, customer embedding, workflow impact and feedback into product and model roadmaps. Accenture describes a bridge between enterprise context and product implementation. These are contemporary role claims from employers with commercial incentives. They do not establish that an FDE title causes better outcomes, nor do they define the buyer's decision rights.

The question is not whether to hire a fashionable hybrid. It is whether a material boundary exists between a workflow and reusable product capability, whether crossing that boundary temporarily will create inspectable evidence, and whether the organisation can absorb what is learned. A mature product team with direct user access, a capable domain owner and reliable platform primitives may need no separate title. Routine configuration belongs with product engineering, a solutions architect or an implementation service. Policy ambiguity may require process redesign rather than AI.

02 · The operating contractWrite sixteen fields before the engineer crosses the boundary

The Forward-Deployment Contract is this article's first synthesis. It turns a loose instruction to embed with the business into a bounded service agreement. Its sixteen fields are not a procurement form. Together they make the outcome, system boundary, authority, access, evidence, production duties, transfer obligations and expiry inspectable before speed creates facts on the ground.

The first four fields anchor consequence: outcome and decision population; workflow and domain boundary; users and affected parties; deployment environment and system boundary. A claim handler, an applicant, a frontline worker and an audited customer may experience the same technical component differently. The contract names who can be affected, where the system touches a decision and where it must not operate.

The next six control the means: data, tools, models and integration scope; identity, secrets and segregation; FDE authority and prohibited actions; domain-owner authority and non-delegable judgement; product and platform obligations; and the rights of security, legal, privacy, risk and assurance. Broad access justified by urgency is a design defect. A vendor engineer uses buyer-owned identity, least privilege, recorded actions and a time limit. The contract states that the FDE may propose, build, test and operate only within written scope.

The final six make success testable: evaluation evidence and production gates; reliability, monitoring, incident and rollback duties; adoption, workflow and benefit measures; service period and support boundary; transfer artefacts and recipient obligations; and transfer criteria, expiry and residual owner. A demonstration is not a production gate. User counts are not benefit evidence. A folder of documents is not capability transfer.

03 · Five work modesMove through evidence, not a maturity theatre

The Forward-Deployment Work Modes are this article's second synthesis. They describe work that may occur inside one engagement. They are not a ladder that every use case must climb. Evidence can stop the loop after observation, return the problem to product engineering after specification or require a separately authorised production loop.

Observe and diagnose

The engineer watches real decisions, exceptions, workarounds and hand-offs. Interviews remain useful, but they often miss tacit judgement because experienced workers compress their reasoning. The output is a workflow map, exception taxonomy or retirement decision. Observation includes worker and affected-party implications: what new monitoring appears, which burdens shift, who can contest an error and whether AI is relevant at all.

Translate and specify

Local language, examples, failure consequences and policy constraints become testable requirements, evaluation sets, interface contracts and acceptance conditions. A boundary object must be legible to both domain and engineering teams. A private notebook is not enough. Carlile's work on knowledge boundaries is useful here because transfer may require more than shared vocabulary: teams may need to transform what they know when interests and consequences differ.

Integrate and evaluate in situ

The team assembles the smallest production-representative path, connects only authorised systems and exposes actual failure surfaces. The purpose is not a polished demo. It is to generate decision-grade evidence with qualified users under realistic constraints. Failed cases, unavailable data, slow hand-offs and operational exceptions belong in the evidence set.

Stabilise under bounded production

Only an approved path is hardened. Monitoring, runbooks, incident routes, rollback, support limits and operational ownership are established before the FDE becomes an unplanned service desk. Google's SRE engagement and production-readiness material offers an adjacent pattern: entry conditions, staffing, reliability preparation and explicit ownership matter before a specialist team accepts production responsibility. An FDE is not an SRE, but both patterns expose the cost of vague engagement boundaries.

Codify, transfer and exit

Local fixes become supported product capabilities, an explicitly owned local service or a retirement decision. Code, configuration, tests, evaluation sets, threat models, decision records and runbooks move into supported systems. Recipients demonstrate the change and incident processes. Temporary access is removed. If ongoing specialist operation is genuinely needed, it becomes a separately priced and governed service rather than a silent extension.

The Embedded Constraint Loop is this article's third synthesis: observe real work, make the constraint explicit, prototype the narrow path, test consequential evidence, productise the repeatable part, transfer ownership, then exit or begin a separately authorised loop. Every turn leaves an inspectable boundary object. Conversation and personal memory do not count.

04 · Two keysContext and consequence belong to different owners

Two-Key Authority is this article's fourth synthesis. The domain or business owner holds the first key: workflow consequence, policy interpretation, affected-party treatment and benefit capture. The product, platform or engineering owner holds the second: system integrity, reusable architecture, release quality, reliability and technical debt. Consequential movement requires both keys.

Security, legal, privacy, risk or assurance functions retain independent challenge or veto only at defined control boundaries. They do not inherit responsibility for domain value or workflow adoption. The FDE may propose, build, test and operate within the contract, but cannot unilaterally accept business risk, redefine policy, approve independent assurance or expand the system boundary. This avoids a common error: the most proximate technical person gradually becomes the de facto product owner, risk acceptor and first-line operator.

NIST's AI RMF separates governance, mapping, measurement and management across a lifecycle and describes distinct actor tasks in design, development, deployment, operation, evaluation, domain expertise, governance and affected communities. The UK Government AI Playbook and digital capability framework likewise make visible product, service, engineering, data, security, user-centred and assurance capabilities. These sources support role clarity, but the two-key mechanism itself is this article's design.

05 · Transfer debtPrototype speed can borrow from the exit

The Transfer Debt Ledger is this article's fifth synthesis. It records any dependency created when speed relies on knowledge or assets that cannot survive the FDE's exit. The ledger is not a moral judgement about improvisation. Narrow experiments often require temporary shortcuts. The control is to make each shortcut visible with an owner, exposure, removal action and deadline before it becomes architecture.

Debt includes undocumented configuration, tacit workflow rules, local code outside supported repositories, one-off transformations, vendor-only identity or observability, missing tests and evaluation sets, unowned runbooks, product gaps concealed by manual patches, business rules encoded without domain approval, personal relationships used as incident routes, hero on-call and recipient teams with no capacity. A successful prototype can be a failed engagement if this debt grows faster than evidence and reusable capability.

Track debt at each loop, not at handover. A local connector may be acceptable during evaluation if it is isolated, observable and scheduled for a product decision. It becomes dangerous when the pilot expands while the connector's owner remains the FDE. The platform owner must choose: absorb a repeatable pattern into the supported product, contract the local service with a real owner, or stop. “Temporary” is not a fourth operating model.

06 · The Exit LadderA handover meeting is not an exit test

The Exit Ladder is this article's sixth synthesis. Its six rungs require demonstrated performance. First, the boundary is understood: workflow, constraints, authority and non-AI alternatives are explicit. Second, evidence is repeatable: another qualified person can rerun the evaluation and reproduce the deployment decision. Third, artefacts are durable: code, configuration, tests, records and controls live in supported systems.

Fourth, owners are capable: named product, platform, domain and operating owners demonstrate the runbook, incident route and change process. Fifth, access is withdrawn: temporary privileges, secrets, environments and vendor pathways are removed or converted to standard roles. Sixth, the FDE exits. Residual work is absorbed, productised, deliberately contracted as a service or stopped.

Documents support these demonstrations but cannot substitute for them. Ask a recipient to deploy from the supported path, interpret a failed evaluation, respond to an alert, roll back a change and explain who may approve the next release. If those tasks still depend on the FDE's prompts or memory, the engagement has not crossed the relevant rung.

07 · Ten worked casesFollow the contract to the next gate

Each case below states the contract boundary, active mode, constraint loop, two keys, transfer debt, Exit Ladder position, affected-party or worker implication, owners and next gate. At least three deliberately stop or choose another intervention.

08 · Practical instrumentFDE Mandate Designer

The FDE Mandate Designer is this article's seventh synthesis. It combines boundary clarity, novelty, consequence, authority, evidence, transfer debt, recipient capacity and expiry. It returns one of five decisions rather than a universal readiness score. The named cases are starting points, not endorsements.

09 · Strong rival and failure boundaryA good product team may make the title unnecessary

The strongest rival is not another hybrid job title. It is a mature product team with direct user access, clear domain ownership, strong engineering and reliable platform primitives. Such a team can observe work, run evaluations, integrate systems and learn from production without creating a separate embedded role. In a small organisation, one capable engineer may span domain and product duties safely for a reversible internal use, provided incompatible approval and challenge events are separated.

Embedding can fragment architecture, increase security exposure, reward heroic customisation and conceal product weakness. A vendor FDE may optimise adoption of its own platform instead of the buyer's full operating outcome. Field feedback can become a stream of anecdotes that displaces product strategy. Customer intimacy is useful only when it yields boundary objects, consequential evidence and portable decisions.

Use the role only when material context is unavailable through normal discovery, the integration path is genuinely novel and the organisation can name the outcome owner, engineering owner, evidence gate and transfer recipient. Reject the engagement when the operating boundary is unclear, the domain has no accountable owner, routine configuration is the likely work, independent challenge would be compromised, or transfer capacity cannot be funded. Stop when evidence shows process redesign or no AI is the better intervention.

10 · Evidence and limitationsWhat the sources support, and what they do not

Employer pages establish that forward-deployed engineering is currently described as a combination of discovery, technical scoping, direct implementation, production rollout, customer embedding and feedback into product. They are recruitment materials, not independent comparative studies. This paper therefore uses them to bound contemporary role claims, not to infer effectiveness.

NIST materials support multidisciplinary lifecycle governance, explicit responsibility, human-AI configuration, documentation, monitoring, incident handling and retirement. UK Government sources reinforce accountable product delivery and the distinction among product, software, data, security, service, user research and assurance capabilities. Google SRE material supplies an adjacent example of bounded specialist engagement and production readiness. None prescribes the Forward-Deployment Contract or proves that an FDE is necessary.

Carlile explains how boundary objects help teams represent, learn and transform local knowledge across syntactic, semantic and pragmatic boundaries. Argote and colleagues locate organisational knowledge in members, tasks, tools and networks, clarifying why transfer fails when the person moves but the system does not. Edmondson's team research supports the importance of speaking up and learning behaviour. Amershi and colleagues provide interaction guidelines spanning initial use, normal operation, failure and change. Field experiments on generative AI show that effects can differ across workers, expertise and team arrangements, but their settings do not justify general claims about all deployments.

The Forward-Deployment Contract, Work Modes, Embedded Constraint Loop, Two-Key Authority, Transfer Debt Ledger, Exit Ladder and Mandate Designer are this article's synthesis. They require contextual testing. Legal duties vary by jurisdiction, and high-consequence sectors may require stronger separation, evidence and approval. The human-AI interaction reference below uses the verified Microsoft Research and CHI record because the source pack's supplied arXiv identifier resolves to an unrelated physics paper.

1. OpenAI, Forward Deployed Engineer (FDE) - SF.
2. Accenture, Forward Deployed Engineer - Products.
3. NIST, Artificial Intelligence Risk Management Framework.
4. NIST AIRC, AI RMF Core.
5. NIST AIRC, Descriptions of AI Actor Tasks.
6. NIST AIRC, AI Risk Management and Human-AI Interaction.
7. NIST, AI RMF Playbook.
8. UK Government, Artificial Intelligence Playbook for the UK Government.
9. UK Government, Government Digital and Data Profession Capability Framework.
10. Google, Evolving the SRE Engagement Model.
11. Google, SRE Engagement Model.
12. Amershi et al., Guidelines for Human-AI Interaction.
13. Carlile, A Pragmatic View of Knowledge and Boundaries.
14. Argote and Ingram, Knowledge Transfer.
15. Argote and Fahrenkopf, Knowledge Transfer in Organizations.
16. Edmondson, Psychological Safety and Learning Behavior in Work Teams.
17. Dell'Acqua et al., The Cybernetic Teammate.
18. Brynjolfsson, Li and Raymond, Generative AI at Work.