Lesson 01 What Is an Agent
Theme:

What Is an Agent

Lesson 01 · Building Your Own Agents · ~10 min read

Why the word "agent" needs unpacking

Walk into any 2026 engineering channel where people are arguing about LLM systems and the word agent will be doing five different jobs in five different sentences. To one person, an agent is a chatbot that can call tools. To another, it is the descendant of the old RPA bots — a screen-scraping automation glued to a browser. A third uses "agent" to mean an autonomous loop that runs unattended for hours. A fourth means a swarm of LLM personas passing messages to each other in a multi-agent system. A fifth has given up and started calling any LLM invocation that does more than one thing an agent.

All five usages are out in the wild, all five appear in marketing copy, and all five show up in academic papers — frequently in the same week. The result is that "I want to build an agent" is not actually a specification. Until you can pin down which sense you mean, picking a framework is impossible: every framework on the market — Claude Agent SDK, LangGraph, OpenAI Agents SDK, CrewAI — optimizes for a different point on this spectrum. Choosing between them without a definition is like choosing between a forklift and a unicycle without saying whether you're moving pallets or learning to balance. This course's first job is to fix a working definition precise enough to choose tools against. Everything that follows in the seven modules sits on top of it.

A working definition

The definition this course uses (the same one carried forward from the slide deck) is short:

An LLM agent is a program whose control flow is driven by an LLM's output.

Three implications follow if you take that sentence literally. First, the LLM picks what step to take next: control flow becomes data — a JSON payload the model emits — rather than something hardcoded in your if/for structure. Second, the runtime executes the chosen step: the LLM never actually touches the database, the shell, or the API; your code does, on instructions read out of the model's response. Third, the result is fed back to the LLM so it can pick the next step, closing the loop.

This definition is sharp enough to exclude three popular things that are not agents. A hardcoded pipeline — even one that calls an LLM at every node — is not an agent, because the order of steps lives in your DAG, not in the model's output. A single-shot RAG chain (retrieve, then answer) is not an agent, because there is no loop and the LLM does not decide what to fetch. A pure chatbot (no tools, no execution) is not an agent either, because nothing closes the loop — the model is talking, not doing.

The agent loop

Every agent — every single one, regardless of framework — is some elaboration of the same six-step loop. Walk through it slowly because the rest of the course is built on it.

  1. Build a prompt. Combine the system prompt, the conversation history, and the new user request into a single Messages-API payload.
  2. Call the LLM. Ask for either a final answer (plain text) or a tool call (a structured request to invoke a function).
  3. If the response is an answer → we're done. Exit the loop and return the answer to the caller.
  4. If the response is a tool call → execute the named function in the runtime, with the arguments the model picked.
  5. Append the tool result back into the conversation as a new message the LLM will see on the next turn.
  6. Goto step 2.
      +-----------------------+
      |  build prompt (msgs)  |
      +----------+------------+
                 |
                 v
      +-----------------------+
      |    call the LLM       |<-------+
      +----------+------------+        |
                 |                     |
       answer?   |   tool call?        |
       +---------+---------+           |
       |                   |           |
       v                   v           |
   +-------+        +--------------+   |
   |  done |        | run the tool |   |
   +-------+        +------+-------+   |
                           |           |
                           v           |
                  +-----------------+  |
                  | append result   |--+
                  +-----------------+

Every agent framework you will meet in this course — Claude Agent SDK (Module 2), LangGraph (Module 3), OpenAI Agents SDK (Module 4), CrewAI (Module 5) — is an elaboration of this loop. They differ in how they let you shape it: who owns the conversation state, where the tool dispatch lives, whether the loop is implicit (driven by stop reasons) or explicit (drawn as a graph), and which knobs are exposed. The loop itself is invariant.

The four building blocks

Strip any framework's marketing page back and the same four pieces are sitting underneath.

Model. The LLM that picks the next step on every iteration. Choice of model is the dominant cost/latency/capability tradeoff: a Haiku-class model is fast and cheap but may give up on multi-step tool reasoning; an Opus-class model handles a longer leash but can be 5x the bill and 3x the latency. Most production agents end up with more than one model — a strong one for planning, a cheap one for routine extractions.

Tools. Functions the agent can invoke, plus the JSON Schema the LLM sees to decide how to invoke each one. The schema is the contract — its name, its description, its parameter shapes — and it is what the model actually reasons against. If you've taken the MCP Servers course, tools are the same idea, but with one structural difference: in an agent, tools are typically defined in-process (regular Python functions); in MCP, tools live in a separate server reached over a transport. Same concept, different blast radius.

Memory. Short-term memory is the conversation history you ship to the model on every turn — every prior user message, every tool call, every tool result. Long-term memory is anything the agent has to fetch: a vector database, a file the agent re-opens, a structured record store. Most production agents need both: short-term memory keeps the current task coherent, long-term memory keeps the agent useful across sessions.

Planner / loop driver. The code that decides when the loop stops. Sometimes invisible because a framework hides it, but it is the part that makes the agent actually terminate. We will return to stop conditions in section 6 — it's the most-skipped piece, and the cause of the most production incidents.

Planning styles

As you read agent papers and framework docs, three named planning patterns keep coming up. Knowing the names lets you read the literature without translating.

Real frameworks let you mix them. Claude Agent SDK leans ReAct-ish by default. LangGraph lets you draw any of the three (or a hybrid) as an explicit graph. CrewAI tends toward explicit task lists assigned to role-named agents — closer to Plan-and-Execute with a multi-agent twist. None of these patterns is intrinsically better; they're choices about where the planning lives.

Stop conditions and budgets

Critical: every agent needs all four stop conditions

"The agent that wouldn't stop" is the single most common 2026 production-agent failure mode. It happens because the developer relied solely on the natural exit and the model never emitted it. Wire all four; treat any one as a single point of failure.

  1. Natural exit. The LLM signals "final answer" — for Claude this is stop_reason == "end_turn"; for other providers it is the equivalent finish signal. Free, but model-dependent.
  2. Turn cap. A hard upper bound on the loop counter (e.g., 20 iterations). Cheap, dumb, and the single most effective safety net you can add. Always ship it.
  3. Cost / budget cap. A running total of input + output tokens (or dollars) that aborts the loop when it exceeds a configured limit. This is what saves you from the runaway agent that technically never hit the turn cap because each iteration was huge.
  4. Caller interrupt. The human user, or a parent system, can cancel the loop. In practice: a cancellation token, a Ctrl-C handler, an HTTP timeout. The loop must check it between iterations.

Missing any one of these has shipped real production incidents. Lesson 02 wires all four into the from-scratch loop so the muscle memory is in place before any framework hides it.

Why frameworks exist (and when you don't need one)

Frameworks pre-package the loop, the tool-call parsing, the retry logic, the cost tracking, the observability hooks, and increasingly the multi-agent orchestration. You do not need them — Lesson 02 builds the whole thing in about 80 lines of plain Python with nothing but the anthropic SDK. So why does the rest of the course spend four modules on them?

What you trade away by skipping frameworks:

What you gain by skipping frameworks:

The course's premise is straightforward: build one yourself first (Lesson 02), so the loop is no longer mysterious; then learn the four major frameworks (Modules 2–5) on top of that foundation; then choose the right framework — possibly none — for the actual job (Module 6). By the end you will be able to read any framework's source and recognize every piece of it.

References