Part 0 - Map

Orientation - why agentic systems need patterns

A single model call can reason and write. It cannot remember, act, recover, or know when to stop. This track is the curriculum for closing that gap: turning a stateless completion into a reliable autonomous system. Before we build any one pattern, we need the map — what an agent actually is, the ladder of autonomy the book climbs, and why the 21 patterns ahead must be learned in dependency order rather than collected as tricks.

1 · A model is not an agent — the five-step loop

Start from the gap the book opens with. A modern LLM is extraordinary at one thing: given a context window of text, it produces a plausible continuation. But that is a single, stateless transaction. Ask it to "book my team's offsite," and it will write you a lovely description of how it would do so — then forget the entire conversation the instant the call returns. It has no calendar, no inbox, no memory of last week, and no way to notice that the venue it suggested is already full. It can advise; it cannot carry out.

The book's definition is deliberately simple: an agent is a system that perceives its environment and takes actions to achieve a goal. It is an LLM that has grown three things a bare model lacks — the ability to plan, to use tools, and to interact with an environment. The book's mental image is an assistant that learns on the job by repeating a five-step loop:

The key word is loop. Step 5 feeds back into step 2: the agent acts, observes what changed, and decides again. A chatbot is steps 3–4 run exactly once with no memory; an agent runs the whole cycle until the goal is met or it decides to stop. That single architectural difference — a feedback loop carrying state — is the seed of everything in this track. Every one of the 21 patterns ahead is a named way to make one edge of that loop stronger or safer.

2 · The autonomy ladder — Level 0 to Level 3

The book frames the last two years as a paradigm shift from "simple automation" to "complex autonomous systems," and it gives that shift a ladder. Each rung adds exactly one new capability — which is precisely the structure this course imitates. Read the ladder as a sequence of capabilities the agent is allowed to gain, because every capability is also a new way to fail.

The book's worked Level-2 example is the one we will carry through the entire course. A software-engineering agent receives a bug report. It reads the report and the codebase, then distills a large pile of information into a focused context — only the files, symbols, and error lines that matter — so it can write, test, and submit a correct patch. That distillation is context engineering, and the book promotes it to a first-class skill (Appendix A and the reasoning chapter): the way to push accuracy up is to give the model short, focused, relevant context rather than dumping everything in. A separate Level-2 example makes the same point: a travel assistant connected to your inbox extracts just the flight number, date, and location from a long confirmation email before handing that to a calendar and weather API — never the whole email.

That arrow — from a bare LLM, to retrieval-grounded answers, to a tool-using agent, to an agent that decides when to retrieve, to collaborating teams — is the spine of the syllabus. Notice it is monotonic in one quantity: autonomy. Each rung lets the system make more decisions on its own. And that is exactly why each rung also demands more of the machinery in the back half of this track — monitoring, recovery, guardrails, evaluation. More freedom, more governance.

3 · The loop as engineering state

The book's five steps are a mental model; to build anything we have to name the state the loop carries. Strip the agent down and it is a small, explicit control loop. Everything else in the course bolts onto this skeleton.

agent = {
  goal,              # what success means (lesson 13 makes this measurable)
  state,             # everything known so far: scratchpad, memory, results
  policy,            # the model + prompt that chooses the next action
  allowed_actions,   # the tools/transitions permitted right now (lesson 07, 20)
  observation_log,   # an append-only record of what each action returned
  stop_condition,    # goal met, budget spent, or escalate to a human
}

while not stop_condition(state):
    context     = build_context(goal, state)        # context engineering (lesson 02)
    action      = policy.choose(context)            # the model decides
    checked     = validate(action, allowed_actions) # refuse out-of-bounds actions
    observation = execute(checked)                  # touch the real world
    state       = update(state, action, observation)# fold result back in
    log(observation_log, action, observation)       # so the run is replayable
return final_report(state)

Six pieces of named state, one loop. Read each later pattern as an answer to "which line does this strengthen?" Routing (lesson 04) enriches policy.choose with a branch decision. Tool use (07) populates allowed_actions and execute. Memory (10) gives state structure that survives across runs. Reflection (06) inserts a critique step before update. Guardrails (20) harden validate. Evaluation (21) scores the whole observation_log, not just the final report. If you cannot point at the line a feature touches, you probably do not yet have an agent — you have a prompt with extra steps.

4 · Why autonomy must be governed — a worked budget

It is tempting to think the hard part of an agent is the intelligence. In production, the hard part is the loop not stopping, or stopping wrong, or spending without bound. A loop that decides its own next action can also decide to keep going. Numbers make the danger concrete.

Worked example — the runaway research assistant. Our coding/research agent answers a question by repeatedly: building context, calling the model, and maybe calling a search tool. Suppose each iteration costs roughly:

At an illustrative blended price of $3 per million input tokens and $15 per million output tokens, one step costs about 8000 × 3/10⁶ + 1000 × 15/10⁶ = $0.024 + $0.015 = $0.039, and takes about 6 seconds. A well-behaved run of 8 steps costs roughly 8 × $0.039 ≈ $0.31 and finishes in 8 × 6 = 48 s. Tolerable.

Now remove the stop rule. The agent hits a flaky search API, gets a confusing result, decides to "try once more," and loops. Worse, context grows: each step it appends the last observation, so input tokens climb — 8k, 12k, 16k, 20k. Left unbounded for 50 steps with growing context, the input bill alone can pass $5, latency exceeds 5 minutes, and the user is still staring at a spinner. One confused agent, one missing line of code. This is not hypothetical; it is the default failure of every naive loop.

The fix is a control surface for every degree of freedom we grant. A budget (max steps, max tokens, max dollars — lesson 18). A goal-and-progress check that can detect "not getting closer" and halt (lesson 13). A recovery path that treats the flaky API as an expected observation rather than a reason to spin (lesson 14). A human-in-the-loop gate before irreversible actions (lesson 15). The design rule that governs the whole track: never add a degree of autonomy without naming the boundary, the evidence, the budget, and the stop rule that govern it.

5 · The dependency order — and the frameworks

Because each capability is also a liability, the patterns cannot be learned in any order. You cannot meaningfully evaluate a trajectory before the agent records one; you cannot debug a multi-agent team before a single agent is debuggable; you cannot add tools before the loop has a state to fold their results into. The book's conclusion groups the patterns, and this track linearizes them into a ladder:

Every code example in the book lands on one of three concrete "canvases," and we will name them the same way it does, choosing whichever fits the pattern:

• LangChain and its stateful extension LangGraph — a flexible canvas for chaining a model with other components and for building explicit control-flow graphs. This is the natural home for chaining (lesson 03), routing (04), and the loop itself.
• CrewAI — purpose-built for orchestrating multiple agents with defined roles and tasks. The natural canvas for multi-agent collaboration (lesson 09).
• Google Agent Developer Kit (Google ADK) — tools and components for building, evaluating, and deploying agents on Google's AI infrastructure. The canvas for the deployment- and evaluation-flavored lessons.

The book's stance, which is also this track's: frameworks are interchangeable canvases for the same underlying patterns. We learn the pattern — the state, the contract, the failure modes — so that the framework becomes an implementation detail you can swap.

Finally, the introduction's five future hypotheses explain why the order tilts ever further toward governance. Each one cranks autonomy up another notch: (1) generalist agents managing fuzzy long-horizon goals — possibly assembled "Lego-style" from many small specialist models (SLMs); (2) deep personalization with proactive goal discovery — agents that act before being asked; (3) embodiment, agents that perceive and act in the physical world; (4) an agent-driven economy, agents as independent economic actors; (5) goal-driven, morphing multi-agent systems that rewrite their own structure and prompts to hit a declared outcome. Every hypothesis adds freedom, and so every hypothesis adds the need for more boundaries, more monitoring, more recovery, more evaluation — the exact machinery the second half of this course builds.

6 · The running example

One example threads through all 25 lessons: a coding and research assistant. It receives a task, inspects a repository, searches references, plans edits, applies patches, runs tests, asks for human approval when an action is risky, and reports its evidence. We will meet it at every level of the ladder — as a Level-1 tool caller in lesson 07, a Level-2 context engineer throughout, and a Level-3 collaborator in lesson 09 — and watch it accumulate exactly one new capability and one new control surface per lesson. By the capstone (lesson 24) it is a complete system that can act, remember, recover, evaluate, and improve, and you will be able to point at the lesson that earned each piece.

Where this points next

We now have the map: an agent is a stateful control loop, autonomy climbs a four-rung ladder, and every rung must arrive with a control surface. But "a loop around a model" is still vague — where exactly does the model end and the system begin? Which decisions belong to the model's judgment and which to deterministic code we can test? Lesson 01, "Agent boundary — model, policy, state, environment," draws that line precisely, separating the stochastic model from the control system around it. Only once the boundary is sharp can lesson 02 turn prompting into an enforced contract, and the execution patterns begin.

Interview prompts

• What is the precise difference between an LLM call and an agent? (§1 — a model call is one stateless text-in/text-out transaction; an agent wraps it in a feedback loop carrying state, so it can perceive, act on the world, observe the result, and decide again until a goal or stop rule is reached.)
• Walk through the book's autonomy levels. What does each rung add? (§2 — L0 reasoning only; L1 adds tools/RAG to act on the world; L2 adds multi-step strategy and context engineering plus self-improvement; L3 adds coordinated specialist agents. Each rung adds one capability and one failure mode.)
• What is "context engineering" and why does the book elevate it to a core skill? (§2 — strategically selecting, packaging, and managing only the most relevant information for each step; accuracy comes from short, focused, relevant context, not from dumping everything into the window.)
• Name the state an agent's control loop must carry. (§3 — goal, state, policy, allowed_actions, observation_log, stop_condition; every later pattern strengthens one of these.)
• Why is autonomy dangerous, and how do you bound it? (§4 — a self-directing loop can fail to stop, growing cost/latency without limit and taking irreversible actions; bound it with step/token/dollar budgets, a progress-based stop rule, recovery paths, and human gates before risky actions.)
• Why must the patterns be learned in dependency order rather than as a checklist? (§5 — you cannot evaluate a trajectory before one is recorded, debug a team before a single agent is debuggable, or add tools before the loop has state to fold results into; reliability is compositional.)
• How do the book's five future hypotheses shape the syllabus? (§5 — generalist agents, deep personalization, embodiment, agent economy, and morphing multi-agent systems all increase autonomy, so the course must repeatedly add boundaries, monitoring, recovery, and evaluation.)