How to use this course
Five minutes now saves you from wandering later. Here is the shape of the whole thing, what each kind of page is for, and the one habit that decides whether any of it sticks.
Bring one real system with you
This course is built around a system you already have or want to build: a support assistant, a doc-QA tool over your own content, an internal agent, anything real. Every project asks you to apply that module to it. Learners who bring a real system finish with a design document. Learners who read along finish with notes.
If you genuinely have nothing, use the worked designs in the capstone as your subject and design one of them properly.
The modules run in one direction
Each module answers one of the four production questions, and they build.
| Module | The question it answers |
|---|---|
| Workflows and Agents | Who is driving, your code or the model, and how much freedom does it get? |
| Context Engineering and Retrieval | What goes into the window, and how does the right thing get found? |
| Cost, Latency and Reliability | What does a request cost, how slow is it, and what happens when it fails? |
| Agent Architecture and Security | What can the agent actually do, and what stops it doing more? |
| Evals and Observability | How would you know it got worse before your users tell you? |
| Shipping It | What has to be true before this goes live? |
| Capstone: Worked LLM System Designs | The whole method, run end to end on six real systems |
The order is deliberate. You cannot budget a system before you know its shape, you cannot secure an agent before you know what it can reach, and you cannot evaluate any of it before you have decided what good looks like.
Six kinds of page, each doing a different job
Each page type has a job, and they run roughly in that order inside every module.
| Kind | What it is | Where it sits |
|---|---|---|
| Lesson | One idea, with a diagram or a table where it helps | In sequence |
| Cheat sheet | A one-page reference for fast recall | End of its module |
| Lab | A hands-on build, specified end to end with acceptance criteria | After the cheat sheet |
| Project | An artifact you produce about your own system | End of the module where the work is done |
| Field guide | A survey of the real tools in that space, with a decision rule | Last in its module |
| Worked design | A complete LLM system reasoned end to end | The capstone |
Lessons teach, cheat sheets remind, labs build the muscle, field guides stop you adopting on vibes, and the projects are where you actually change.
The labs are TypeScript, and the provider is behind one seam
Each lab is specified end to end: the steps, the acceptance criteria, and the shape of the code. The companion repo, github.com/ehsangazar/llms-and-agents-labs, is TypeScript, and it currently ships a full starter, worked solution and test suite for the workflow router lab; the other five you build in your own codebase against the spec in the lesson.
Whichever way you build them, put every model call behind a single module rather than scattering them through the codebase.
// common/llm.ts: one seam, so swapping provider or model is a one-line change
export interface LlmRequest {
system: string;
user: string;
model: "small" | "large";
maxTokens: number;
}
export interface LlmResult {
text: string;
inputTokens: number;
outputTokens: number;
ms: number;
}
export async function complete(req: LlmRequest): Promise<LlmResult> {
// The rest of the course depends on this signature, not on any one provider.
// Cost, caching, fallback and tracing all wrap this single function.
}That seam is not a coding style preference. Half of what this course teaches (budgets, caching, fallback ladders, tracing, evals) is implemented by wrapping exactly one function. If model calls are scattered across forty files, none of it is possible.
A lesson is not done when you have read it
It is done when you can say the trade-off out loud and name the one thing that would change your mind. Reading builds recognition. Saying it back builds the judgment you are actually here for.
The cheapest version of that habit: after each lesson, write one sentence about your own system in the form "we will do X, which costs us Y, and I would change it if Z." That sentence is the raw material for every project.
Recap
- Bring one real system. Every project applies the module to it, and the projects are where the learning lands.
- Six kinds of page: lessons teach, cheat sheets remind, labs build, projects produce, field guides help you choose, worked designs show the method whole.
- Labs are TypeScript with the provider behind one seam, because budgets, caching, fallback and tracing all wrap that one function.
- Next: lesson 0.3, the idea the whole course hangs on.