Become a Forward Deployed Engineer

Module 0 — Orientation & Gap Baseline

Objective: know exactly what you're converting from and to.

• Read Part I above twice. Write one page in your own words: "What an FDE does that I don't currently do."
• Collect 10 real FDE job postings (AI labs, Palantir-style companies, agent-platform startups, local enterprise AI roles). Extract every required skill into a spreadsheet; tag each ✅ have / 🟡 partial / ❌ gap. This weights your course hours — spend them proportional to the ❌ and 🟡 tags.
• Self-rate the six pillars (table above), 1–5. Date it.
• Inventory your evidence: every shipped product, deployment, and engagement you can legitimately talk about in an interview — the problem, what you built, and the measured outcome. Most builders find their history lacks the measurement. That's the point of Module 3.

Module 1 — Discovery & Scoping: The FDE's First Two Weeks

Objective: master the skill that separates FDEs from strong builders — converting an ambiguous enterprise into a scoped, signable pilot.

1.1 — The discovery interview

• Who to interview: operators (do the work), managers (own the metric), IT/security (own the veto), and the executive sponsor (owns the money).
• The interview spine: "walk me through the last time you did X" — never "what do you want from AI?" Users don't know what AI can do; you don't know what their work actually is. Trade accordingly.
• Hunt the four AI-shaped signals: high-volume repetitive judgment; document and unstructured-data drudgery; expensive expert time spent on low-expertise tasks; information scattered across systems that humans manually join.
• Anti-signals — flag, don't chase: hard real-time guarantees, required determinism, unrecoverable errors.

1.2 — Use-case scoring

Build a scoring matrix. Columns: Value (hours × cost × frequency), Feasibility (data availability, task verifiability, error tolerance), Time-to-prove (can a pilot show value in under 4 weeks?), Sponsor strength, Expansion path. Score each candidate 1–5 per column. The pilot pick is rarely the highest-value item — it's the highest provable-quickly item with a live sponsor.

1.3 — Scoping the pilot: the Statement of Pilot

One page, signed by the sponsor:

• The workflow — one, specific, named
• Success criteria — numeric, with an agreed measurement method: "≥85% of claims triaged correctly vs. senior assessor judgment on a 200-claim holdout, at under 60 seconds per claim"
• Data & access required, and who provides it by when
• Out of scope — the fence that saves you (no production writes, no PII beyond X, no system Y integration in pilot)
• Timeline — 2–4 weeks with a mid-point checkpoint
• The decision the pilot informs ("if criteria met, we proceed to production scope next quarter")

The cardinal rule: never start a pilot whose success criteria the customer hasn't signed. An unsigned pilot is unfalsifiable, and unfalsifiable pilots die in procurement.

1.4 — Reading the political map

• Identify the sponsor, the champion, the sceptic, and the veto-holder (security/legal) in week one — and give the sceptic a job in the pilot: they define the holdout set. Converted sceptics are your best expansion salespeople.
• IT distrusts you by default — you're shadow-IT with a vendor's logo. Flip them: bring them in before they find you, and hand them the security documentation pack unprompted.

Module 2 — LLM Engineering Core, Formalised

Objective: convert practitioner fluency into examinable engineering knowledge. In interviews and in front of customer architects, you must explain why, with vocabulary — not just demonstrate that.

2.1 — Model behaviour from first principles

• Tokens, context windows, attention (conceptual level), why long contexts degrade ("lost in the middle"), sampling parameters and when they matter.
• Model selection as an engineering decision: capability tier vs. latency vs. cost. Build the habit of saying "this task needs frontier reasoning; this sub-task is a classification a small model does at a twentieth of the cost."

2.2 — Context engineering

• The hierarchy: system prompt (behaviour contract) → retrieved context (facts) → conversation (state) → tools (capability).
• Prompt structure as engineering: role, constraints, output schema, few-shot examples, escape hatches ("if information is missing, say so — never invent").
• Structured outputs and schema enforcement; when to force JSON vs. let the model write.

2.3 — Retrieval (RAG) properly

• Chunking strategy is a product decision, not a default: chunking by document structure (headings, clauses) beats fixed token counts for enterprise documents.
• Embeddings plus hybrid search (BM25 + vector) — hybrid wins on enterprise jargon, codes, and IDs.
• Evaluate retrieval separately from generation: recall@k on a labelled query set before you ever look at answers.
• When RAG is wrong: small corpora (put it all in context), highly structured data (query the database, don't embed it), and agentic search as the increasingly common alternative.

2.4 — Cost, latency, and reliability engineering

• Prompt caching, batching, streaming; retry/backoff and idempotency around a probabilistic API.
• Failure design: what does your system do when the model refuses, drifts, or times out? The enterprise answer: degrade to a human, loudly, with logs.

Module 3 — Evals & Measurement: The Credibility Engine

Objective: close the most common gap in strong builders. FDEs live and die by evals — the pilot readout (Module 6) is only as strong as the harness behind it.

3.1 — Eval anatomy

• Golden dataset: 50–200 real (or realistic) input cases with reference outputs or grading criteria. In pilots, sourced from the customer's actual historical data — which is why data access lives in the Statement of Pilot.
• Graders, in order of preference: exact/programmatic checks (cheapest — use whenever output is verifiable) → rubric-based LLM-as-judge (for prose quality; validate the judge against human labels on a sample) → human review (expensive; reserve for calibration and the final readout).
• Metrics that survive an executive readout: task success rate, critical-error rate (kept separate — one hallucinated legal citation outweighs ten formatting wins), latency, cost per task, and comparison against the human baseline.

3.2 — The eval-driven development loop

• Write the eval before improving the system — it's test-driven development for AI.
• Regression gates: no prompt, model, or retrieval change ships without a run. Keep a scoreboard over time.
• Error analysis discipline: read every failure, categorise it (retrieval miss / reasoning error / format / refusal), fix the biggest category, re-run. Never "tweak the prompt and eyeball it" again.

3.3 — Evals for agents

• Trajectory evals (did it take sane steps?) vs. outcome evals (did it end right?) — outcome-first, trajectory for debugging.
• Tool-call correctness, recovery-from-error behaviour, and cost-per-completed-task as a first-class metric.

Module 4 — Agents, Tools & Enterprise Integration

Objective: formalise agent-building into architecture patterns you can defend at a whiteboard, and go deep on MCP (Model Context Protocol) as the integration standard.

4.1 — The agent design ladder

Climb only as high as the task demands — each rung adds capability and failure modes:

1. Single call
2. Chained workflow (fixed steps)
3. Router (model picks the path)
4. Tool-using agent (model picks actions in a loop)
5. Multi-agent (orchestrator + specialists)

Interview-ready rule: start at the lowest rung that works; agents are for when the path through the task is unknowable in advance. Most enterprise value ships at rungs 2–4.

4.2 — Tool design

• Tools are UX for models: few, well-named, with descriptions written like documentation for a smart new hire; return errors the model can act on.
• The read/write boundary: reads are cheap to grant; writes need approval gates, dry-run modes, and audit logs. Enterprise deployments are won and lost on this design.
• Context discipline: what each tool returns is a context-budget decision.

4.3 — MCP in anger

• Server anatomy: tools, resources, prompts; transport options; auth patterns.
• Failure handling: timeouts, partial results, and the model retrying a failing tool forever (set budget caps).

4.4 — Human-in-the-loop as architecture

• Approval gates, confidence-based routing (auto-handle the easy 80%, queue the hard 20%), escalation design.
• "Human in the loop" is the phrase that unlocks enterprise deals — it converts "AI risk" into "AI-assisted process with controls."

Module 5 — Production & Enterprise Deployment

Objective: package deployment competence into the form enterprise security reviews and FDE interviews expect — including the LLM-specific operations layer.

5.1 — The security review you must survive

• The questions every enterprise asks: where does data go, is it retained or trained on, who can see it, how is it encrypted, what's the tenancy model, and where does inference run (SaaS API vs. cloud-provider endpoints vs. VPC/self-host)?
• Prompt injection as the LLM-era vulnerability class: untrusted content entering the context — documents, emails, web pages — must be treated as data, never instructions. Tool permissions bound the blast radius.
• Data governance in pilots: de-identification, minimum-necessary data, the customer's data classification rules. Get the data-handling agreement in writing during scoping.

5.2 — LLM observability

• Log every call: prompt version, model, tokens, cost, latency, outcome. Trace multi-step agent runs end to end.
• Quality drift monitoring: run your eval suite on a schedule against samples of production traffic.
• Cost controls: budgets, per-tenant metering, kill switches.

5.3 — Handover engineering

• The pilot isn't done until a named customer engineer can run, debug, and extend it — pair with them from week one, not week last.
• The handover pack: runbook, architecture doc, eval harness, and a "how to change a prompt safely" guide.

Module 6 — The Consultative Layer

Objective: perform under scrutiny — demos, readouts, objections.

6.1 — The executive demo

• Structure: their problem in their words (1 min) → the workflow live, on their data (5 min) → the numbers (2 min) → what it takes to deploy (2 min).
• Demo discipline: pre-run everything, keep a recorded backup, never demo an untested path — and plant one deliberate "watch what happens when it doesn't know: it says so" moment. That builds more trust than ten successes.

6.2 — The pilot readout

• The deck: criteria we agreed → what we measured → results vs. criteria → error analysis, honestly shown → production path and cost → the ask.
• Show failures deliberately: an FDE who presents 87% and explains the 13% wins the renewal; one who presents "it works great" loses it in questions.

6.3 — Objection handling (build the crib sheet, rehearse aloud)

• "It hallucinates" → error rates measured against the human baseline (also measured), plus human-in-the-loop controls.
• "Our data can't leave" → deployment-boundary options, retention terms, what's contractually enforced.
• "Security won't approve" → hand them Module 5's pack; offer the security team a working session.
• "It'll replace our people" → the pilot's design shows augmentation, plus numbers on what staff stopped doing.
• "We'll build it ourselves" → total-cost honesty: model access isn't the moat, the deployed-working-system is; offer to build alongside their team — that's literally the FDE model.

Module 7 — Capstone: The Full Simulated Engagement

Objective: run the entire FDE loop once, end-to-end, producing the single strongest interview asset you'll own.

Setup: pick a real business you can access — a past client, a local firm, a friend's company. If none is accessible, use a rigorously realistic fictional enterprise — but real access is worth three times more.

Execute in order, using every module's kit:

1. Discovery (Module 1): interviews, scored use-case shortlist
2. Scope: Statement of Pilot with numeric success criteria
3. Build (Modules 2, 4): the pilot system on real(istic) data, the appropriate rung of the agent ladder, human-in-the-loop where warranted
4. Prove (Module 3): eval harness — baseline → iterations → final numbers vs. criteria
5. Package (Module 5): security/data-flow one-pager, cost model, runbook
6. Readout (Module 6): recorded 15-minute readout presentation as if to the sponsor

Pass criteria (self-assessed, honestly):

• Success criteria were written before the build and not retro-fitted
• The eval has ≥50 cases and a separate critical-error metric
• The readout shows failures and their categories, not just wins
• A stranger could deploy and operate the system from your pack alone