LLM vs agent

The model: text in, text out

Think of the model as a function. You pass it some text, and it gives you back some text.

response = model(context)

The text you pass in is called the context. In an agent, the context holds the instructions, the conversation so far, and a short description of each tool the agent may use. The text that comes back is usually a reply. It can also be a request, such as "call search_files with the query auth".

Four facts about this function explain most of agent design:

• It cannot act. When an agent "searches the code", the model only wrote a request to search. Your code did the searching.
• It remembers nothing between calls. Each call starts fresh, so the model knows only what you send it this time.
• It can give different answers to the same input.
• It follows what it reads. Text in the context can change its behavior, even text you did not write, such as a web page the agent opened.

So when the model answers, it draws on two things: what it learned in training, and the context of this one call.

The agent: a loop around the model

An agent is a program that calls the model again and again. Each time, it sends the current situation, reads the reply, does what the reply asks, and records what happened.

Here is a complete agent in Python-style pseudocode:

def run_agent(task, tools, max_steps=30):
    messages = [system_prompt(), user(task)]
    for step in range(max_steps):
        reply = model(messages, tools)       # the only line that uses the model
        messages.append(reply)
        if not reply.tool_calls:
            return reply.text                # no request: the model says it is done
        for call in reply.tool_calls:
            result = execute(call)           # your code runs the tool, under your rules
            messages.append(tool_result(call.id, result))
    return "stopped: step limit reached"

Only the line with model(...) involves the model. Everything else is ordinary code that you write. The messages list is the agent's state. The if decides when to stop. The execute line is where something in the world actually changes.

The rest of this course adds features to this loop, one chapter at a time: memory, planning, subagents, approvals, and more.

Example: two calls

A user asks, "How many open bugs do we have?" The agent has one tool, search_issues. On the first call, your code sends this:

// call 1: what the model receives
messages: [
  {"role": "system", "content": "You are Patch, a coding agent..."},
  {"role": "user",   "content": "How many open bugs do we have?"}
]
tools: [search_issues(label: string, state: "open" | "closed")]

The model cannot search, so it replies with a request:

{"role": "assistant", "tool_calls": [
  {"id": "call_1", "name": "search_issues",
   "arguments": {"label": "bug", "state": "open"}}]}

Your code runs the search and finds 17 issues. Then it calls the model a second time. It sends everything again, plus the request and its result:

// call 2: what the model receives
messages: [
  {"role": "system",    "content": "You are Patch, a coding agent..."},
  {"role": "user",      "content": "How many open bugs do we have?"},
  {"role": "assistant", "tool_calls": [{"id": "call_1", "name": "search_issues", ...}]},
  {"role": "tool", "tool_call_id": "call_1", "content": "17 issues: #412, #415, ..."}
]

Now the model answers, "There are 17 open bugs." It seemed to remember its own request, but it did not. Your code sent the whole conversation back, including the model's earlier reply.

Two related features are worth knowing. Some provider APIs can store the conversation for you, so you send an id instead of the full history. The provider rebuilds the context on its side, so the model still reads the full history on every call. Providers can also cache the repeated start of a context. That makes calls cheaper and faster, but the context is just as long. Chapter 4 covers both.

Who holds what

A sentence like "the AI remembered my preference" mixes up five different parts:

When someone says the agent remembers something, ask which of these parts holds it. It is never the model call itself.

Where intelligence and agency come from

The intelligence comes from the model. It reads the request, picks the next step, writes the arguments for a tool, and makes sense of the results.

The agency comes from your code. Agency means the ability to act in the world over time. That needs tools connected to real systems, permission to use them, a loop that keeps going, saved state, and the authority to stop. All of that lives in the runtime.

So the model chooses, and your code decides whether each choice happens. That is why the same model can power very different agents. In a chat window it can only talk. With file and shell tools, it becomes a coding agent. With access to tickets and refunds, it becomes a support agent.

Who does what

Try this before reading the answers. For each job, pick who does it in a typical agent, where your code runs the loop.

Now the questions people most often get wrong, with their answers:

What "done" really means

When an agent says it is finished, three separate things happen, and different parts own them:

• The model says it is done by replying without asking for a tool.
• Your code stops the loop. It may stop because of that reply, because a step or cost limit ran out, or because a person pressed stop.
• A check confirms the result, for example by running the tests or checking that an API call succeeded.

A run that stopped is not necessarily a run that succeeded. Decide how you will check success before you build. For a coding agent, the check might be: the failing test now passes, the other tests still pass, and no files outside src/ changed. Chapter 16 builds on this.

From one call to an agent

To tell a workflow from an agent, ask who decides what happens next.

One call

One model call does one job, such as summarizing a document. There is no loop.

A workflow

Your code decides the order of the steps, and the model fills in some of them. For example, an invoice workflow might go like this:

An agent

The model decides the next step, inside limits your code enforces. Fixing a failing test is a good example, because the right steps depend on what the agent finds along the way.

Many real systems mix the two. Use the simplest design that works. A workflow is easier to predict, test, and pay for. Choose an agent when the right steps depend on what it discovers, as in debugging.

Running example: Patch, version 0

Patch is the coding agent we build up across the course. It works on a small team's web service: a Python API with a PostgreSQL database, deployed on AWS. In version 0, Patch is not an agent at all. You paste in a failing test and the file, one model call suggests a fix, and you run the tests yourself. You are the loop. Chapter 1 replaces you with code.

What goes wrong

You decide, AI builds

Check yourself

Takeaways

• A model call is a function: context in, text out. The model runs nothing and remembers nothing between calls.
• An agent is ordinary code that calls the model in a loop, runs the tools it asks for, and decides when to stop.
• "Done" has three parts: the model says so, your code stops, and a check confirms it.

Going deeper

• Building effective agents (Anthropic, December 2024). The source of the workflow vs agent distinction, with the advice to start with the simplest design.
• A working definition of "agent" (Simon Willison, September 2025). One sentence that matches this chapter: "An LLM agent runs tools in a loop to achieve a goal."