intermediateAI
LLM Workflows That Hold Up
Loops, tools, skills and subagents — and knowing which one the problem needs.
19 lessons3h 14m5 sections
Need to Know HQPractical engineering courses, written by people who ship$39.99
- Lifetime access to all lessons
- 19 lessons across 5 sections
- Progress tracking across devices
What you'll learn
- Choose between a single call, a workflow and an agent — and defend the choice
- Build an agent loop that terminates, recovers from failures and stays affordable
- Design a tool surface your harness can gate, audit and parallelize
- Use skills and subagents where they pay, and skip them where they don't
- Keep a long-running loop inside its context window without losing the thread
Course content
5 sections · 19 lessons · 3h 14m
Choosing a shapeThe most expensive mistakes happen before any code is written.4 lessons
- Single call, workflow, agentFree preview11m
Read this lesson
Three tiers, in ascending order of power and descending order of predictability. A **single call** handles classification, extraction, summarization, rewriting — anything where one input maps to one output. Most production LLM usage is this, and should be. A **workflow** is multiple calls wired together by *your* code. You decide what runs next. Prompt chaining (each step's output feeds the next), routing (classify, then dispatch to a specialist prompt), parallelization (fan out, then aggregate), evaluator-optimizer (generate, critique, revise). The control flow is in a language with a debugger. An **agent** is a model deciding what runs next, in a loop, with tools. You give it a goal and it plans its own path. The rule: **use the simplest tier that solves the problem.** Agents are for tasks that are genuinely hard to specify in advance — "fix this failing test suite", where the steps depend on what you find. If you can draw the flowchart, build the flowchart. It will be cheaper, faster, and it will fail in ways you can reproduce. - Four questions before you build an agentFree preview9m
Read this lesson
Ask all four, and take a "no" seriously. **Complexity** — is the task multi-step and hard to fully specify up front? If you can enumerate the steps, an agent is overhead. **Value** — does the outcome justify the cost and latency? An agent run can be twenty model calls. That's fine for a code migration and absurd for a support-ticket tag. **Viability** — is the model actually good at this class of task today? Test on ten real examples before you architect around an assumption. **Cost of error** — can mistakes be caught and undone? Tests, review, rollback, a staging environment. An agent acting irreversibly on production data with no gate is not a design, it's an incident with a launch date. The pattern in the failures: teams answer yes to complexity and never ask the other three. - The loop, precisely12m
- Termination is a design problem10m
Tools4 lessons
- Your tool surface is your security boundary13m
- Descriptions are the trigger, not the documentation11m
- Errors are context, not exceptions9m
- Too many tools, and what to do about it10m
Context3 lessons
- The prefix rule, and the money it costs12m
- Compaction, clearing, and memory12m
- Write the memory file for the next reader9m
Skills and subagents3 lessons
- Skills: instructions that load when relevant11m
- Subagents: what you actually buy12m
- Fan-out patterns that work10m
Running it for real5 lessons
- Evaluate, or you are guessing12m
- Cost and latency levers, ranked11m
- Failure modes and what they look like11m
- Humans in the loop, placed well9m
- Where to go next
Requirements
- Comfortable reading code in any language
- You have called a model API at least once, or watched someone do it
Description
The gap between a demo and a system that runs unattended is not model quality. It is loop
design, tool design, context management, and knowing which of those to reach for.
This course covers the patterns that survive contact with production: the agent loop and
what terminates it, tools as a security boundary rather than a feature list, skills as
on-demand instructions, subagents as a cost multiplier you deploy deliberately, and the
context-management techniques that keep an eight-hour run coherent. It is opinionated about
when *not* to use each one, because that is where most of the money is lost.