# How to become a forward deployed engineer A practical FDE learning path: 29 milestones across software foundations, customer discovery, integrations, applied AI, production, and portfolio work. Canonical: https://fdelab.dev/learn/ Build one customer workflow from discovery through handoff. These original exercises ask for working evidence, not just completed reading. The milestones are self-assessed and do not guarantee hiring. [Use the interactive learning plan](https://fdelab.dev/workspace/#learn) - [Build a software foundation](https://fdelab.dev/learn/#foundation) - [Understand the workflow first](https://fdelab.dev/learn/#discovery) - [Connect data and systems](https://fdelab.dev/learn/#integration) - [Build an AI workflow you can evaluate](https://fdelab.dev/learn/#ai) - [Make it work after the demo](https://fdelab.dev/learn/#production) - [Turn the work into a credible application](https://fdelab.dev/learn/#career) ## Build a software foundation Make code a tool you can rely on. If you already build software professionally, use the exercises as a diagnostic and spend time only on the gaps. Outcome: A small application that you can run, test, debug, and explain without following a tutorial. ### Write and debug a useful program Learn variables, functions, lists and dictionaries, file I/O, exceptions, and unit tests. Read stack traces and use a debugger. Choose Python for this path; it is a practical starting choice, not a universal FDE requirement. Practice: Build a command-line tool that reads a CSV of support tickets, validates required fields, groups tickets by category, and exports a report. Add empty-file, malformed-row, and duplicate-ID cases. Evidence: You can explain each transformation and show tests for both normal and malformed inputs. - [CS50’s Introduction to Programming with Python](https://cs50.harvard.edu/python/) [Work on this milestone](https://fdelab.dev/workspace/#lesson-programming) ### Work in a shared codebase Practise commits, branches, diffs, merges, and reverting a change. Learn shell navigation, environment variables, dependency isolation, and how to keep secrets out of a repository. Practice: Put your ticket tool in Git. Make a feature branch, introduce and fix a failing test, then write a setup guide. Ask a peer to run it from a fresh checkout. Evidence: A second person can install and run it, and the history explains the changes. - [Pro Git](https://git-scm.com/book/en/v2) [Work on this milestone](https://fdelab.dev/workspace/#lesson-workflow) ### Make the result usable Understand the browser/server boundary, HTTP methods and status codes, JSON, and basic HTML. Learn enough JavaScript to send a request and present loading, empty, success, and error states. Practice: Build a small page that accepts a ticket file or text input and shows the results. Make an error understandable to someone who did not write the code. Evidence: The interface can be used with a keyboard and makes failures visible. - [Learn web development](https://developer.mozilla.org/en-US/docs/Learn_web_development) - [Full Stack Open](https://fullstackopen.com/en/part0/general_info/) [Work on this milestone](https://fdelab.dev/workspace/#lesson-web-basics) ### Direct AI work and verify it Agent Factory describes two uses of a general agent: solving a task in a session and helping build a worker that runs independently. Its 10-80-10 rule is a planning heuristic for human direction, AI execution, and human review; it is not a measured allocation of time. Practice: Give an assistant the ticket-tool task with three acceptance examples. Inspect its diff, run the examples, and explain one incorrect assumption. Log time spent specifying, generating, and correcting. Evidence: You can reproduce the result and explain the code, its boundaries, and the checks you used. Faster generation alone is not the success measure. - [The AI Agent Factory: About](https://agentfactory.panaversity.org/docs/about) - [Pro Git](https://git-scm.com/book/en/v2) - [How to Learn from This Book](https://agentfactory.panaversity.org/docs/how-to-learn-from-this-book) [Work on this milestone](https://fdelab.dev/workspace/#lesson-direct-and-review) Stage review: Change the input format without following a tutorial. Can you isolate the failure, update the implementation, and prove the fix with a test? ## Understand the workflow first An FDE needs to discover what is worth building. Practise listening, mapping the current process, and narrowing a request into a deliverable. Outcome: An evidence ledger, stakeholder map, approved delivery specification, and a justified workflow redesign. ### Run a discovery conversation Ask about the last time a task happened, rather than whether someone likes your idea. Understand the trigger, steps, exceptions, current tools, and who is accountable. Record assumptions separately from observations. Practice: Interview a willing user for 20 minutes, or run a clearly labelled simulation. Ask them to walk through a recent task. Write a workflow map and identify one costly handoff. Evidence: Your notes distinguish what the user said, what you observed, and what you still need to verify. - [Using in-depth interviews](https://www.gov.uk/service-manual/user-research/using-in-depth-interviews) [Work on this milestone](https://fdelab.dev/workspace/#lesson-interview-user) ### Define a small, testable outcome Choose one user and one workflow. Define the current baseline, the desired outcome, and how you will measure it. Ask about data access, approval, budget, and the person who accepts the delivery. Practice: Write a one-page brief: problem, user, current process, proposed slice, non-goals, data access, success test, and owner. For a simulation, choose a synthetic dataset and state its limits. Evidence: A reviewer can decide whether the project succeeded without relying on your demo narrative. - [Using in-depth interviews](https://www.gov.uk/service-manual/user-research/using-in-depth-interviews) [Work on this milestone](https://fdelab.dev/workspace/#lesson-scope) ### Explain a technical trade-off Compare a manual process, a deterministic automation, and an AI-assisted workflow. Explain trade-offs in accuracy, cost, latency, and maintenance. Learn to report a blocker with a decision or next step. Practice: Write a short decision record choosing the simplest viable approach. Then send a simulated weekly update: result, next step, blocker, and decision needed. Evidence: Your recommendation is understandable to a nontechnical decision-maker and states what would change your mind. - [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents) - [Is This an Agent Problem?](https://agentfactory.panaversity.org/docs/is-this-an-agent-problem) [Work on this milestone](https://fdelab.dev/workspace/#lesson-tradeoffs) ### Validate the brief before committing Buehling calls unverified understanding discovery debt. Compare the sponsor’s request with operator evidence, technical constraints, and the real reason for the deadline. Connect goals, scope, risk, time, and budget before promising delivery. Practice: Create an evidence ledger with claim, source, confidence, owner, and next check. Test three claims from a fictional AI-written brief. Map the sponsor, daily operator, system owner, and acceptance owner; record one disagreement. Evidence: Every critical assumption has evidence or an unresolved decision. Write a conditional commitment: “We can deliver this slice if access is approved by this date; otherwise we reduce scope or pause.” - [Forward Deployed — Richard Buehling (February 2026)](https://fdelab.dev/workspace/#ref-benmore) - [Using in-depth interviews](https://www.gov.uk/service-manual/user-research/using-in-depth-interviews) [Work on this milestone](https://fdelab.dev/workspace/#lesson-discovery-debt) ### Write a specification a reviewer can test Write observable behavior before implementation. Link each requirement to evidence and an acceptance check. Keep the approved intent and the actual implementation aligned when new information changes the work. Practice: Specify one ticket-routing slice: input schema, output, denied actions, error handling, latency and cost budget, reviewer, and three acceptance examples. Change one customer constraint and update the affected check and decision record. Evidence: A peer can test the requirement from the document. Open questions stay visible instead of becoming invented requirements. - [Spec-Driven Development](https://agentfactory.panaversity.org/docs/spec-driven-development-crash-course) - [Forward Deployed — Richard Buehling (February 2026)](https://fdelab.dev/workspace/#ref-benmore) [Work on this milestone](https://fdelab.dev/workspace/#lesson-delivery-spec) ### Decide what to preserve, change, or remove Observe the old workflow, then question why each step exists. Agent Factory’s vertical-design method distinguishes enduring obligations from steps created by older tools or organizational constraints. Validate proposed changes with the responsible operator. Assign each step to a person, AI, or a reviewed collaboration. Explain the choice using reversibility, the cost of error, and who is accountable. Practice: Map the three eligibility lookups in your project. For each, record its purpose, evidence, and a keep/change/remove recommendation. Preserve the eligibility decision while testing whether one repeated data-entry step can disappear. Name who reviews, what they check, and when review happens before the action takes effect. Give the map an owner and a review date. Evidence: The revised flow preserves required controls and has an owner-approved test. An unexplained step remains unresolved, not automatically deleted. - [Designing the Vertical System of Record](https://agentfactory.panaversity.org/docs/ecosystem/designing-the-vertical-sor) - [Workflow Design & Diagnosis](https://agentfactory.panaversity.org/docs/workflow-design-diagnosis-crash-course) [Work on this milestone](https://fdelab.dev/workspace/#lesson-redesign-work) Stage review: Have the customer change a critical assumption. Update scope, acceptance checks, time and budget implications; explain whether to proceed, narrow, or pause. ## Connect data and systems Connect your project to persistent data and an external interface. Reliability starts at the boundaries: schemas, identities, permissions, and retries. Outcome: A tested API, recoverable data flow, and governed policy register with denied-access evidence. ### Model and query the data Learn tables, primary keys, foreign keys, joins, aggregates, transactions, and indexes. Identify missing values, duplication, inconsistent timestamps, and fields that should not enter your application. Practice: Load your project data into a relational database. Create a schema, a migration, a duplicate-detection query, and a query that measures your workflow baseline. Evidence: You can explain the grain of each table and avoid double-counting when joining data. - [PostgreSQL tutorial](https://www.postgresql.org/docs/current/tutorial.html) [Work on this milestone](https://fdelab.dev/workspace/#lesson-data-model) ### Build an API with clear boundaries Define request and response schemas. Distinguish authentication from authorisation. Return meaningful status codes and avoid exposing secrets in logs or responses. Practice: Add endpoints to create, view, and update a record. Validate inputs, add a per-user permission check, and test allowed and denied requests. Use test identities locally. Evidence: Tests demonstrate that one user cannot read or change another user’s records. - [FastAPI tutorial](https://fastapi.tiangolo.com/tutorial/) - [Testing FastAPI applications](https://fastapi.tiangolo.com/tutorial/testing/) [Work on this milestone](https://fdelab.dev/workspace/#lesson-api-contract) ### Make the integration recoverable Assume remote calls can fail and events can repeat. Use bounded retries and backoff where appropriate. Define what happens after a timeout and how a caller can safely retry a write. Practice: Connect a mock customer API. Simulate paginated results, a rate-limit response, duplicate events, and a partial failure. Add a reconciliation script for the failed records. Evidence: A replay does not duplicate work, and a failed batch can resume without losing completed records. - [Testing FastAPI applications](https://fastapi.tiangolo.com/tutorial/testing/) [Work on this milestone](https://fdelab.dev/workspace/#lesson-resilience) ### Give domain knowledge an accountable owner A searchable document collection needs ownership, review, versioning, permissions, and citations to serve as governed knowledge. Agent Factory separates source evidence, a map of what exists, and complete procedures that must be followed together. Keep three source types distinct: approved rules, current values from the owning system, and supporting conversations. An index helps find evidence; it does not become the authority. Practice: Create a synthetic policy register with document ID, version, owner, approval date, review date, access group, and superseded version. Add one complete eligibility procedure. Test expired guidance, a revoked reader, and a missing required step. Assemble one context packet with the applicable policy version, live ticket facts, supporting notes, missing evidence, and citations. A chat message cannot override the approved policy. Evidence: The answer cites an approved version; unavailable authority leads to escalation. Permissions are enforced outside the model, and a procedure is never executed from a partial search excerpt. - [The FDE AF Model](https://agentfactory.panaversity.org/docs/ecosystem/fde-af-model) - [Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) - [Excessive agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) - [System of Context](https://agentfactory.panaversity.org/docs/ecosystem/system-of-context) [Work on this milestone](https://fdelab.dev/workspace/#lesson-governed-knowledge) Stage review: Replay the same event twice, deny the caller permission, and make the dependency time out. Show exactly what changed in the database for each case. ## Build an AI workflow you can evaluate Learn model APIs and tool use in the context of a useful workflow. Add autonomy only when you can show that it improves the outcome. Outcome: A bounded AI worker, a non-AI baseline, a calibrated evaluation report, and an approval-and-recovery interface. ### Start with a bounded model call Learn messages, tokens, structured output, tool calling, and schema validation. Separate a model’s suggestion from an operation your application executes. Set a usage budget before using a paid API. Practice: Add ticket classification or draft suggestions. Compare a rule-based baseline with one model call. Validate the returned schema and route uncertain or invalid outputs to human review. Evidence: The workflow behaves sensibly when the model is unavailable or returns an invalid response. - [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents) - [AI Agents Course](https://huggingface.co/learn/agents-course/en/unit0/introduction) [Work on this milestone](https://fdelab.dev/workspace/#lesson-model-workflow) ### Retrieve the right context safely Learn when keyword search, indexed retrieval, or live exploration fits. Preserve source identity, apply access controls before returning content, and handle missing or contradictory evidence. Practice: Add a small knowledge collection with source links. Include stale documents, two conflicting answers, and a document that a test user cannot access. Evidence: Your test user never receives the restricted document and can trace an answer to its source. - [Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) - [Excessive agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) [Work on this milestone](https://fdelab.dev/workspace/#lesson-retrieval) ### Measure outcomes and inspect failures Create representative tasks with expected outcomes. Separate development examples from evaluation cases. Use deterministic checks when possible and calibrate subjective judgements with human review. Practice: Create an initial set of 20–30 diverse test cases as a project exercise. Include ambiguity and adversarial input. Record completions, failure categories, latency, and cost; explain the small sample’s limits. Evidence: Your report includes failed cases and the actual resulting system state, not just a convincing model response. - [Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) [Work on this milestone](https://fdelab.dev/workspace/#lesson-evaluation) ### Turn a session task into an operable worker A useful session result does not establish that a workflow can run unattended. Specify who owns a recurring job, what wakes it, what it can change, where progress lives, and how it stops. Keep human judgment explicit at consequential boundaries. Practice: Run the ticket task from a synthetic queue. Persist job state, cap runtime and retries, require review before assignment, and expose pause/resume. Interrupt a job after a suggested route is saved and demonstrate safe recovery. Evidence: A duplicate trigger causes no duplicate assignment. The operator can see why work stopped and resume without guessing what already happened. - [The AI Agent Factory: About](https://agentfactory.panaversity.org/docs/about) - [Eval-Driven Development for AI Employees](https://agentfactory.panaversity.org/docs/eval-driven-development-crash-course) - [From One-Off to Worker](https://agentfactory.panaversity.org/docs/from-one-off-to-worker) - [Harness Engineering](https://agentfactory.panaversity.org/docs/harness-engineering-crash-course) [Work on this milestone](https://fdelab.dev/workspace/#lesson-worker-contract) ### Check the evaluator before trusting its score Tests verify specific properties; evaluation estimates behavior on a sample. A model judge can miss a bad outcome or reward a persuasive explanation. Check the final state, compare with human judgments, and keep evaluation examples separate from tuning. Practice: Label 12 held-out routing runs as correct or incorrect with a peer. Include fluent but wrong suggestions, correct but terse results, and failed writes. Compare the judge with those labels, list false passes and false failures, then revise the rubric without editing the held-out cases. Evidence: You can show a disagreement table, explain which errors the grader misses, and state where human review is still needed. Twelve examples are a calibration exercise, not production reliability evidence. - [Trusting the Checker](https://agentfactory.panaversity.org/docs/trusting-the-checker-crash-course) - [Eval-Driven Development for AI Employees](https://agentfactory.panaversity.org/docs/eval-driven-development-crash-course) - [Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) [Work on this milestone](https://fdelab.dev/workspace/#lesson-check-the-checker) ### Design a workflow people can supervise An approval screen should show the proposed change, supporting evidence, affected records, and available alternatives. Distinguish queued, running, waiting for review, failed, and completed work. Design recovery and operator access before expanding autonomy. Practice: Build a routing review screen with approve, edit, and reject actions. Seed a stale recommendation and an interrupted write. Ask a peer to use only the interface to explain the change, correct it, and recover the interrupted task. Test the same task with a keyboard and at a narrow viewport. Evidence: The reviewer sees what will happen before approving. A stale decision is revalidated, a repeated click cannot repeat the write, and the person can find the next action after a failure. Record completion time and the confusing step. - [Designing Agent Experiences](https://agentfactory.panaversity.org/docs/designing-agent-experiences-crash-course) - [Workflow Design & Diagnosis](https://agentfactory.panaversity.org/docs/workflow-design-diagnosis-crash-course) - [Learn web development](https://developer.mozilla.org/en-US/docs/Learn_web_development) [Work on this milestone](https://fdelab.dev/workspace/#lesson-review-and-recover) Stage review: Replace the model or prompt, rerun the same evaluation, and explain the change in quality, cost, and latency. Include at least one regression. ## Make it work after the demo Give your project an operational life. Make it possible to see a failure, recover from it, and hand the system to another person. Outcome: A release-gap register, reproducible deployment, recovery drill, and accepted ownership and support pack. ### Deploy reproducibly Separate code from environment-specific configuration. Pin the dependencies your build needs. Understand health checks and what a deploy changes in application and database state. Practice: Containerise the service or document an equivalent reproducible setup. Add an automated test step, a health check, and a rollback procedure. Keep a local demo mode to control cost. Evidence: You can deploy a known version and return to the previous working version. - [Get started with Docker](https://docs.docker.com/get-started/) [Work on this milestone](https://fdelab.dev/workspace/#lesson-deploy) ### See and diagnose a failure Connect a user-visible failure to the requests and dependencies involved. Record useful identifiers without exposing sensitive data. Choose measurements that correspond to the customer workflow. Practice: Add structured logs and measure task completion, p95 latency, and cost per task. Simulate a slow dependency. Create one actionable alert with an owner and a response. Evidence: You can find the failing request, identify the dependency, and describe the user impact. - [Observability signals](https://opentelemetry.io/docs/concepts/signals/) - [The Site Reliability Workbook](https://sre.google/workbook/table-of-contents/) [Work on this milestone](https://fdelab.dev/workspace/#lesson-observe) ### Transfer ownership responsibly Document setup, permissions, common failures, recovery, and operational ownership. Observe a user doing the workflow and remove friction. Describe what the system cannot yet do. Practice: Write a runbook and a short incident report from your failure exercise. Run a handoff session, ask the other person to operate the service, and capture one improvement from feedback. Evidence: A named person can operate the project without relying on your memory. - [The Site Reliability Workbook](https://sre.google/workbook/table-of-contents/) [Work on this milestone](https://fdelab.dev/workspace/#lesson-handoff) ### Close the gap between prototype and release Buehling separates prototype, specification completion, and production readiness. A convincing interface can still contain stubbed integrations, unsupported rules, and untested recovery. Keep a visible record of those gaps. Practice: Make a gap table: requirement, current behavior, placeholder, risk, evidence needed, and owner. Replace one mock dependency with a test integration. Recheck earlier acceptance cases and review the full workflow before proposing a pilot. Evidence: Every release-critical gap has been closed with evidence or explicitly excluded from the pilot. Tests and permission checks start with implementation and continue through release. - [Forward Deployed — Richard Buehling (February 2026)](https://fdelab.dev/workspace/#ref-benmore) - [Spec-Driven Development](https://agentfactory.panaversity.org/docs/spec-driven-development-crash-course) [Work on this milestone](https://fdelab.dev/workspace/#lesson-prototype-gap) ### Agree the support boundary and prove handoff Buehling’s handoff stack combines an operational runbook, a system overview, and a maintained specification tree. Receiving teams learn through changes and recovery exercises. Support needs explicit responsibilities, coverage, and an end or review point. Practice: Have a peer diagnose a seeded failure, roll back a release, and implement a small requirement change. Record the drill outcome, primary and backup owner, support hours, escalation route, exclusions, and next review date. Evidence: The receiver can operate and change the system. A named owner accepts remaining issues, and ongoing support distinguishes defect fixes from new scope. - [Forward Deployed — Richard Buehling (February 2026)](https://fdelab.dev/workspace/#ref-benmore) - [The Site Reliability Workbook](https://sre.google/workbook/table-of-contents/) - [Human-Agent Teams](https://agentfactory.panaversity.org/docs/human-agent-teams-crash-course) [Work on this milestone](https://fdelab.dev/workspace/#lesson-support-exit) Stage review: Ask a peer to recover from a simulated outage using only the runbook. Record where they got stuck and improve the instructions. ## Turn the work into a credible application Make your contribution easy to assess. Connect engineering decisions to the user’s problem and apply to roles whose responsibilities match your experience. Outcome: A reproducible case study, a bounded engagement proposal, practice interviews, and a targeted application shortlist. ### Write the project case study Explain the original workflow, your scope, the architecture, a difficult trade-off, the evaluation, and what happened after delivery. Distinguish real user outcomes from results on synthetic data. Practice: Publish a concise case study with a diagram, a runnable repository, a demo, a failure example, and the runbook. Make setup instructions the first thing a reviewer can find. Evidence: A reviewer can reproduce your evidence and understand what you personally owned. - [The AI-native interview](https://sierra.ai/blog/the-ai-native-interview) [Work on this milestone](https://fdelab.dev/workspace/#lesson-case-study) ### Practise explaining and building Practise a timed debugging task and a solution-design conversation with missing requirements. State assumptions, ask focused questions, and explain alternatives. Check AI permissions for the actual assessment. Practice: Do two mock interviews with a peer. In one, debug a broken integration. In the other, design a workflow and respond to a changed constraint. Review where your reasoning became unclear. Evidence: You can explain your code and decisions, respond to feedback, and work within the stated tool rules. - [OpenAI interview guide](https://openai.com/interview-guide/) - [Candidate AI guidance](https://www.anthropic.com/candidate-ai-guidance) - [The AI-native interview](https://sierra.ai/blog/the-ai-native-interview) [Work on this milestone](https://fdelab.dev/workspace/#lesson-practice-interview) ### Build a targeted application shortlist Read the exact requisition. Compare what you would build, the customer interaction, seniority, location eligibility, and travel. Tailor your CV around relevant ownership and outcomes. Practice: Shortlist five roles using the directory, recheck each employer page, and map three requirements per role to concrete evidence. Rewrite two CV bullets without inventing impact numbers. Evidence: Every application has a clear match, an evidence link, and explicit gaps you can discuss. - [OpenAI interview guide](https://openai.com/interview-guide/) [Work on this milestone](https://fdelab.dev/workspace/#lesson-applications) ### Present a bounded engagement or portfolio proposal Frame your work around an accepted result and the evidence you will deliver. Employment, independent client work, and a domain product require different commercial arrangements. Do not infer income or demand from a teaching framework. Practice: Write a one-page proposal for the synthetic routing pilot: sponsor, baseline, fixed scope, assumptions, access needs, acceptance, support boundary, and exclusions. Explain which generic adapter or check could be reused without customer data. Evidence: A reviewer can distinguish the deliverable, acceptance decision, recurring support, and optional expansion. Label simulated results and explain who owns any proposed reusable material. - [Forward Deployed — Richard Buehling (February 2026)](https://fdelab.dev/workspace/#ref-benmore) - [The FDE AF Model](https://agentfactory.panaversity.org/docs/ecosystem/fde-af-model) [Work on this milestone](https://fdelab.dev/workspace/#lesson-delivery-offer) Stage review: Give a peer five minutes with your case study. Can they explain the problem, your contribution, the result, and the most important limitation?