AI-DLC and AIDD for forward-deployed engineers: field guide

In this lesson you'll learn:

• how AI-DLC and AIDD change when you run them inside a customer rather than your own team;
• the three decisions a forward-deployed engineer must get signed and must never make alone;
• how to hand over so the system survives your leaving.

Sound familiar?#

• The pilot was scoped from the sales deck, and the customer's real pain turned up in week three.
• You set the refund limit yourself because the customer's risk team was slow, and now it is yours.
• The deployment worked while you were on site, and quietly degraded after you left.

Each is a decision that belonged to the customer being made, or left unowned, by the person who was there. A forward-deployed engineer's advantage is speed; the risk is that speed moves decisions to the wrong side of the contract.

What is a forward-deployed engineer?#

A forward-deployed engineer (FDE) is a software engineer embedded with a customer to make a technical deployment succeed in that customer's systems and workflows. The role was popularised by Palantir and is now common at AI companies, including OpenAI and Anthropic. Where a product engineer builds one capability for many customers, an FDE builds whatever one customer needs, which, with AI agents, means running the whole lifecycle, fast, in someone else's organisation.

The job runs in three stages, Frame, Deliver and Evolve, each set out step by step in the forward-deployed engineer guide. This lesson is Deliver in depth: the weeks from the first day on site to the handover, run with AI-DLC and AIDD.

The guide's Deliver stage is four steps, 5 to 8, and this lesson walks the same weeks as eight moves:

• Moves 1 and 2 are step 5, Mobilise. Frame measured the pain from one export and named the people (steps 1 and 2); in week one you measure the pain again, from their records, and confirm who owns each risk.
• Moves 3 and 4 are step 6, Sign.
• Moves 5, 6 and 7 are step 7, Build: the build, the proof on their cases and the shadow run.
• Move 8 is step 8, Hand over.

The field guide, move by move#

Move 1 · Measure the pain in their data, in week one#

Replace the pitch with a pain register line from the customer's own records: who, how often, what it costs, and the evidence. It is also your first test of their data access, which is usually the longest lead time you will meet. File every other lead-time item on day one too, before any code: model access in the region their data must stay in, the security review, change approvals. P0 Frame

Move 2 · Name their risk owner before you design anything#

Find the person in the customer's organisation who can accept risk on each consequential action: money, identity, customer communications. If nobody can, you have found the first blocker, and it is not a technical one.

Move 3 · Run Inception as a mob, with their people#

AI-DLC's Mob Elaboration is well suited to a customer site: the AI proposes requirements and asks its clarifying questions, and the customer's own experts answer in the room. Record who answered what: the customer's decisions should carry the customer's names. What is AI-DLC?

Move 4 · Get the authority budget signed by them#

Autonomy per action, the caps and the approvals are theirs: a table of actions, each with a level and an approver, signed by the risk owner from move 2. You then enforce every cap in a tool signature with tests, but you do not choose the numbers. Guardrails that hold

Move 5 · Build with AIDD habits in their stack#

A context file in their repository, story files per bolt, exact code first, and a walking skeleton against their real system on the build's first day. It will find the credentials, network and data problems while they are cheap. AIDD

Move 6 · Prove it on their cases, in their pipeline#

Build the golden set from the customer's historical cases, tagged by the slices they care about, and wire the harness into their CI so the check outlives you. Prove the bar

Move 7 · Shadow beside their staff#

A shadow run at a customer finds the rules that live in people's heads. At SkyWays, this manual's fictional airline, fourteen disagreements were all one rule: the evening shift never uses a certain partner after 18:00, because its transfer desk closes. No spec had it. Shadow and cut-over

Move 8 · Hand over evidence and an owner, then leave#

Leave behind the evidence pack, the two-number report and, most important, a named person in their organisation who owns the running system: the drift watch, the rollback switches, the next brief. A deployment with no owner after the FDE leaves has no P3. The evidence pack

What is yours, and what is theirs#

Where you'll use it#

• On every customer deployment of an AI agent, from the first on-site week.
• When the customer's process is slower than yours: speed up the mechanics, never the risk decisions.
• In the contract and the statement of work: name the customer's risk owner and operator in writing.

Why it matters#

Forward-deployed engineering exists to get AI from pilot to production inside real organisations. The deployments that survive are the ones where the customer owns the decisions and the running system; the ones that fail are the ones that depended on the engineer who has since gone home.

Key takeaways#

1. An FDE runs the whole lifecycle in someone else's organisation, in their data, stack and pipeline.
2. Their risk owner signs the autonomy, the limits and the widening; you enforce them in code.
3. Hand over evidence and a named operator, or the deployment has no P3 after you leave.

FAQ#

What does a forward-deployed engineer do?#

Embeds with a customer to make a technical deployment succeed in that customer's systems: scoping the real problem, integrating with their data and infrastructure, building and adapting the solution, and handing it over. With AI agents, that means running the full lifecycle quickly at the customer site.

How do forward-deployed engineers use AI-DLC?#

AI-DLC's Mob Elaboration and Mob Construction fit customer sites well: the AI proposes and the customer's experts decide in the room, with decisions recorded under their names. Bolts of hours or days suit short engagements, and the adaptive workflows keep small customer requests from getting heavy process.

What is the biggest risk in forward-deployed AI work?#

That the engineer makes the customer's risk decisions (limits, autonomy, acceptance) because it is faster, and then leaves. The decisions should be signed by the customer's owner, and the running system should have a named operator in the customer's organisation.

How is an FDE different from a solutions engineer?#

A solutions engineer typically supports the sale and the design; a forward-deployed engineer builds and ships inside the customer's environment, often on site, and stays until the deployment works in production.

Apply it in your role#

Across the enterprise. An FDE programme scales when every engagement feeds a pattern library and the product roadmap. FDEs who only ever deliver bespoke work turn a product company into a services firm.

The ten-minute workflow. Turn field notes into roadmap evidence:

Here are my notes from three customer deployments: <paste>. List every problem I solved more than once:
the problem, how I solved it each time, and whether it should become configuration, a reusable service
or a product feature. For each product feature, write the one-paragraph request to the product team,
with the customer evidence.

Sources and credits#