# AI-DLC and AIDD for Forward-Deployed Engineers: Field Guide
You carry the whole lifecycle into someone else's organisation, and the decisions that are theirs to make stay theirs, even when it would be faster to make them yourself.
7 min read · Intermediate · Lesson 5 of 9 in By role · Updated 2026-10-03 · By Akash Das
Canonical: https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/ai-dlc-for-forward-deployed-engineers/
> **In short.** In the [Deliver stage](https://akash-coded.github.io/aws-bedrock-agentcore-strands/forward-deployed-engineer/deliver/) of the job, a forward-deployed engineer
> runs the whole agentic lifecycle inside a customer's organisation: measuring the pain in *their* data,
> running AI-DLC's mob sessions with *their* people, and building with AIDD habits in *their* stack.
> Every decision that trades their risk against their return is signed by *their* owner. The engineer
> leaves behind an evidence pack and a named person to run it.
**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.
*Setting the customer's refund limit yourself is faster, and it makes their risk yours. Push the decision back to their 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](https://akash-coded.github.io/aws-bedrock-agentcore-strands/forward-deployed-engineer/). 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](https://akash-coded.github.io/aws-bedrock-agentcore-strands/forward-deployed-engineer/deliver/#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](https://akash-coded.github.io/aws-bedrock-agentcore-strands/forward-deployed-engineer/deliver/#sign).
- **Moves 5, 6 and 7** are step 7, [Build](https://akash-coded.github.io/aws-bedrock-agentcore-strands/forward-deployed-engineer/deliver/#build): the build,
the proof on their cases and the shadow run.
- **Move 8** is step 8, [Hand over](https://akash-coded.github.io/aws-bedrock-agentcore-strands/forward-deployed-engineer/deliver/#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](https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/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?](https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/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](https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/ai-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](https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/what-is-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](https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/prove-ai-accuracy/)
### 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](https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/shadow-mode-and-cutover/)
### 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](https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/the-evidence-pack/)
## What is yours, and what is theirs
| Yours to do | Theirs to decide |
| --- | --- |
| Measure the pain, run the mob sessions, build the system | Which pain is worth solving, and at what value |
| Enforce every limit in code, with tests | The limits themselves, and who may approve above them |
| Build the golden set and the harness | What counts as a right answer in their business |
| Run the shadow and rehearse the rollback | Whether to widen, and when |
| Hand over the evidence pack | Who runs it after you leave |
## 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.
## Try it
A customer's compliance team will take three weeks to approve a refund limit. Your pilot ends in two.
**What do you do?**
Show the answer
**Ship everything except the unapproved action.** Run the refund action in shadow (deciding, logged,
never acting) while the rest of the pilot goes live on its own evidence. Record the open decision with
the compliance owner's name and date, and build the refund tool with the cap as a typed parameter so the
approved number is a one-line configuration change. Do not choose the limit yourself: that turns their
risk into yours.