Healthcare
Claims Processing Agent
A document-heavy claims workflow where policy rules, human review, and a complete audit trail are the product, and the model is the smallest part.
documentspolicyhuman review
COURSE 001 · FDE ENGINEERING
Learn how to design agents whose work survives failures, restarts, long waits and changing context.
Course content and API examples last verified: 2026-08 · exact dependency versions live in the reference repo lockfile
You build one canonical system, the Vendor Review Agent, all the way through. The concepts are grounded in five industry cases along the way: incident investigation, claims and document workflows, customer operations, enterprise data, and coding agents. One app to build, five systems to understand.
Healthcare
A document-heavy claims workflow where policy rules, human review, and a complete audit trail are the product, and the model is the smallest part.
documentspolicyhuman review
SaaS
An operations agent that acts on customer accounts through real APIs, where every action is a side effect someone has to approve, dedupe, or reverse.
tool permissionsside effectsidempotency
Financial Services
A question-answering agent over enterprise data where the hard problems are permissions, business definitions, and proving the answers are right.
context engineeringdata permissionsSQL
Developer Tools
A coding agent that migrates a large codebase over many sessions, with plans, parallel workers, and verification that does not take "I finished" on faith.
coding agentsplanningrepository context
Enterprise Operations
A production investigation agent that fans out across logs, metrics, deploys and tickets, survives partial failure, and synthesizes a defensible incident narrative.
parallel executionpartial failurelong-running agents
Each module answers one production question. Watch or read to follow the course completely; the labs and the repo are optional depth.
When is an agent worth this much engineering?
Forty lines that work. Every line is a promise you cannot keep.
The agent says it finished. Prove it.
Your worker disappeared. Did the job?
The customer got two refunds. The agent swears it sent one.
Two workers picked up the same investigation.
The log store is down. Should the investigation die?
The approver is at lunch. For three hours.
The agent read forty pages and got dumber.
The run looks dead. Is it?
The vendor's website is talking to your agent.
Version B feels better. Feels.
The framework says it handles all this.
Every credible system has the same skeleton.
Push to main, mid-run.
Everything fails at once. That is the exam.
Python
The whole reference implementation; modules 00-02 are plain Python so the loop is visible.
LangGraph
Graph execution, persistence, checkpoints and interrupts, adopted in Module 03 after the failures make them necessary.
PostgreSQL
Durable state, leases, event log, side-effect records. The load-bearing component.
FastAPI + HTMX
The run API, review endpoints and operator dashboard, with no frontend framework.
Render + Neon
The free-tier public deployment whose restarts double as failure injection.
14 Failure Labs break the running system on purpose: kill the worker, duplicate the publish, poison a page, race two workers. Entirely optional; the lessons describe each failure well enough to learn from without running anything.
The Vendor Review Agent lives in an open repo with the fixture server the labs run against. Clone it if you want your hands on the system; skip it if you are here to watch and read.
Every module links one to three primary sources with a sentence on why each is worth your time. The full annotated list lives on the course sources page, and the site-wide library is at /resources.
Local progress only: your Watched/Read marks and exit-criteria checklists live in this browser, never on a server.