Lesson 3 - The Anatomy of an Agent

Welcome to The Anatomy of an Agent#

You now know what an agent is: a model in a decide-act-observe loop, choosing its own actions until a goal is met. This lesson opens that idea up and lays the parts out on the table. Because here’s the reassuring truth — no matter how sophisticated an agent looks, it’s assembled from the same small set of pieces. Learn those pieces once and you have a map of this entire course: every later module is just one of these parts, examined in depth and built for real.

Throughout the course we’ll build Atlas, a friendly trip-planning agent. By the end you’ll have given Atlas a model to think with, instructions that shape its personality, tools to search destinations and check the weather, a loop to run it, memory so it remembers the conversation, and guardrails so it always knows when to stop. In this lesson we’ll meet each of those parts and point to where you’ll build it.

By the end of this lesson, you will be able to:

• Name the six parts every agent is built from
• Explain what each part does and how it connects to the others
• Identify which later module covers each part in depth
• Describe an agent as the composition of these parts running in a loop

Let’s start with the part that does the thinking.

The Brain: Model and Instructions#

Two parts give an agent its “mind”: the model that reasons, and the instructions that tell it who to be.

The model is the reasoning engine — the part that looks at the goal and everything seen so far and decides what to do next. In this course that’s Claude. The model is what makes an agent feel intelligent: it reads a user’s request, weighs whether it can answer directly or needs a tool, and produces the next step. Which model you pick is a real engineering decision, because it trades capability against cost. A small, fast model like claude-haiku-4-5 is cheap and quick — perfect for simple, high-volume deciding — while a larger model handles harder reasoning and trickier judgment calls at a higher price per request. A good rule of thumb: start with a capable model to get the agent working, then consider a cheaper one once you know which steps are actually easy. You’ll make your very first call to Claude in the next lesson.

The instructions — usually called the system prompt — are the persistent “who you are and how to act” that ride along with every request. They define the agent’s role, its tone, its boundaries, and the rules it should never break. For Atlas, the instructions might be as simple as “You are a concise, friendly trip planner. Suggest realistic itineraries, always check the weather before recommending outdoor activities, and never invent prices you haven’t looked up.” Notice how much that single paragraph does: it sets a personality, nudges tool use, and draws a safety boundary. The model supplies the raw reasoning; the instructions aim it.

Together these two are the smallest possible “agent brain” — but a brain with no hands can only talk. For that, we need tools.

The Hands: Tools and the Loop#

If the model and instructions are the mind, tools and the loop are how that mind reaches into the world and actually gets things done.

Tools are the actions the model is allowed to request. Each tool is just a function you expose to the agent, described by three things: a name (like get_weather), a description that tells the model when to use it, and an input schema that says what arguments it expects. That’s it. Atlas’s toolbox might hold search_destinations, get_weather, and convert_currency — each one a small, well-described capability. Tools are what separate an agent from a chatbot: without them the model can only produce text, but with them it can look things up, run calculations, and take real action. We devote an entire module to designing good tools later in the course.

The loop — also called the harness — is your code: the program that actually runs the decide-act-observe cycle. The model only ever requests a tool; your loop is what dispatches the real function, captures the result, feeds it back, and decides whether to go around again. The harness is the part you own and control, and it’s where reliability lives. You’ll build this loop from scratch in the very next module.

A tiny sketch of the parts, in pseudocode, makes the relationship concrete:

agent = model + instructions + tools
loop:
    step = model.decide(instructions, history, tools)   # the brain decides
    if step is a tool call:
        result = run_tool(step)                          # your harness acts
        history.add(result)                              # observe
    else:
        return step                                      # final answer

The model decides; the harness acts and observes; the loop ties them together. Two things remain before this is a complete agent: it needs to remember what it has seen, and it needs to know when to stop.

What It Remembers and When It Stops: Memory and Guardrails#

Memory is everything the agent carries forward as it works. The most important kind is the simplest: the running message history — every user message, every tool call, every result, accumulated so the model can see the whole conversation each time it decides. This is the agent’s short-term memory, and it’s what lets Atlas connect “what’s the weather there?” to the city you mentioned three steps ago. Later, agents gain long-term memory too: a store outside the conversation where facts persist across sessions, so Atlas could remember next month that you prefer window seats. We dedicate a full module to memory, both short and long term.

Stopping conditions and guardrails are how the agent knows the loop is finished — and how you keep it safe when it isn’t. The natural stop is the happy path: the model decides it has everything it needs and returns a final answer instead of another tool call. But a model can also get stuck looping, so your harness sets hard limits: a maximum number of steps, a budget cap, or a timeout. When any limit trips, the agent halts gracefully instead of spinning forever or running up a bill. Atlas might be allowed ten steps to plan a trip; if it hasn’t finished by then, it stops and reports what it has. Getting these limits right is part of the craft, and we’ll set them as we build the loop.

That completes the set. Six parts: model, instructions, tools, the loop, memory, and stopping conditions — the full anatomy of any agent you’ll ever build.

Practice Exercises#

Exercise 1: Map Atlas to its parts#

Take the Atlas trip-planning agent and assign each of the following to one of the six parts: get_weather, “You are a concise, friendly trip planner,” the accumulated chat history, Claude, “stop after 10 steps,” and the code that calls get_weather and feeds back the result.

Exercise 2: Which part defines the persona?#

A teammate wants Atlas to be more playful and to always warn travelers about visa requirements. Which part of the agent should they change, and why is it the right place rather than, say, adding another tool?

Exercise 3: Which part decides when to stop?#

In a single sentence, name the two ways an agent run can end, and say which part is responsible for each.

Summary#

Every agent, however advanced, is assembled from the same six parts. The model is the reasoning engine that decides each step (Claude, in this course), and model choice trades capability against cost. The instructions — the system prompt — are the persistent role, tone, and boundaries applied to every request. Tools are the actions the model can request, each defined by a name, a description, and an input schema. The loop (the harness) is your code that runs the decide-act-observe cycle, dispatches tools, and enforces limits. Memory is what the agent carries forward — the running message history now, and a long-term store later. And stopping conditions end the run, either at the model’s natural finish or at a guardrail you set. An agent is the composition of these parts running in a loop, which is also a map of the rest of this course.

Key Concepts#

• Model — the reasoning engine that decides each step; choice trades capability against cost.
• Instructions (system prompt) — the persistent role, behavior, and boundaries.
• Tools — actions the model can request: a name, a description, and an input schema.
• The loop (harness) — your code that runs decide-act-observe and enforces stopping.
• Memory — short-term message history now; long-term store later.
• Stopping conditions & guardrails — the natural finish plus max-step, budget, and timeout limits.

Why This Matters#

Seeing an agent as a composition of parts is what turns “build an AI agent” from a vague, intimidating goal into a checklist you can work through one piece at a time. When something misbehaves, this map tells you where to look: a wrong personality is an instructions problem, an action it can’t take is a missing tool, an endless run is a stopping-conditions problem, a forgotten detail is a memory problem. Every later module in this course picks up exactly one of these parts and builds it for real — so this anatomy is the scaffolding the whole course hangs on. Next, you’ll bring the first part to life by making your own call to Claude.

Next Steps#

Continue Building Your Skills#

You now have a map of the whole course: an agent is a model and instructions for a brain, tools and a loop for hands, plus memory and stopping conditions to keep it coherent and safe. Each part has a module waiting for it. Next, you’ll stop talking about the model and actually use it — making your first call to Claude and watching the reasoning engine respond.