Lesson 01 · Slide 1

Lesson 01 — What Is an Agent

Beyond the hype: a working definition, the agent loop, and the four building blocks.

Agents Module 1

Lesson 01 · Slide 2

The hype problem

In 2026 vendor decks, the word agent means at least five different things — sometimes all on the same slide.

Chatbot with tools — one LLM call with function-calling bolted on.
RPA bot — clicks-and-keystrokes automation, often no LLM at all.
Autonomous loop — the thing this course is actually about.
Multi-agent system — several loops talking to each other.
Just “an LLM call” — marketing reaching for the word.

We need a usable definition before we can pick a framework — every framework optimises for a different point on this spectrum.

Lesson 01 · Slide 3

Working definition

An LLM agent is a program whose control flow is driven by an LLM's output: the LLM picks what step to take next, the runtime executes it, and the result is fed back to the LLM.

Contrast with three things that are not agents under this definition:

Hardcoded pipelines — the control flow lives in your code, not in the LLM's output.
Single-shot RAG — the LLM is one node in a fixed graph, not the driver.
Chatbots — no loop; one user turn produces one model turn and stops.

Lesson 01 · Slide 4

The agent loop

Every agent — in every framework — is some elaboration of this shape:

          +-------------------+
          |  build prompt     |
          |  (sys + history)  |
          +---------+---------+
                    |
                    v
          +-------------------+
   +----> |  call the LLM     |
   |      +---------+---------+
   |                |
   |        action? |  final answer?
   |                |
   |     +----------+----------+
   |     |                     |
   |     v                     v
   |  +------+           +-----------+
   |  | tool |           |  return   |
   |  +--+---+           +-----------+
   |     |
   |     v
   |  +--------+
   +--+observe|
      +--------+

Loop body: prompt → LLM → tool call → observation. Exit: the LLM emits a final answer (or a stop condition fires).

Lesson 01 · Slide 5

Four building blocks

Model

Picks the next step. The “brain” of the agent — usually a single LLM behind an API.

Tools

What the agent can do. Functions with schemas the LLM can call by name.

Memory

What the agent knows so far. Conversation history plus any scratchpad or external store.

Planner / loop

Wires the three together. Drives the loop forward until a stop condition fires.

Lesson 01 · Slide 6

Planning: implicit vs explicit

Implicit planning — the LLM decides the next step every turn, in-line with its reasoning. Default mode for most agents.
Explicit planning — the LLM first produces a multi-step plan, then a separate executor runs it. More predictable, less adaptive.
Production agents mix: some scaffolding planned up front, individual turns decided as it goes.

Three named patterns you'll meet in papers and framework docs:

ReAct — reason, then act, on every turn.
Plan-and-Execute — plan once, execute the plan.
ReWOO — plan a DAG of tool calls, execute in parallel, synthesise the answer.

Lesson 01 · Slide 7

Tool use, in one slide

The LLM doesn't run tools — it asks the runtime to. A tool call is just a structured block in the model's output:

# Pseudocode: LLM emits a structured tool-call block
{"name": "search", "input": {"query": "rust async runtimes 2026"}}

The runtime parses the block, dispatches the function call, captures the result, and feeds it back to the LLM as the next observation. The LLM never touches the network, the disk, or your database — your code does.

Notes: This is the single most important mental flip in the lesson. Tools are not “the LLM calling APIs”; they're “the LLM emitting JSON your code interprets”.

Lesson 01 · Slide 8

Memory: short vs long

Short-term

The conversation messages sent to the LLM on every turn: system prompt, user turns, assistant turns, tool results.

The LLM sees these by default. Cheap and immediate, but bounded by the context window.

Long-term

Anything the agent has to fetch: a vector DB, a structured store, files on disk.

The LLM only sees long-term memory when a tool reads it — treat it as an external system you query, not as state you assume.

Most production agents need both.

Lesson 01 · Slide 9

Stop conditions

Every agent needs all four of these. Missing one is a runaway-cost bug waiting to happen.

Natural exit — LLM emits a final answer with no more tool calls (e.g., stop_reason == "end_turn").
Turn cap — hard upper bound on loop iterations. Pick a number, enforce it.
Cost / budget cap — running token total exceeds a limit. Tracked per request.
Caller interrupt — the user or parent system cancels.

Danger

The most common 2026 incident: a developer relied solely on the natural exit. The LLM kept emitting tool calls. The cost ran for hours before anyone noticed.

Lesson 01 · Slide 10

What agents are not

Three myths to dispel

“Agent = autonomous AGI.” No — they're loops with budgets. Useful, bounded, fallible programs.
“Agent = multi-agent.” No — single-agent loops are the common case. Multi-agent is a specialisation we'll meet later in the course.
“Agent = needs a framework.” No — the next lesson builds one in ~80 lines of plain Python.

Lesson 01 · Slide 11

Agent vs pipeline: when to pick which

Pipeline (fixed flow)

The steps are known in advance.

Example: “Summarise this document.” Input → OCR → LLM → summary → out.

Cheaper, more predictable, easier to test. The LLM is one node, not the driver.

Agent (LLM-driven flow)

The steps depend on intermediate results.

Example: “Answer this question — search, read, decide if you have enough, repeat.”

More flexible, harder to bound cost, needs explicit stop conditions.

If you don't need LLM-driven control flow, don't reach for an agent. Pipelines are usually the right tool.

Lesson 01 · Slide 12

What the rest of the course gives you

Module 1 — build an agent from scratch in ~80 lines of Python. No frameworks.
Modules 2–5 — build the same shape of agent in four real frameworks: Claude Agent SDK, LangGraph, OpenAI Agents SDK, CrewAI.
Module 6 — compare them side-by-side on the same task: latency, cost, ergonomics, observability.

By the end you'll know which framework to reach for — and when the answer is none of them.

Lesson 01 · Slide 13

Recap & what's next

Agent = LLM-driven control flow. The LLM picks the next step; your runtime executes it.
Four building blocks. Model, tools, memory, planner / loop.
Every agent needs four explicit stop conditions. Natural exit, turn cap, cost cap, caller interrupt.

Coming up: Lesson 02 — build the loop yourself in ~80 lines of Python using just the Anthropic SDK.