Skip to content
FDE Handbook

Syllabus

Design approach: organize the complete knowledge map into modules and lessons without binding it to a fixed number of weeks. Each lesson includes detailed topics, learning outcomes, and estimated total study time. Modules can later be combined flexibly based on a learner’s background, goals, and weekly availability.

Curriculum principles: Less syntax, more systems. Start with the business problem. Add technical complexity only when the problem truly requires it. Puffo/Pavlov can serve as a rapid delivery abstraction layer, while the curriculum also explains the code, tools, state, data, permissions, and production engineering behind it.

Generated on 2026-11-03. Download as CSV

This is the public edition: every module is listed below, but only the public modules’ pages open here. Modules marked “Full handbook” are available to the Azure Partners team.

Module overview

ModuleLessonsStudy timePurpose
M0 · Start Here — Understanding the FDE Role31.5–3hGive readers who don't yet know what an FDE is a map before any engineering: what the role is accountable for, how it differs from neighboring roles, and which module builds the capability each stage of FDE delivery needs. Orientation only, no engineering detail.
M1 · AI-Assisted Development & Software Systems Foundations Full handbook628–42hBuild a mental model of modern software systems for beginners or technically rusty learners, and enable them to read, run, modify, debug, and deploy code with AI coding tools. The focus is system understanding rather than syntax memorization.
M2 · AI Application Engineering Full handbook628–43hTurn LLMs from “chat tools” into verifiable, integrable application capabilities. Use a Tutor / Customer Support RAG case to build foundations in prompting, RAG, tool calling, evaluation, and guardrails.
M3 · Agent Engineering — From Prompts to Scalable Agent Systems Full handbook631–49hDefine an agent as a job with real boundaries, give it reusable skills backed by code where needed, choose between a workflow, a single agent and multiple agents, and make its state, long-running work and failures manageable. An agent is not simply a prompt, and more agents are not automatically better.
M4 · Enterprise Integration & Production AI Full handbook527–42hTeach learners that real customer environments involve data, APIs, permissions, security, deployment, observability, cost, and reliability beyond prompts/agents, and develop judgment about when deeper engineering is required.
M5 · FDE Discovery, Consulting & Delivery Full handbook739–62hTrain the core capabilities that distinguish FDEs from typical AI Engineers: entering ambiguous customer environments, finding the real problem, defining outcomes, managing scope, making technical/business trade-offs, and driving pilots, acceptance, handoff, and productization.
M6 · Four Representative FDE Use-Case Archetypes427–40hUse four realistic cases of increasing complexity to demonstrate the same FDE method repeatedly. Industry is the context; the goal is to understand why different business problems require different technical depth.
M7 · FDE End-to-End Practicum Full handbook652–78hLearners choose an approved customer-style use case and complete a full FDE delivery from Discovery through Release/Handoff. This is the core job-search portfolio module and is not tied to a fixed number of weeks.
M8 · Career Preparation & FDE Interviews Full handbook415–25hTurn real curriculum and practicum outputs into verifiable job-search evidence, and prepare for common FDE interviews in engineering, system design, problem decomposition, customer communication, and project deep dives.
Full path47248.5–384hA complete knowledge and project pathway from near-beginner level to an entry-level / apprentice FDE job-search portfolio.

M0 · Start Here — Understanding the FDE Role

Goal: give readers who don't yet know what a Forward Deployed Engineer is a map before any engineering begins: what the role is accountable for, how it differs from neighboring roles, and which module builds the capability each stage of FDE delivery needs. Orientation only, with no engineering detail; read it first whatever your background.

3 lessons · 1.5–3h · Required for every background; read first

Lesson 1 · What Is a Forward Deployed Engineer?

0.5–1h

Learning outcomes: Explain what an FDE is accountable for, place any FDE job on the four-responsibility model, and explain why the role needs engineering, AI, delivery and business context at once.

Row IDWhat you learnResources
M0-L1.1

FDE: A Forward Deployed Engineer (FDE) is an engineer embedded with a specific customer who is accountable for a system running, being used and producing a measurable result inside that customer's real systems, permissions and workflows.

M0-L1.2

Many Capabilities for One Customer: A product engineer builds one capability for many customers, while an FDE delivers many capabilities for one customer and helps turn what worked there into product for the next customer.

M0-L1.3

Four FDE Responsibilities: A complete FDE owns a loop of four responsibilities (Discovery, Production, Adoption and Feedback): choosing the customer problem worth solving, making the solution run safely in the real environment, getting real users to actually use it, and carrying field lessons back into the product.

M0-L1.4

Echo and Delta Roles: Palantir splits field work between Echo, embedded analysts who decide which problem to solve, and Delta, deployed engineers who build it; many companies merge both into one person, so the split describes responsibility, not seniority or tech stack.

Lesson 2 · FDE vs. Adjacent Roles

0.5–1h

Learning outcomes: Compare an FDE with each neighboring role on responsibility rather than on who writes code, and use the three role tests to place a real job description.

Row IDWhat you learnResources
M0-L2.1

FDE Title Variation: There is no universally accepted industry boundary for the FDE role; companies use the same title for model-optimization engineers, multi-customer delivery engineers and on-site prototypers, so judge a role by what it is accountable for, not by its name.

M0-L2.2

Role Tests: Three questions separate an FDE from neighboring roles better than "do they write code": does the code reach production, do field lessons flow back into a product, and is the work paid for and measured by time or by outcome.

M0-L2.3

FDE vs Software Engineer and AI Engineer: A software or AI engineer builds and improves the company's own product for many users; an FDE starts from one customer's problem, builds what that customer needs on top of the product, and owns whether it works there.

M0-L2.4

FDE vs Solutions Architect and Sales Engineer: Pre-sales roles show that a solution can work in order to win the deal and usually step back once it closes; an FDE is accountable for making it work in production after the contract is signed.

M0-L2.5

FDE vs Consultant and Systems Integrator: End-to-end consulting firms can also take a project from discovery through production, so the difference is not who writes code; an FDE delivers on top of their own company's product and feeds what they learn back into it, so each next customer costs less to serve.

M0-L2.6

FDE vs Implementation Engineer and Outsourcing: Implementation and outsourced teams deliver what the customer specified, and the know-how stays with the project or leaves with the person; whether an FDE team is just outsourcing under a new name depends on whether the reusable parts end up in a product.

M0-L2.7

FDE vs Customer Success Manager: A customer success manager keeps an already working product adopted and renewed, mostly without code; an FDE builds the customer-specific part that has to work first and shares responsibility for getting it adopted.

Lesson 3 · The FDE Delivery Lifecycle & Handbook Map

0.5–1h

Learning outcomes: Name the lifecycle stages in order, say which module builds the capability each stage needs, and pick a reading path through the handbook from your background.

Row IDWhat you learnResources
M0-L3.1

FDE Delivery Lifecycle: An FDE engagement moves through ten stages (Qualify → Discover → Define → Build → Integrate → Evaluate → Deploy → Adopt → Handoff → Productize), which group into the four responsibilities: Discovery, Production, Adoption and Feedback.

M0-L3.2

Lifecycle-to-Module Map: Each stage of the FDE lifecycle draws on a specific part of this handbook, so the 44 lessons after Module 0 form a capability map rather than a list of topics.

  • No external resource needed. Use the Module Overview for hours per module, and the Introduction of each module for its lesson list.
M0-L3.3

Handbook Reading Paths: Readers choose how deep to go in each module (Know, Use, Build or Design) based on their background, skip what they already master, and treat Module 0 and the Module 7 practicum as required for everyone.

  • No external resource needed. The Background Pathways table in the syllabus gives the full per-module recommendations.

M1 · AI-Assisted Development & Software Systems Foundations Full handbook

Goal: help beginners or technically rusty learners build a mental model of modern software systems and use AI coding tools to read, run, modify, debug, and deploy code. The emphasis is not memorizing syntax, but understanding how systems work.

6 lessons · 28–42h · Skip mastered modules based on the entry assessment

Lesson 1 · AI Coding Workspace & Vibe Coding Collaboration

4–6h

Learning outcomes: Set up an AI-assisted development workspace; read and modify small codebases; explain what submitted code actually does.

Row IDWhat you learnResources
M1-L1.1

AI Coding Workflow: The AI coding workflow is a repeating loop, state the requirement, break it into tasks, let the AI generate code, run it, check the result, and revise, with a human deciding what to build and whether the result is correct.

M1-L1.2

AI Coding Tools: AI coding tools come in different forms, autocomplete that suggests the next line as you type, and agentic tools that read a codebase, plan a change, edit multiple files, and run commands on their own, and the form you are using changes how much you should trust the output unsupervised.

Development Environment: The development environment is the terminal, editor, project folder, installed packages, and configuration that code needs to run, and every AI coding tool works inside that same environment, not instead of it.

Context Management: Context management is deciding what goes into the AI's context window, the text it can actually see, because the AI has no memory of your project beyond what is in front of it.

M1-L1.3

Reading Code: Reading code is pattern recognition, spotting functions, variables, conditionals, loops, exceptions, and modules, patterns every mainstream language shares, so you do not need fluency in a language to trace what its code does.

M1-L1.4

AI Code Review: Reviewing AI-generated code means asking the AI to explain what it wrote, list the risks, and write tests, then confirming each answer yourself by running the code, instead of trusting the explanation.

Lesson 2 · How Modern Web Applications Actually Work

5–7h

Learning outcomes: Draw the architecture of a simple application and explain how a request flows through the frontend, backend, database, and external services.

Row IDWhat you learnResources
M1-L2.1

Web App Layers: A web app is not one program but a set of separate pieces, running in different places, that pass messages back and forth to produce one answer.

M1-L2.2

Client-Server Model: A client is any program that starts a conversation by sending a request, and a server is any program that waits for requests and sends back responses.

IP Addresses and Ports: An IP address identifies a machine on a network, and a port number tells that machine which program should receive the traffic.

Processes and Services: A process is a running instance of a program, with its own memory, and it stays running only until something stops it, on purpose or by accident.

HTTP Requests and Responses: HTTP is the agreed-upon format a client and a server use to exchange a request and a response, both structured as plain text with a few required parts.

HTTP Methods: The HTTP method is the verb in a request, telling the server what kind of action the client wants, and picking the right one lets other programs make safe assumptions about what a request will do.

Status Codes: A status code is a three-digit number at the start of every HTTP response that tells you, at a glance, whether the request succeeded, failed, or needs something else before it can complete.

JSON: JSON is a plain-text way of writing structured data that both a browser's JavaScript and a backend's Python can read and write without confusion.

M1-L2.3

Logic Placement: Each layer of a web app runs on a different machine controlled by a different party, and putting a security check or a secret in the wrong layer is a common way real apps get broken into.

M1-L2.4

Full Request Lifecycle: A single click in a browser sets off a full chain of steps, DNS lookup, connection, encryption, request, backend logic, and response, and being able to follow that chain is the fastest way to find where something actually broke.

Lesson 3 · API, Data & Systems Integration Foundations

5–7h

Learning outcomes: Read API documentation, call external services, inspect returned data, and diagnose whether integration failures come from authentication, networking, formatting, or business logic.

Row IDWhat you learnResources
M1-L3.1

REST Conventions: REST is a style for designing APIs where every piece of data is a "resource" with its own URL, and you act on it with standard HTTP methods, headers, and query parameters.

API Authentication: Authentication is how an API proves who (or what) is calling it, usually through a secret value sent with every request, and authorization is the separate question of what that identity is allowed to do.

Error Responses and Timeouts: A failed API call either comes back with a status code and an error body you can read, or it never comes back at all within the time you were willing to wait, and those two situations need different handling.

Rate Limits: A rate limit is a cap on how many requests, or how many tokens, a client can send in a given time window, and going over it gets a 429 response instead of an answer.

M1-L3.2

CSV and Tables: CSV is a flat, plain-text way to store rows of data with no enforced types, while a database table enforces a schema.

Relational Model: A relational database stores data in linked tables, so related facts are not duplicated everywhere they are needed.

Schema and Data Contracts: A schema is the structure two systems agree to use for a piece of data, and that agreement is a contract, even when nobody wrote it down.

SQL Basics: SQL (Structured Query Language) is how you talk to a relational database: create tables, insert data, and ask questions about what is stored.

M1-L3.3

Webhook vs. Polling: Polling means repeatedly asking another system "has anything changed yet," while a webhook means the other system calls you the moment something happens.

Integration Boundaries: Not every system exchanges data through a REST API; a lot of real integration work moves data through file drops, direct database reads, or prebuilt SaaS connectors, each with its own format, owner, and failure points.

Integration Failure Diagnosis: When a call to an outside API fails, the status code and error message tell you which of four buckets the problem falls into: authentication, networking, data format, or business logic.

M1-L3.4

Data Normalization: Normalization means organizing a database so each fact is stored exactly once, and the term also has a second meaning: reshaping data from different sources into one consistent format.

Lesson 4 · Git, Debugging, Testing & Security Basics

4–6h

Learning outcomes: Maintain a traceable code repository, diagnose common errors, and demonstrate basic security and testing awareness.

Row IDWhat you learnResources
M1-L4.1

Git Mental Model: Git tracks a project's files through three areas, the working tree where you edit, the staging area where you mark what to save, and the commit history where saved snapshots live forever.

Branches and Merging: A branch is a movable pointer to a commit that gives you a separate line of work where you can make changes safely, and a merge combines that branch's changes back into another one.

Diff and Revert: A diff shows exactly which lines changed between two versions of a file, and a revert undoes a commit by adding a new commit rather than erasing the old one.

Pull Request Workflow: A pull request (PR) is a request, made on a hosting platform like GitHub, to merge one branch into another, with a review step in between.

M1-L4.2

Logs and Stack Traces: Logs and stack traces are the evidence a program leaves behind, a log describes what it did and a stack trace shows where it crashed.

Reproduce, Narrow, Minimize: Reproduce, narrow, and minimize is a repeatable method for tracking a bug down to its cause, instead of guessing at a fix.

M1-L4.3

Test Case Types: A test is code that runs your program with a known input and checks the result, and thorough testing covers normal, unusual, and rejected input.

Unit vs. Integration Tests: A unit test checks one small piece of code on its own, and an integration test checks that real pieces, like your code and a real database, actually work together.

M1-L4.4

Secrets Management: A secret, an API key, a database password, a token, should never live in code or in a git repository, and should instead be stored and rotated through a system built for that purpose.

Input Validation: Input validation is checking that data from a user, a form, or an outside service matches what your code expects before you use it.

Least Privilege: Least privilege means giving every piece of code, database user, and API key only the access it needs to do its job, nothing more.

Dependency Risk: A dependency is code someone else wrote that your project relies on, and dependency risk is the chance that code has a known security problem you never reviewed yourself.

Lesson 5 · Docker, Containers, Cloud & Basic Deployment

5–8h

Learning outcomes: Understand core containerization and cloud deployment concepts; deploy an application using existing platforms and diagnose common deployment issues.

Row IDWhat you learnResources
M1-L5.1

Images, Containers, Registries: Docker packages an app with the exact language version, libraries, and OS files it needs into a single unit, so that unit runs the same way on any machine.

Volumes and Persistence: A container's own filesystem disappears whenever the container is replaced, so anything that needs to survive, such as a database or an uploaded file, has to live in a separate place.

Port Mapping: A container's port is closed to the outside world until you explicitly connect it to a port on the host machine.

M1-L5.2

Deployment Environments: An environment is a separate copy of an app used for one stage of work, such as building it, testing it, or serving real users, and mixing them up is a common cause of "it worked yesterday" bugs.

Compute Options: A compute option is where and how your code actually runs in the cloud, and the main choices, serverless functions, virtual machines, and managed container services, trade off control, setup effort, and cost differently.

M1-L5.3

Configuration: A cloud app reads its settings from the platform it runs on, not from a file on a developer's laptop, so the same image behaves correctly in every environment.

HTTPS, Domains and Certificates: Once an app runs somewhere, it needs a human-readable address that DNS can translate, and a certificate proving that address is really it, so traffic can travel over encrypted HTTPS.

M1-L5.4

Deployment Logs: Deploying means getting an app running on a server the world can reach, and reading logs is how you find out why a deployment failed.

Lesson 6 · Reliability, Async Work & Scalability Basics

5–8h

Learning outcomes: Recognize reliability and scalability issues that appear when moving from demo to real usage, and judge when queues, retries, or concurrency controls are needed.

Row IDWhat you learnResources
M1-L6.1

Sync vs. Async: A synchronous request makes the caller wait until the work finishes; an asynchronous request replies immediately and finishes the work separately.

Queues and Workers: A queue holds jobs waiting to run, and a worker is a separate process that pulls jobs off the queue and runs them.

M1-L6.2

Retries and Backoff: A retry tries the same request again after a failure, and backoff spaces those retries out so a struggling service gets a chance to recover.

Timeouts: A timeout limits how long a caller waits for a response before giving up, instead of waiting forever.

Idempotency: An idempotent operation gives the same end result no matter how many times you run it, so retrying it safely never causes duplicates.

M1-L6.3

Race Conditions: A race condition happens when two things try to read and change the same data at almost the same time, and the order they happen to finish in changes the result.

Connection Limits and Pooling: A connection pool is a small set of already-open connections an app keeps ready to reuse, instead of opening a new one for every request, because a database can only handle so many connections at once.

M1-L6.4

Caching: A cache is a copy of data kept somewhere fast to reach, so the app does not redo slow work every time the same data is needed again.

Load Balancing and Horizontal Scaling: When one server cannot handle the traffic, you either make that server bigger (vertical scaling) or run more copies and split the traffic between them (horizontal scaling), which needs a load balancer.

Database Bottlenecks: App servers are easy to add because they are stateless, but the database holds the actual state, so it is often the real limit once an app has scaled out.

M2 · AI Application Engineering Full handbook

Goal: turn LLMs from “chat tools” into verifiable, integrable application capabilities. Use a Tutor / Customer Support RAG case to establish foundations in prompting, RAG, tool calling, evaluation, and guardrails.

6 lessons · 28–43h · Skip mastered modules based on the entry assessment

Lesson 1 · LLM Application Foundations: From Chat to Programmatic Use

4–6h

Learning outcomes: Call an LLM from code, explain model inputs and outputs, and understand that good chat behavior does not equal system reliability.

Row IDWhat you learnResources
M2-L1.1

Large Language Models (LLMs) and Next-Token Prediction: A large language model (LLM) is a program trained on huge amounts of text to predict the next small chunk of text, so it writes answers piece by piece from learned patterns instead of looking facts up.

M2-L1.2

Tokens and Context Windows: A token is the chunk of text a language model reads and writes, and the context window is the fixed number of tokens one request can hold, including the model's reply.

M2-L1.3

LLM APIs (Requests, Responses, Streaming, SDKs): An LLM API is the web interface your code uses to send a model ID, instructions and messages to a hosted model and get back its reply, token usage and the reason it stopped, all at once or streamed.

M2-L1.4

Message Roles, System Prompts and Conversation History: An LLM request is an ordered list of messages tagged by who wrote them, and because the model remembers nothing between calls, your app resends the conversation every turn.

M2-L1.5

Generation Settings (Temperature, Top-p, Max Tokens, Reasoning Effort): Generation settings are the per-request dials that shape a model's reply: how random its word choices are, how long it may run, where it stops, and how much it thinks first.

M2-L1.6

Hallucinations and Other Model Output Failures: A model reply can fail in four distinct ways (hallucination, format drift, instruction conflict and missing context), each with its own cause and its own fix in a different part of the system.

M2-L1.7

Chat Behavior vs System Reliability: A good chat answer shows a model can do a task, not that it will do it correctly every time, unattended and at volume, inside software that trusts whatever comes back.

M2-L1.8

Programmatic LLM Interfaces (Inputs, Outputs, Errors, Retries, Logs): A programmatic LLM interface turns a plain-language task, like "classify this email," into an ordinary function with checked inputs, one output shape, named errors, capped retries and a log record per call.

M2-L1.9

Adding an LLM Endpoint to an Existing Service: An LLM endpoint is one narrow new route in an existing backend, such as POST /triage, that calls a model behind cost limits, turns each model outcome into a clear HTTP response, and can be switched off.

Lesson 2 · Prompting, Context & Structured Output

4–6h

Learning outcomes: Design reusable prompts and structured-output contracts, and explain why prompts may fail in different contexts.

Row IDWhat you learnResources
M2-L2.1

Prompt Structure: Prompt structure is the checklist of parts a production prompt spells out (role, objective, context, constraints, examples, output format and refusal conditions) so the model does the same job the same way on every request.

M2-L2.2

Few-Shot Examples: Few-shot examples are sample inputs paired with the exact outputs you want, placed in the prompt so the model copies their format, labels and tone without retraining.

M2-L2.3

Reusable Prompt Templates: A reusable prompt template is a prompt written once as a file, with fixed instructions and named blanks that your code fills with each request's data and checks before sending.

M2-L2.4

Context Engineering: Context engineering is deciding what information the model receives on each call, from which source and at what moment, so it gets the smallest set of facts that is still enough for the task.

M2-L2.5

Context Pollution and Context Rot: Context rot is the gradual drop in answer quality as a prompt grows longer; context pollution is the drop caused by irrelevant, stale or conflicting material in it. Neither produces an error.

M2-L2.6

Structured Output and JSON Schema: Structured output means the model returns data in a shape your code defined in advance, usually a JSON Schema of fields, types and allowed values, so software can use the reply directly.

M2-L2.7

Prompt Brittleness and Portability: A brittle prompt works where it was written but fails when the wording, model, inputs or context change; a portable prompt keeps behaving the same across those changes, and only testing shows which you have.

M2-L2.8

Prompt Versioning and Experimentation: Prompt versioning gives every prompt change a permanent version ID and a written reason, and experimentation means testing one change at a time while recording exactly what ran and what came out.

Lesson 3 · RAG & Knowledge Bases: Tutor / Support Assistant

6–9h

Learning outcomes: Build a basic RAG assistant that cites sources, identifies knowledge gaps, and escalates to a human when evidence is insufficient.

Row IDWhat you learnResources
M2-L3.1

Retrieval-Augmented Generation (RAG): Retrieval-augmented generation (RAG) is a pattern where, for each question, the application searches an index of your documents, places the most relevant passages in the prompt, and has the model answer from them with sources.

M2-L3.2

Knowledge Base Preparation (Source Selection, Parsing, Cleaning): Knowledge base preparation is choosing which documents an assistant may answer from, converting them into clean text that keeps headings and tables, and checking they cover what real users ask.

M2-L3.3

Chunking: Chunking is splitting each document into smaller, self-contained pieces called chunks, which are embedded and searched separately so retrieval can hand the model only the passages that answer a question.

M2-L3.4

Embeddings and Vector Search: An embedding is a list of numbers that places a piece of text by its meaning, and vector search finds the stored embeddings closest to a question's embedding.

M2-L3.5

Metadata, Filtering and Freshness: Metadata is the labels stored with each chunk, such as version, status and audience; filters use them to decide which chunks may be retrieved at all, and freshness keeps the index matching the current documents.

M2-L3.6

Hybrid Search, Reranking and Query Rewriting: Hybrid search runs keyword and meaning-based search together and merges the results, a reranker reorders the top candidates more carefully, and query rewriting fixes the question first, so the right chunks reach the model.

M2-L3.7

Grounding and Citations: Grounding means an answer may use only the sources supplied with the request, and citations tie each claim to the exact chunk it came from, so a person or a program can check it.

M2-L3.8

Knowledge Gaps and Insufficient Evidence: A knowledge gap is a question your sources cannot answer; handling it means detecting missing or conflicting evidence, saying "that is not in our material" instead of guessing, and logging the gap so someone fills it.

M2-L3.9

RAG vs Alternatives (Long Context, Fine-Tuning, Databases, APIs): RAG is one way to give a model facts it lacks, alongside long context, fine-tuning, database queries and live API calls, and a good assistant sends each question to the source that owns the answer.

M2-L3.10Practice Practice (no handbook page): turn course materials, FAQs, policies or product documentation into a Tutor / Customer Support Assistant that cites its sources and says so when the evidence is missing.

Lesson 4 · Tool Calling & Deterministic Logic

5–8h

Learning outcomes: Separate model judgment from deterministic execution, design a verifiable tool, and enable the LLM to call it correctly.

Row IDWhat you learnResources
M2-L4.1

Tool Calling (Function Calling): Tool calling (also called function calling) lets a model ask your application to run a named operation with structured arguments, such as an order lookup, while your code decides whether to run it and does the work.

M2-L4.2

The Tool-Call Loop and Tool Traces: The tool-call loop is the repeated round trip in which a model requests a tool, your code runs it and returns the result under the call's ID, and a trace records each step.

M2-L4.3

Model Judgment vs Deterministic Code: In a reliable AI feature, the model handles fuzzy language work, like reading intent or pulling facts out of messy text, while ordinary code handles anything with one rule-defined right answer, such as money or dates.

M2-L4.4

Regular Expressions (Regex) and Checksums: A regular expression is a short pattern that describes the shape a value must have, and a checksum is a small calculation over its digits that catches typos, so code, not the model, decides whether an ID is well formed.

M2-L4.5

Tool Schemas and Tool Design: A tool definition is the name, description and parameter schema a model reads to decide when and how to call your code, and good tool design makes those calls hard to get wrong and easy to test.

M2-L4.6

Tool Argument Validation: Tool argument validation is the set of checks your tool code runs on every argument the model proposes, confirming the values make sense against real data and business rules, before anything is changed.

M2-L4.7

Tool Results and Error Returns: A tool result is what your code sends back to the model after a tool runs or is rejected, and it must say clearly whether the tool succeeded, found nothing or failed, and what to do next.

M2-L4.8

Read-Only Lookup Tools: A read-only lookup tool lets an AI assistant fetch one current fact, such as a grade, an order status or a ticket status, from the system that owns it, without changing anything.

Lesson 5 · AI Evaluation: Proving It Actually Works

5–8h

Learning outcomes: Build a minimum viable evaluation set, document failure cases, and use evidence rather than intuition to judge whether changes improve the system.

Row IDWhat you learnResources
M2-L5.1

AI Evaluation (Evals): An eval is a repeatable test of an AI feature: realistic inputs with expected outcomes written down in advance, graded automatically where possible, giving a score you can compare after every change.

M2-L5.2

Evaluation Sets (Normal, Edge, Failure, Adversarial Cases): An evaluation set is a versioned list of realistic inputs for an AI feature, each paired with the behavior it should show, such as answering with a cited source, refusing, escalating or calling a specific tool.

M2-L5.3

Error Analysis and Failure Case Documentation: Error analysis means reading a sample of an AI feature's real outputs, noting what went wrong in each failure, and grouping and counting those notes to decide what to fix first.

M2-L5.4

Core Evaluation Metrics (Accuracy, Completeness, Format Compliance, Refusals, Latency, Cost): Core evaluation metrics are the separate numbers an eval run reports (accuracy, completeness, format compliance, refusal behavior, latency and cost), each held to its own threshold agreed with the client.

M2-L5.5

RAG Evaluation (Retrieval Quality, Groundedness, Source Support): RAG evaluation scores a retrieval-based assistant across a whole eval set in separate stages: whether search found the right sources, whether every claim is backed by them, and whether each citation supports its claim.

M2-L5.6

Human Evaluation: Human evaluation means people, ideally domain experts, grading a sample of AI outputs against a written guideline, pass or fail with a reason for each, to define what good means and produce labels the team can trust.

M2-L5.7

LLM-as-Judge: LLM-as-judge means using a second language model with a written rubric to grade another model's outputs at scale, and trusting its verdicts only after measuring how often they agree with human experts.

M2-L5.8

Regression Testing for Prompts, Models, Tools and Data: Regression testing means re-running the same evaluation set after any change to a prompt, model, tool or indexed data, and comparing each case with an approved baseline to confirm that what used to work still works.

Lesson 6 · Safety, Guardrails & Human-in-the-Loop

4–6h

Learning outcomes: Define basic safety boundaries and human checkpoints for an AI application, without confusing “the model can answer” with “the model is allowed to act.”

Row IDWhat you learnResources
M2-L6.1

Input and Output Guardrails: A guardrail is a check in your own code on what goes into the model, what comes out and what it tries to do, so the model never has the final say.

M2-L6.2

Content Boundaries and Sensitive Requests: A content boundary policy is a written, client-approved list of what an AI assistant will answer, redirect, refuse or hand to a person, precise enough to enforce and test.

M2-L6.3

Sensitive Data and PII Protection: Sensitive data protection means keeping personal information and confidential business data out of every place an AI feature does not need it, from the prompt and provider to logs, traces and replies.

M2-L6.4

Prompt Injection and Jailbreaks: Prompt injection is text the model reads, from a user or hidden in a document or tool result, that overrides your app's instructions, while a jailbreak talks the model past its own safety rules.

M2-L6.5

Unauthorized Requests, Per-User Access and Action Gates: A model that can answer a request is not thereby allowed to act on it, so code checks every tool call against the signed-in user's permissions and hard limits before anything runs.

M2-L6.6

Human-in-the-Loop Approval: Human-in-the-loop approval is a checkpoint where your code pauses a specific, already permitted AI action until a person confirms it, reserved for actions that are costly or hard to undo.

M2-L6.7

Refusals and Fallbacks: A refusal is the designed reply when a request is out of bounds, and a fallback is the designed reply when something breaks; both give a short reason and a next step.

M2-L6.8

Escalation Paths and Human Takeover: An escalation path is the designed route that hands a conversation from an AI assistant to the right person, triggered by code checks and carrying a summary, after which the assistant goes quiet.

M2-L6.9

Documenting Known Limitations: Documenting known limitations means writing down, from evidence, what an AI assistant cannot do or cannot be trusted with, then telling users where it matters and the client in writing.

M2-L6.10Practice Practice (no handbook page): add escalation on checkable signals (not the model's self-rated confidence), sensitive-request blocking and human takeover to the Tutor / Support Assistant.

M3 · Agent Engineering — From Prompts to Scalable Agent Systems Full handbook

Goal: define an agent as a job with real boundaries (Profile, with Knowledge kept separate), give it reusable Skills backed by code where steps must repeat exactly, choose between a workflow, a single agent and multiple agents, then make its state, long-running work and failures manageable. An agent is not merely a prompt, and more agents do not automatically mean a better system.

6 lessons · 31–49h · Skip mastered modules based on the entry assessment

Lesson 1 · Start with Profile.md: Define an Agent with Real Boundaries

4–6h

Learning outcomes: Define an agent with clear boundaries from business responsibilities rather than writing a one-line role prompt.

Row IDWhat you learnResources
M3-L1.1

AI Agents: An AI agent is a system where a language model picks its own next step (which tool to call, what to do with the result, when to stop) in a loop toward a goal, inside limits set by code.

M3-L1.2

Agent Profiles (Profile.md): An agent profile is a short document that defines an agent as a job (role, objective, responsibilities, prohibited actions, inputs, outputs, escalation conditions and success criteria), written from the business process it serves, not a one-line persona.

M3-L1.3

Separating Agent Knowledge from the Profile: Separating knowledge from the profile means an agent's profile defines how it behaves and where to look things up, while facts like prices and policies stay in owned sources it reads at run time.

M3-L1.4

Agent Responsibilities and Prohibited Actions: Responsibilities say which work an agent owns, only drafts or leaves to others; prohibited actions say what it must never do, each enforced by a withheld tool, a code check or an approval.

M3-L1.5

Agent Inputs, Outputs and Escalation Conditions: An agent's inputs, outputs and escalation conditions are the part of its profile that says what it needs to start, what it must hand back with a status, and when to stop and pass the decision on.

M3-L1.6

Agent Success Criteria and Definition of Done: Success criteria say in measurable terms, before you build, what good work from an agent looks like; the definition of done is the checklist each run must pass before the agent stops.

M3-L1.7Practice Practice (no handbook page): write minimal profiles for Content Research, Draft and Review agents and compare their responsibilities.

Lesson 2 · Skills: Decompose Agent Capabilities into Reusable Units

5–8h

Learning outcomes: Decompose a complex agent into maintainable, testable, reusable skills and identify where code is required.

Row IDWhat you learnResources
M3-L2.1

Agent Skills: An agent skill is a named, reusable package of steps, checks and optional scripts for one kind of task, such as comparing peers or writing a memo, that an agent loads only when a task calls for it.

M3-L2.2

SKILL.md Files and Progressive Disclosure: A SKILL.md file is the Markdown file that packages one skill: a short header says what the skill does and when to use it, and progressive disclosure means the agent reads the rest only when needed.

M3-L2.3

Skill Decomposition: Skill decomposition is breaking an agent's growing all-in-one prompt into separate skills, each owning one step with an input and output you can name and test, while the profile keeps rules that apply everywhere.

M3-L2.4

Skill Inputs, Outputs and Checks: A skill's inputs, outputs and checks are its written contract: what it needs to start, the named result it returns in a fixed structure, and the tests that result must pass before anyone uses it.

M3-L2.5

Instruction-Only vs Code-Backed Skills: An instruction-only skill is Markdown guidance the model follows with its own judgment; a code-backed skill also bundles scripts the agent runs for steps that must repeat exactly, such as parsing or calculating.

M3-L2.6

Skill Composition and Versioning: Skill composition runs several skills as one flow, each output feeding the next; skill versioning gives every change a permanent ID, so production runs a tested version and can roll back.

M3-L2.7Practice Practice (no handbook page): decompose a content-creation flow into research, outline, draft, review and revise skills.

Lesson 3 · Workflow, Single Agent, or Multi-Agent?

6–9h

Learning outcomes: Choose the simplest viable architecture based on task complexity and risk, and justify the design with business reasons rather than “multi-agent is more advanced.”

Row IDWhat you learnResources
M3-L3.1

Workflows vs Agents: In a workflow, code fixes which steps run and in what order, and a model fills in individual steps; in an agent, the model decides the next step itself, including which tool to use and when it is done.

M3-L3.2

Workflow Patterns (Chaining, Routing, Parallelization): Workflow patterns are fixed ways to connect model calls in ordinary code: chaining runs steps in order with checks between them, routing sends each input down one specialized path, and parallelization runs calls at once and merges the results.

M3-L3.3

Single-Agent Systems: A single-agent system is one AI agent, with its profile, skills and tools, working in one loop where it picks each next step until the task is done, it needs a person, or a limit stops it.

M3-L3.4

Multi-Agent Systems: A multi-agent system splits one task across several AI agents, each with its own instructions, context and tools, gaining parallel work and cleaner contexts at the cost of more tokens and harder coordination.

M3-L3.5

Choosing an Agent Architecture: Choosing an agent architecture means picking the simplest design that reliably does the job (from plain code up to several agents) and defending that choice with evidence about risk, cost and reliability.

M3-L3.6

Splitting Work Across Agents: Splitting work across agents means giving a responsibility its own agent only when it needs an isolated context, different tools or permissions, independent review or parallel runs; otherwise it stays a skill or a function.

M3-L3.7

Handoffs and Agent Contracts: A handoff passes work from one agent to another; an agent contract is the agreed, checkable format for that exchange: the task, required inputs, structured result, and a status with errors.

M3-L3.8

Review and Critic Patterns: A review or critic pattern adds a step that checks work against explicit criteria before it moves on, sends failures back for revision, and stops when the criteria pass or a limit is reached.

M3-L3.9Practice Practice (no handbook page): map a Content Operations flow (Research, Plan, Draft, Review) and mark each step as deterministic code, LLM or human, with a reason for each.

Lesson 4 · State, Memory & Context Persistence

5–8h

Learning outcomes: Design state and memory boundaries for agents, and distinguish “a lot of context” from reliable persistence.

Row IDWhat you learnResources
M3-L4.1

Agent State and Memory Types: An agent works from five kinds of information (this call's context, the conversation, the task's progress, facts about the user and knowledge kept across tasks), each with its own lifetime, owner and store.

M3-L4.2

Context vs Durable Persistence: Context is what the model sees in one call, rebuilt by your app each time; durable persistence is storage outside the process that still holds the task after a crash, redeploy or new session.

M3-L4.3

Conversation Threads and Sessions: A conversation thread, often called a session, is the stored, ordered record of one conversation, with its own ID and owner, that your app loads and extends every turn so the chat can resume later.

M3-L4.4

Task State (Plans, Progress, Artifacts): Task state is the stored record of where one job stands (goal, plan, finished and pending steps, outputs, open decisions and budget used), kept outside the model and updated by code so work can resume after a pause or failure.

M3-L4.5

Long-Term and User Memory: User memory is what an agent keeps about one person (preferences, confirmed constraints, decisions); long-term memory is what it keeps from past work (prior analyses, lessons); both live outside the model, scoped and loaded by your code.

M3-L4.6

Memory Write Policies: A memory write policy is the set of rules, enforced by code, that decide what an agent may save to memory, on whose word, with what source and review date, and how new facts replace old ones.

M3-L4.7

Memory Pollution, Staleness and Privacy Risks: Agent memory goes wrong in three ways: wrong or planted facts keep resurfacing, true facts go out of date while still being used, and personal data is kept too long or shown to the wrong person.

M3-L4.8

Persistence Patterns (Workspace, Landing Pad, Journal): Three storage patterns let agent work survive restarts: a workspace for one task's working files, a landing pad where finished outputs wait for the next step or a person, and a journal recording each step and decision.

M3-L4.9Practice Practice (no handbook page): let a Content or Finance agent remember prior analysis, user preferences and confirmed constraints, each stored with its source and date.

Lesson 5 · Persistent Agents: Queues, Recovery, Concurrency & HITL

6–10h

Learning outcomes: Understand persistent-agent execution and explain how tasks are queued, recovered, deduplicated, and paused for human approval at critical points.

Row IDWhat you learnResources
M3-L5.1

Persistent Agents: A persistent agent is an agent whose task outlives one request and one process: the work is queued, progress is saved after every step, and the task can wait for days or survive a crash or deploy, then continue.

M3-L5.2

Durable Execution (Checkpoints, Replay, Recovery): Durable execution runs a multi-step task so each finished step and its result are saved outside the process, letting another worker continue after a crash, redeploy or restart instead of starting over.

M3-L5.3

Agent Task Queues and Workers: An agent task queue holds each agent task until a worker finishes it; configured well, it keeps tasks through crashes, sets aside repeat failures, serves urgent work first and paces model calls to rate limits.

M3-L5.4

Bounded Execution (Budgets, Step Limits, Trigger Control): Bounded execution means code caps what any agent task can consume (steps, tokens, dollars and time), stops tasks that loop or stall, and decides which events may start a model call.

M3-L5.5

Duplicate Execution and Deduplication: Duplicate execution is a persistent agent repeating a step after a retry, crash or repeated message; deduplication lets the repeat recognize the first attempt, so a refund, email or booking happens only once.

M3-L5.6

Concurrency and Stale State in Agent Systems: Concurrency problems arise when two agent runs, or an agent and a person, change the same task or record at once; stale state is acting on data that changed after it was read.

M3-L5.7

Pausing Agents for Human Approval: Pausing an agent for human approval means saving its state and the exact action it proposes, releasing the worker that ran it, and resuming from that point when a person decides, minutes or days later.

M3-L5.8

Recovery Testing (Failure Injection): Recovery testing means breaking a persistent agent on purpose mid-task (killing its worker, dropping a model reply, delivering a message twice), then checking that it resumes at the right step without sending, paying or updating anything twice.

M3-L5.9Practice Practice (no handbook page): build a recoverable persistent agent on Puffo/Pavlov or an equivalent runtime, kill a worker mid-task, and confirm it resumes with no duplicate side effects.

Lesson 6 · Agent Evaluation, Tracing & Debugging

5–8h

Learning outcomes: Locate failures within an agent workflow and use traces/evaluations—not endless prompt rewriting—to fix them.

Row IDWhat you learnResources
M3-L6.1

Agent Evaluation (Tasks, Environments, Outcomes): Agent evaluation runs an agent on whole, realistic tasks in a test copy of its systems, grades what changed there rather than what it said, and repeats each task because runs vary.

M3-L6.2

Agent Traces (Steps, Tool Calls, Handoffs, State Changes): An agent trace is the step-by-step record of one task across agents and workers: every model call, tool call, handoff and state change, with inputs, outputs, errors, timing and tokens, under one trace ID.

M3-L6.3

Failure Attribution in Agent Systems: Failure attribution means finding the first step where an agent run went wrong and naming which part caused it: data, instructions, the model, a tool, a handoff, a business rule, a permission or a limit.

M3-L6.4

Agent-Level Metrics (Task Completion, Handoffs, Tool Use, Loops, Cost, Latency): Agent-level metrics show how well an agent system does whole tasks: how often it completes them, how cleanly it hands off and uses tools, how often it loops, and what each completed task costs in money and time.

M3-L6.5

Trajectory Evaluation: Trajectory evaluation grades the steps an agent took in a run (tools called, arguments, order, handoffs), not just where it ended, so lucky passes and rule breaks along the way get caught.

M3-L6.6

Replayable Tests for Agent Workflows: A replayable test turns one agent run into a scenario you can rerun: the same input, starting state and recorded tool responses, checked against the expected outcome and key steps, without touching live systems.

M3-L6.7

Debugging Agents with Traces and Evals: Debugging an agent means reproducing a failure, finding the first wrong step in its trace, fixing the cause in its own layer (often not the prompt), and proving the fix with a new test and an eval run.

M4 · Enterprise Integration & Production AI Full handbook

Goal: show that real customer environments involve data, APIs, permissions, security, deployment, observability, cost, and reliability beyond prompts and agents. Learners should know when deeper engineering is required.

5 lessons · 27–42h · Skip mastered modules based on the entry assessment

Lesson 1 · External APIs, MCP & Connector Design

6–9h

Learning outcomes: Explain the difference between APIs and MCP, and connect external data or actions to agents through clear, replaceable interfaces.

Row IDWhat you learnResources
M4-L1.1

MCP and Traditional API Connectors: The Model Context Protocol (MCP) standardizes how a model discovers and calls tools, but it does not replace the real work of authentication, networking, and failure handling that any connection to an external system still requires.

M4-L1.2

Tool Registries, Schemas & Capability Discovery: A tool registry lists the tools available to an agent, each described by a schema (its inputs, outputs, and purpose), and capability discovery is how a client learns at runtime what a server can do, so third-party and commercial tools can plug into the same slot.

M4-L1.3

API Versions, Rate Limits & Fallback Sources: External APIs change versions, cap how often you can call them, and sometimes charge per call, so a durable integration pins versions, respects rate limits, and has fallback sources rather than hard-coding one vendor's current behavior into business logic.

M4-L1.4

Designing a Minimal Connector Contract: A connector contract is the small, explicit definition of how a tool or API is exposed to an agent, its inputs, outputs, error types, authentication, and rate limits, and designing it well is what makes an integration predictable, swappable, and safe.

Lesson 2 · Authentication, Authorization, RBAC & Secrets

5–8h

Learning outcomes: Design a basic permission model and understand that prompts cannot replace real authentication and authorization controls.

Row IDWhat you learnResources
M4-L2.1

Authentication vs Authorization: Keys, OAuth, Sessions & Tokens: Authentication proves who a caller is; authorization decides what they may do; and the common mechanisms, API keys, OAuth tokens, sessions, and JWTs, are the concrete ways systems carry that identity and permission with each request.

M4-L2.2

RBAC, Least Privilege & Read/Write Permissions: Role-Based Access Control grants permissions through roles, least privilege means giving each identity only the access it needs, and distinguishing read from write access is the most basic and important line, especially for what different agents and users can view versus execute.

M4-L2.3

Secret Management, Environment Variables & Rotation: Secrets (API keys, passwords, tokens) must live outside code in a secure store, be injected at runtime via environment variables or a vault, never be written to logs, and be rotated on a schedule and immediately after any exposure.

M4-L2.4

Human-in-the-Loop Tied to Permissions: High-risk actions should require explicit human approval enforced by the permission system, not by asking the model nicely in a prompt, because a prompt is not a security control and a probabilistic system must not be the final authority on consequential actions.

M4-L2.5

Enterprise SSO (SAML/OIDC) & Service Accounts: Enterprise single sign-on lets employees authenticate through the company's identity provider using SAML or OIDC, and service accounts are non-human identities for machines, an FDE's integration almost always authenticates as a service account, not as a person.

Lesson 3 · Real-World Data: Quality, Freshness, Provenance & Entity Resolution

6–9h

Learning outcomes: Identify major risks in real data, design provenance/freshness/entity-alignment rules, and clearly state which conclusions remain unverified.

Row IDWhat you learnResources
M4-L3.1

Dirty Data: Missing, Duplicate, Stale & Conflicting: Real customer data is missing values, duplicates, stale records, conflicting entries, and inconsistent formats, which is fundamentally different from the clean sample data a demo runs on, and assuming otherwise is how solutions break in production.

M4-L3.2

Freshness Gates, Provenance & Data Lineage: Freshness gates reject or flag data that's too old to trust, provenance records where each value came from, and lineage traces how data moved and transformed, so every conclusion the system produces can be traced back to a trustworthy source.

M4-L3.3

Entity Resolution: Entity resolution is figuring out when records in different systems refer to the same real-world thing, the same person, company, or product, and aligning their IDs, using matching rules and merge policies, so data can be joined reliably across systems.

M4-L3.4

Worked Example: Provider-Directory Data Quality: A healthcare provider directory, names, specialties, and contact details for doctors, shows every real-world data problem at once, and walking through cleaning it (deduplication, specialty validation, contact freshness, human confirmation) makes the abstract data-quality concepts concrete.

M4-L3.5

Data Contracts & Schema Evolution: A data contract is an explicit, validated agreement on the field names, types, and meaning of data exchanged between systems, and schema evolution is changing that shape over time without silently breaking the systems that depend on it.

M4-L3.6

PII/PHI Handling & Compliance Basics (SOC 2, GDPR, HIPAA): Personal and health data must be minimized, protected, and kept within legal limits on what may be stored, logged, or sent to a model API, and an FDE needs baseline awareness of SOC 2, GDPR, and HIPAA to work safely on Healthcare and Finance engagements.

Lesson 4 · Reliability, Cost, Latency & Scale

5–8h

Learning outcomes: Make basic performance and cost trade-offs and recognize when a demo architecture can no longer support real users.

Row IDWhat you learnResources
M4-L4.1

Reliability: Timeouts, Retries, Fallbacks, Circuit Breakers, Batching & Caching: Model and API calls fail, slow down, and rate-limit, so production reliability comes from timeouts, retries with backoff, fallbacks, circuit breakers, batching, and caching, the standard toolkit for staying up when a dependency doesn't.

M4-L4.2

Cost Model: Tokens, Model Choice & When to Use Code: AI features cost money per token, per model, per API call, per unit of storage and compute, so controlling cost means measuring token usage, right-sizing the model, caching, and using cheaper deterministic code wherever it can do the job.

M4-L4.3

Latency Budgets & Parallelization: A latency budget is the total time a response is allowed to take, and because sequential agents, multi-turn calls, and tool chains add up fast, you manage it with streaming, trimming, and parallelizing independent steps, accepting the added complexity that parallelism brings.

M4-L4.4

Scaling Concepts: Concurrency, Bottlenecks & Horizontal Scaling: Scaling is what happens when many users hit the system at once, and the judgment that matters is spotting where it will bottleneck (queue depth, database, or API limits) and knowing that horizontal scaling and queues, not heroics, are the usual answer, without needing to build a giant cluster yourself.

Lesson 5 · Deployment, CI/CD, Observability & Production Readiness

5–8h

Learning outcomes: Explain what an AI application still needs to move from a local demo to an internal pilot and production, and produce basic deployment/run evidence.

Row IDWhat you learnResources
M4-L5.1

Build, Test, Deploy & Rollback: CI/CD Basics: CI/CD is the automated flow that takes code from commit to production, build, test, deploy, and roll back if something's wrong, and an FDE needs to understand the flow and use it, not hand-build complex pipelines.

M4-L5.2

Logs, Metrics, Traces, Health Checks & Alerts: Observability is answering "what is the system doing right now, and is it healthy?" from the outside, through logs (events), metrics (numbers over time), traces (one request's path), health checks (is it up?), and alerts (tell me when something's wrong).

M4-L5.3

Version Records: Model, Prompt, Data, Tools & Config: Recording the versions of everything that shapes behavior, model, prompt, data, tools, and configuration, is what lets you reproduce the exact state the system was in during an incident, and change any one of them deliberately rather than silently.

M4-L5.4

Demo → MVP → Pilot → Production Maturity Ladder: Software matures through stages, demo, MVP, pilot, then production, and each stage demands more engineering and governance (reliability, security, observability, support), so knowing where you are tells you what's required next and prevents treating a demo like a product.

M5 · FDE Discovery, Consulting & Delivery Full handbook

Goal: train the core capabilities that distinguish an FDE from a typical AI Engineer—entering ambiguous customer environments, finding the real problem, defining outcomes, managing scope, making technical/business trade-offs, and driving pilots, acceptance, handoff, and productization.

7 lessons · 39–62h · Skip mastered modules based on the entry assessment

Lesson 1 · The FDE Role & End-to-End Delivery Lifecycle

4–6h

Learning outcomes: Understand the full scope of FDE work, recognize that technical capability is only one part, and complete a personal skill-gap assessment.

Row IDWhat you learnResources
M5-L1.1

The FDE Role vs Adjacent Roles: A Forward Deployed Engineer builds and ships working software inside a single customer's systems to solve their specific problem, distinct from SWEs, AI Engineers, Solutions Engineers, pre-sales, implementation, consulting, and outsourcing, each of which owns only part of what an FDE does.

M5-L1.2

The End-to-End Delivery Lifecycle: An FDE engagement runs a full arc, Qualify → Discover → Scope → Design → Build → Evaluate → Pilot → Handoff → Product Feedback, and knowing the whole arc keeps you from jumping to building before you understand, or stopping before the work is handed off and its lessons fed back.

M5-L1.3

Outcome Ownership vs Time-and-Materials: FDE work is measured by the outcome delivered, not the hours billed, which is why the role is not simply "on-site coding", you own that the customer's problem gets solved, not just that you showed up and wrote code.

M5-L1.4

The FDE Capability Model: Eight Dimensions: An FDE's skills span eight dimensions, Systems, AI, Agents, Integration, Production, Discovery, Communication, and Domain, and different FDE roles weight them differently, so knowing the model helps you see what "good" looks like and where to grow.

M5-L1.5

Working Inside Customer Environments: FDE work happens in the customer's world, their systems, data access, permissions, and test environments, and the practical skill is obtaining access early and unblocking the typical obstacles (provisioning delays, security review, missing test data) before they stall the build.

Lesson 2 · Customer Discovery & Stakeholder Interviews

6–9h

Learning outcomes: Run a structured discovery session, identify key stakeholders, real problems, and information gaps, and produce reviewable interview notes.

Row IDWhat you learnResources
M5-L2.1

Discovery Interviews: A discovery interview systematically uncovers the customer's business goals, current workflow, pain points, constraints, supporting evidence, and who actually decides, so you understand the real problem before proposing a solution.

M5-L2.2

Questioning Technique: 5 Whys, Facts vs Opinions vs Incentives: Good discovery uses open-ended questions and the "5 Whys" to get from symptom to root cause, and it carefully separates facts from opinions from incentives, never treating the customer's first statement as the requirement.

M5-L2.3

Stakeholder Mapping: Stakeholder mapping identifies everyone who affects or is affected by the project, decision makers, users, technical owners, data owners, security/legal, and skeptics, so you know whose buy-in you need, whose access you depend on, and whose concerns could block you.

M5-L2.4

Reconciling Conflicting Stakeholder Answers: Business, IT, operations, and finance will describe the same problem differently, and reconciling those conflicting answers, understanding why each sees it their way and finding the shared truth, is a core discovery skill, not a sign someone is wrong.

Lesson 3 · As-Is / To-Be Workflow Mapping & Requirement Decomposition

5–8h

Learning outcomes: Translate ambiguous requests into clear business workflows and identify where AI should actually intervene.

Row IDWhat you learnResources
M5-L3.1

Mapping a Workflow: Actors, Steps, Inputs, Outputs, Decisions, Handoffs: Mapping a workflow means breaking a customer's process into its actors, steps, inputs, outputs, decision points, pain points, and handoffs, so you see exactly how work actually flows before deciding what to change.

M5-L3.2

Allocating Steps: Automation, AI, Deterministic Code or Human: Once a workflow is mapped, each step is best handled by one of four things, simple automation, an AI model, deterministic code, or a human, and matching each step to the right one is the heart of designing an AI-assisted workflow.

M5-L3.3

Decomposing “Build an AI Agent” into Atomic Tasks: A vague ask like "build an AI agent" has to be decomposed into atomic tasks with their dependencies and failure boundaries, so the work becomes estimable, buildable, and safe, with clear points where a failure is contained rather than cascading.

M5-L3.4

As-Is vs To-Be: Documenting the Process Change: As-Is is how the workflow runs today; To-Be is how it will run after your solution; and documenting both, the business-process change, not just the software feature, is what makes the value clear and the change adoptable.

Lesson 4 · Scope, PRD/SOW, Acceptance Criteria & Non-Goals

5–8h

Learning outcomes: Write an implementable and testable mini PRD/SOW and protect the project from unlimited scope creep.

Row IDWhat you learnResources
M5-L4.1

Scope: Problem, Users, MVP, Must/Nice-to-Have, Non-Goals: Scoping turns discovery into an agreed plan, the problem statement, target user, MVP, must-haves vs nice-to-haves, explicit non-goals, and dependencies, so everyone commits to the same thing and the smallest valuable version ships first.

M5-L4.2

PRD vs SOW: A PRD (Product Requirements Document) describes what to build and why; an SOW (Statement of Work) is a contractual document defining project scope, mutual responsibilities, milestones, acceptance evidence, and how changes are handled, and an FDE engagement often needs both.

M5-L4.3

Requirement Types: Functional, Non-Functional & Constraints: Requirements come in three kinds, functional (what it must do), non-functional (how well: speed, reliability, security), and constraints (fixed limits like data access, security, timeline), and classifying each and placing it in the PRD/SOW prevents shipping a feature that works but can't be deployed.

M5-L4.4

Measurable Acceptance Criteria: Acceptance criteria define, in measurable terms, what proves a deliverable is done, its inputs, expected outputs, quality bar, latency, risk handling, and human-review requirements, so "done" is an objective test rather than an opinion.

M5-L4.5

Classifying New Requests: Clarification, Change or Future Phase: When a new request arrives mid-project, classify it, a clarification of existing scope, a formal change to scope, or future-phase work, and record it accordingly, so scope stays controlled and nothing is silently absorbed or lost.

Lesson 5 · Solution Architecture: Choose the Simplest Architecture That Works

5–8h

Learning outcomes: Choose the minimum viable architecture based on customer value, time, risk, and team capability, and explain how it can evolve later.

Row IDWhat you learnResources
M5-L5.1

The Architecture Decision Tree: Start with the simplest architecture that could work and escalate only when needed, rules/scripts → web app → RAG → tool calling → workflow → single agent → multi-agent, because each step up adds capability but also cost, latency, and failure surface.

M5-L5.2

Build vs Buy vs Configure: For each part of a solution, decide whether to build it custom, buy an existing product, or configure an existing platform, and know when to use a platform like Puffo/Pavlov versus a codebase, an MCP, or custom services, so you spend build effort only where it creates unique value.

M5-L5.3

Architecture Hypothesis: Assumptions, Risks & Tech Debt: Turn requirements into an explicit architecture hypothesis, "we believe this design will work because…", and document the assumptions it rests on, the risks that could break it, and the technical debt you're knowingly taking on, so the design can be tested and revisited rather than treated as fact.

M5-L5.4

Avoiding Premature Optimization (and What You Can't Defer): Defer the engineering complexity that isn't needed yet, scale, caching, elaborate abstractions, but never defer the security and data baselines, because those are expensive or impossible to retrofit and cause real harm if skipped.

Lesson 6 · Demo, Feedback & Change Management

4–7h

Learning outcomes: Run a demo for non-technical stakeholders and clearly explain trade-offs when new requests appear instead of agreeing unconditionally.

Row IDWhat you learnResources
M5-L6.1

Demo-Driven Development: Demo-driven development means showing a narrow, working, end-to-end path on a regular cadence rather than accumulating features for one big final reveal, so misunderstandings surface early while they're cheap to fix.

M5-L6.2

Show Real Failures, Not Clean-Data Theater: In demos and reviews, show the system's real failures, limitations, and next steps rather than a curated happy path on clean data, because honest failure-showing builds trust and surfaces problems early, while "clean-data theater" hides risk until production.

M5-L6.3

Negotiating Trade-offs & Saying No Without Losing Trust: When a request would break scope, timeline, or a working system, present the technical constraint and the time/cost options and negotiate a trade-off, saying no constructively (usually "yes, and here's the cost" or "not this phase") rather than either caving or refusing flatly.

M5-L6.4

Close the Loop: Feedback → Issue → Priority → Decision → Change Log: Feedback is only useful if it's closed into a loop, captured as an issue, prioritized, decided on, and recorded in a change log, so nothing is lost, decisions are traceable, and the customer sees their input acted on.

M5-L6.5

Written Status Communication: Regular written status updates, weekly progress and clear risk flags, keep remote stakeholders aligned without meetings, and doing them well (concise, honest, leading with risks and asks) is a quiet superpower in customer-facing work.

Lesson 7 · Pilot, Value, Handoff & Productization

10–16h

Learning outcomes: Design both business and technical metrics for a pilot and use evidence to explain project value and uncertainty. Hand a project over so others can run it and extract reusable assets rather than keeping all knowledge in one person’s head.

Row IDWhat you learnResources
M5-L7.1

Designing a Pilot: A pilot is a controlled rollout to real users doing real work, with a defined duration, success criteria, and a go/no-go decision at the end, so you learn how the solution performs in reality before committing to full production.

M5-L7.2

Baseline, Success Metrics, North Star & Attribution: Prove value against a baseline measured before the project, using success metrics tied to the business outcome and a North Star metric that captures overall value, and be honest about attribution, don't treat model metrics as if they were direct business value.

M5-L7.3

User-Adoption Friction: A working solution fails if people don't use it, and adoption friction, workflow changes, training needs, trust, the burden of human review, and organizational resistance, is what stands between a shipped system and a used one.

M5-L7.4

Measuring Value & ROI: ROI translates the solution's impact into business terms, time and cost savings, revenue gains, and risk reduction, while being honest about the strength of the evidence and what can't be attributed to the solution.

M5-L7.5

The Handoff Package: A handoff package is everything the customer's team needs to run the solution without you, setup, operation, permissions, inputs/outputs, common failures, restart and fallback procedures, and known limitations, and it's what determines whether your work survives after you leave.

M5-L7.6

Postmortem: A postmortem is an honest written retrospective, what broke, why it broke, what changed, and how to prevent recurrence, done blamelessly and never turned into success marketing, so a finished engagement (or an incident) produces durable lessons.

M5-L7.7

Separating Customer-Specific Logic from Reusable Assets: After delivery, separate what's specific to this customer from what's reusable, prompts, skills, eval sets, connectors, and templates, so the reusable pieces become assets that make the next engagement cheaper and faster.

M5-L7.8

Feeding Learnings Back to Product: Field learnings from an engagement, what customers really need, where the product fell short, what had to be built around it, should flow back to the product team in a prioritized, actionable way, so the product improves and each subsequent deployment gets cheaper.

M6 · Four Representative FDE Use-Case Archetypes

Goal: use four realistic cases of increasing complexity to repeatedly demonstrate the same FDE methodology. Industry is the context; the focus is understanding why different business problems require different levels of technical depth.

4 lessons · 27–40h · Skip mastered modules based on the entry assessment

Lesson 1 · Education Tutor / Customer Support: RAG Application

6–9h

Learning outcomes: Understand and build one of the simplest enterprise AI applications, and recognize when RAG alone is sufficient.

Row IDWhat you learnResources
M6-L1.1

Case Overview: Tutor / Support RAG: A tutor or support assistant answers questions from course materials, FAQs, policies and past Q&A, cites the passage behind every answer, says so when the sources do not cover the question, and hands off to a person when it should.

M6-L1.2

Technical Design: Course Support Assistant: A reference design for a grounded support assistant: a versioned knowledge base that owns the facts, retrieval that produces evidence, a model that only restates and cites, and policy code that decides when to answer, refuse or escalate.

    M6-L1.3

    PRD: Course Support Assistant: A reference PRD for a tutor / support assistant that answers student and customer questions from an education business's own documents, cites the passage behind every answer, refuses what the documents do not cover, and hands sensitive cases to a person.

      M6-L1.4

      Reference Build: Support RAG on n8n: The Technical Design built as three n8n workflows (ingest, answer, evaluate), with every gate in a deterministic node, every citation checked in code, and a clear list of what n8n does not do for you.

      M6-L1.5

      Extension: From RAG to Support Agent: Giving the assistant tools such as course-status lookup, order lookup and ticket creation turns a read-only RAG system into a support agent, and every tool that changes something brings permissions, confirmation and audit with it.

      Lesson 2 · Content Operations: Multi-Stage Content Production Workflow

      6–9h

      Learning outcomes: Decompose a content-operations process into agents/workflows and understand that multi-agent value comes from separation of responsibilities, not agent count.

      Row IDWhat you learnResources
      M6-L2.1

      Case Overview: Content Operations: In Puffo Marketing Studio, a marketer asks for a poster, landing page or slide deck in plain language, four agents with separate jobs and separate models turn it into a reviewed HTML asset built from locked templates, and the marketer edits it in a local browser editor and exports a PNG, with no model call for a small edit.

      M6-L2.2

      Technical Design: Marketing Studio: A reference design for a multi-agent content studio: facts in owned files, copy and design as typed hand-offs, HTML built from templates as the only master, an independent reviewer whose approval is bound to the exact artifact, and interlocks that code enforces rather than agents remember.

        M6-L2.3

        PRD: Marketing Studio: The Puffo Marketing Studio MVP PRD (draft for engineering review, 27 August 2026) defines a single-client, local-first system where four agents produce HTML marketing assets that non-technical marketers edit and export without touching code.

          M6-L2.4

          Transfer: The Same Pipeline in Other Industries: The Marketing Studio pattern of intake, writing from canonical facts, independent review, templated design and human sign-off carries over to any business that produces a steady stream of rule-bound content.

            Lesson 3 · Healthcare Provider Research & Outreach: Data-Driven Prospecting

            7–10h

            Learning outcomes: Break target-customer research and outreach into a verifiable data/automation pipeline and know which information requires human confirmation.

            Row IDWhat you learnResources
            M6-L3.1

            Case Overview: Provider Research: The Provider Research Factory turns a population query such as "all urologists in the United States" into a verified dataset: five Puffo agents handle the judgment work, a deterministic Python pipeline does every fetch, filter, join and count, two human gates bracket the expensive and the risky steps, and nothing in the system can contact a provider.

            M6-L3.2

            Technical Design: Provider Research: A reference design for agent-planned, code-built data products: models decide sources, codes and objections, a deterministic pipeline does every fetch, join and count under assertions that fail the build, two human gates bracket the expensive and the risky steps, and compliance is a function that cannot be bypassed.

              M6-L3.3

              PRD: Provider Research: The Provider Research PRD (draft, 15 September 2026) defines a five-agent Puffo system that produces a defensible list of US urologists, with a definition document, a contact sheet and a build record, and with no ability to contact anyone.

                M6-L3.4

                Transfer: The Same Pipeline for Other Targets: The Provider Research method of an agreed definition, a deterministic build, an independent challenge and contact rules delivered with the rows works for any prospecting target, from doctors to schools to manufacturers.

                  Lesson 4 · Finance Research / Trading Desk: Complex Multi-Agent Decision Support

                  8–12h

                  Learning outcomes: Understand why complex agent systems need multiple roles, tools, freshness controls, memory, and evaluation, and design a simplified research desk.

                  Row IDWhat you learnResources
                  M6-L4.1

                  Case Overview: Trading Desk: The Trade Recommendation Desk is a team of six AI agents in a Puffo space that reviews a fixed pool of 10 US stocks each week, where a backend strategy engine creates every call from two market signals and the agents review, challenge and explain it, with no real money anywhere.

                  M6-L4.2

                  Adding Complexity Layer by Layer: Start from a single prompt that asks "should I buy this stock?", add only what each failure forces, and you arrive layer by layer at the Sprint 1 desk design, where every layer exists to remove one specific way the answer could be wrong.

                  Delivery Plan: Trading Desk: The Trade Recommendation Desk Delivery Plan fits the build into eight weeks for two engineers by breaking it into 35 tasks with checkable finish conditions, estimating 71 days of work against 80 available, and fixing the milestones that must happen in order.

                  M6-L4.3

                  PRD: Trading Desk: The Trade Recommendation Desk PRD (FDE Internship Program, September 2026) defines what the six-agent desk must do, under eight product rules that are never broken, and how the team will know it is finished.

                  Extension: Beyond the Internship Desk: The desk's later phases add what this version deliberately left out, and its core pattern (a deterministic backend that owns every number, agents that interpret and dissent, publishing checks and scoring against reality) carries over to other high-stakes decision-support problems.

                    M6-L4.4

                    Technical Design: Trading Desk: A reference design for multi-agent decision support over changing numbers: a deterministic backend that computes and stores every value, agents that interpret and dissent through role-scoped tools, point-in-time data with a cutoff per run, rules frozen before a one-time holdout, publishing checks on every call, and outcomes scored against what really happened.

                      M7 · FDE End-to-End Practicum Full handbook

                      Goal: learners choose an approved customer-style use case and complete a full FDE delivery from Discovery through Release/Handoff. This is the core portfolio module and is not tied to a fixed number of weeks; learners can progress based on their available effort.

                      6 lessons · 52–78h · Skip mastered modules based on the entry assessment

                      Lesson 1 · Practicum Kickoff: Discovery & Project Selection

                      6–10h

                      Learning outcomes: Produce an approved Problem Brief and Discovery Pack demonstrating that the project is worth designing and building.

                      Row IDWhat you learnResources
                      M7-L1.1

                      Project Selection: Project selection is choosing one realistic customer problem, from an approved domain, that you can take from discovery to handoff, and getting a Problem Brief signed off before you build anything.

                      M7-L1.2

                      Discovery Pack: The Discovery Pack is the bundle of five short documents that proves you understand the customer's problem, people, current workflow, knowledge gaps and dependencies before you design anything.

                      M7-L1.3

                      Project Validation: Project validation is a written check that your project is real, solvable, valuable and deliverable within your time and data limits, done before you commit to building.

                      M7-L1.4

                      Go / No-Go Decision: The go or no-go decision is the checkpoint where you read your validation evidence and choose one of four paths: proceed, scope down, change projects, or run a validation experiment first.

                      Lesson 2 · Architecture & MVP Freeze

                      10–14h

                      Learning outcomes: Produce an executable MVP design and explain each architecture choice, technical debt item, and deferred feature.

                      Row IDWhat you learnResources
                      M7-L2.1

                      Mini PRD and Risk Register: The mini PRD is a two-page statement of what you will build and how you will know it works, and the risk register lists what could stop you, each with an owner and a response.

                      M7-L2.2

                      Solution Architecture Map: The solution architecture map is a one-page picture of your system's components, data flow, tools, memory and human checkpoints, drawn so another person can review it before you build.

                      M7-L2.3

                      Configure, Skill or Code: For each capability in your MVP, you decide whether to get it by platform configuration, a reusable Skill, custom code, or by deliberately deferring it.

                      M7-L2.4

                      MVP Freeze and Change Control: An MVP freeze locks the scope after architecture review, and change control is the small routine that decides what happens to every request that arrives afterward.

                      Lesson 3 · Alpha Build: Complete the First End-to-End Happy Path

                      12–18h

                      Learning outcomes: Complete a reproducible Alpha Release proving that the core business path runs from input to output.

                      Row IDWhat you learnResources
                      M7-L3.1

                      Thin End-to-End Slice: A thin end-to-end slice is one narrow question that travels the whole system, from user input to final answer, before you build anything else.

                      M7-L3.2

                      Reproducible Setup: A reproducible setup is a recorded recipe, covering profile, skills, code, tools, data and settings, that lets someone else rebuild your alpha from scratch and get the same behavior.

                      M7-L3.3

                      Run Log and Failure Triage: A run log records what the system did at each step of each test run, and triage means fixing the failures that block the real workflow before anything else.

                      M7-L3.4

                      Alpha Pass Condition: The alpha passes when another person, using only your instructions, can run the system from input to final output.

                      Lesson 4 · Evaluation & Hardening

                      10–14h

                      Learning outcomes: Complete a Beta with evaluation results, a failure report, and prioritized reliability improvements—not just a successful demo path.

                      Row IDWhat you learnResources
                      M7-L4.1

                      Evaluation Set and Baseline: An evaluation set is a fixed list of test cases covering normal, edge and failure situations, and the baseline is the score your alpha gets on it before you change anything.

                      M7-L4.2

                      Failure Attribution Report: A failure attribution report says, for each failing eval case, which part of the system caused it, so you fix the cause and not the symptom.

                      M7-L4.3

                      Targeted Hardening: Targeted hardening means adding a protection, such as a guardrail, fallback or retry, only where an observed failure or a named risk calls for it.

                      M7-L4.4

                      Known Limitations and Fix List: Known limitations are the problems you did not fix, written down honestly, paired with a prioritized list of what to fix next.

                      Lesson 5 · Pilot / Proxy User Testing & Release Candidate

                      8–12h

                      Learning outcomes: Use real or proxy-user evidence to determine whether the system is worth continuing and complete a demonstrable Release Candidate.

                      Row IDWhat you learnResources
                      M7-L5.1

                      Proxy User Testing: Proxy user testing means asking real users, or people who closely resemble them, to complete realistic tasks on your system while you watch and take notes.

                      M7-L5.2

                      Feedback Triage: Feedback triage is sorting what testers told you into dislikes, real bugs, and missing requirements, so you fix the right things and skip the rest on purpose.

                      M7-L5.3

                      Regression Rerun: A regression rerun means running your critical evaluation cases again after fixes, to prove you did not break something that used to work.

                      M7-L5.4

                      Release Candidate: A release candidate is the version you believe is ready to hand over, frozen and labeled, with its evidence, open issues, and next steps written down.

                      Lesson 6 · Client Demo, Stakeholder Defense, Handoff & Postmortem

                      6–10h

                      Learning outcomes: Complete an end-to-end FDE project suitable for interviews and a portfolio, demonstrating not only agent building but full delivery ownership.

                      Row IDWhat you learnResources
                      M7-L6.1

                      Client Demo Narrative: The client demo narrative is the fixed order in which you tell the story of your project: problem, old workflow, solution, live system, evidence, limits, and value.

                      M7-L6.2

                      Stakeholder Pressure Test: The stakeholder pressure test is a live Q and A where a reviewer plays the client and pushes with new requests and objections, and you answer with time, cost, and risk instead of agreeing to everything.

                      M7-L6.3

                      Handoff Package Submission: The handoff package submission is the folder you give the client so their own people can run, restart, and understand the system without you.

                      M7-L6.4

                      Individual Postmortem: An individual postmortem is your own written review of the project: what failed, why, what you would change, and which parts you can reuse for the next customer.

                      M8 · Career Preparation & FDE Interviews Full handbook

                      Goal: turn real curriculum and practicum outputs into verifiable job-search evidence, and prepare for common FDE interviews covering engineering, system design, problem decomposition, customer communication, and project deep dives.

                      4 lessons · 15–25h · Skip mastered modules based on the entry assessment

                      Lesson 1 · Portfolio, Case Study & Resume Packaging

                      4–6h

                      Learning outcomes: Turn course outputs into a credible, explainable, and verifiable FDE resume and portfolio.

                      Row IDWhat you learnResources
                      M8-L1.1

                      Case Study Structure: A case study is a written account of one project in a fixed order — Problem → Discovery → Architecture → Trade-offs → Build → Eval → Failure → Outcome → Next Step — so a reader can follow your judgment, not just your output.

                      M8-L1.2

                      Evidence-Based Resume Bullets: A resume bullet earns its place when it states scope, data, interfaces, evaluation, and outcome — five concrete facts a reviewer could check — instead of a verb attached to a buzzword such as "Built an AI agent."

                      M8-L1.3

                      Maturity Labeling: Every project you present carries one of four labels — Demo, MVP, Pilot, or Production — and presenting work at a higher label than it earned is the single fastest way to lose an interviewer's trust.

                      M8-L1.4

                      Portfolio Composition: An FDE portfolio is one in-depth capstone written as a full case study plus three smaller case artifacts, each proving a different capability, all labeled by maturity and all linked to something a reviewer can open.

                      Lesson 2 · Coding / Debugging & System Design Interviews

                      4–7h

                      Learning outcomes: Explain and modify code in interviews and complete practical system designs aligned with FDE work.

                      Row IDWhat you learnResources
                      M8-L2.1

                      Practical Coding and Debugging Round: FDE coding rounds test whether you can read unfamiliar code, find and fix a bug, integrate an API with proper error handling, and explain every decision — including the ones you made with an AI coding tool — not whether you can recall algorithm patterns.

                      M8-L2.2

                      End-to-End AI System Design: The FDE system design round asks you to design a real customer deployment across frontend, backend, data, tools, agents, state, auth, deployment, and observability, and it scores the trade-offs you name more than the boxes you draw.

                      M8-L2.3

                      MVP-First Design Evolution: In a design round you start with the thinnest end-to-end path that proves the risky part, then add components one at a time with a stated reason for each, instead of drawing a complete distributed architecture in the first five minutes.

                      M8-L2.4

                      Technical Debt and Architecture Change Stories: Every candidate should be able to explain one real technical-debt item and one real architecture change from their own project — what it was, why it was accepted or made, what it cost, and what it taught — because these two stories prove the project was real and that you were the one making decisions.

                      Lesson 3 · FDE Case: Problem Decomposition & Customer Simulation

                      4–7h

                      Learning outcomes: Structure ambiguous customer problems, propose verifiable solutions, and communicate with non-technical stakeholders.

                      Row IDWhat you learnResources
                      M8-L3.1

                      Ambiguous Problem Clarification: When a customer says "use AI to improve sales / efficiency / research quality," the first ten minutes belong to six questions — objective, users, workflow, data, baseline, constraints — and the interviewer is scoring whether you ask them before you propose anything.

                      M8-L3.2

                      Live Scoping: Live scoping is stating, in the room, what the first version will do, what it will not do, how it will be validated, and when you will stop — a verbal PRD with non-goals that turns a decomposed problem into a plan the customer can say yes or no to.

                      M8-L3.3

                      Stakeholder Simulation: The client-simulation round puts you across the table from a role-played skeptic, technical owner, or business owner, and scores whether you change how you explain, what you commit to, and how you push back for each one — without changing what is true.

                      M8-L3.4

                      Handling Unknowns: When you do not know, the scored answer is "I don't know yet — here is how I would find out in a week": acknowledge the gap, name the cheapest experiment that closes it, and give a date, instead of inventing a confident answer on the spot.

                      Lesson 4 · Role Matching, Interview Narrative & Job-Search Strategy

                      3–5h

                      Learning outcomes: Define a personal job-market position, project narrative, and follow-up skill-gap roadmap, and identify which FDE/adjacent roles fit best.

                      Row IDWhat you learnResources
                      M8-L4.1

                      FDE and Adjacent Roles: Forward Deployed Engineer, Applied AI Engineer, Solutions Engineer, AI Consultant, and their neighbors are told apart not by whether they write code but by three questions from Module 0 — does the code reach production, do field lessons feed a product the company owns, and is the role measured on outcomes — and knowing which answers you want decides where you apply and how you tell your story.

                      M8-L4.2

                      Background-Based Narratives: Your interview narrative is a bridge from what you have already done to FDE work — Domain Expert → FDE, Backend → FDE, AI Engineer → FDE, Startup Generalist → FDE — and the strongest bridge is "I have already done this work informally; here is the evidence."

                      M8-L4.3

                      STAR and Project Deep Dives: Behavioral rounds and project deep dives are the same skill from two directions: STAR gives a 60–90-second story a shape (Situation, Task, Action, Result), and the FDE version adds judgment, trade-offs, failure, and retrospective so the interviewer hears how you decide, not just what happened.

                      M8-L4.4

                      Skill-Gap Learning Plan: A skill-gap plan rates yourself on the eight FDE capability dimensions at one of four proficiency levels — Know, Use, Build, Design — compares that against the roles you are targeting, and turns the difference into a short, dated list of things to build, not things to read.