0.3 Why one call is not enough

We now have the two pieces: a model that turns text into text, and tools it can request to touch the outside world. You might think that’s enough to build an agent. It almost is. One thing is missing, and it’s the thing that turns a party trick into a system.

Follow a real task and watch it get stuck

Take a genuinely ordinary request:

“How many days until the project deadline?”

The model can’t answer this cold — it doesn’t know today’s date or the deadline. So, as we learned in 0.2, it emits a tool request:

{ "tool": "getToday", "args": {} }

The program runs getToday() and gets back "2026-07-10". Now what?

Here’s the wall. That result has to go somewhere, and the only thing that can use it is the model — but the model already finished its one call. A model runs once per call and then it’s done. It cannot take the tool result, think again, and ask for the next tool. Someone has to call it again.

The loop is that “someone”

So we wrap the model in a tiny piece of code that just keeps going:

   ┌─────────────────────────────────────────────┐
   │                                             │
   ▼                                             │
 call the model  ──►  did it ask for a tool?     │
                          │            │          │
                       no │            │ yes      │
                          ▼            ▼          │
                     return the    run the tool,  │
                      answer       feed result ───┘
                                    back in

Read it as plain English:

1. Call the model with everything so far.
2. Did it ask for a tool?
   • No → it produced an answer. We’re done; return it.
   • Yes → run the tool, add the result to the conversation, and go back to step 1.

That loop — call, check, maybe run a tool, repeat — is the smallest thing that deserves the name agent. Each pass through it is one step. The model supplies a step’s decision; the loop supplies the repetition that a single call can’t.

The load-bearing idea

An agent is a loop around a model. The model decides the next move; the loop keeps asking “what’s next?” until the model says “nothing — here’s the answer.” That’s the whole engine.

When does it stop?

Notice there’s no counter, no “do five steps.” The loop ends on a condition: the model returns an answer without asking for a tool. Which means the model itself decides when the task is finished, simply by no longer reaching for a tool.

That’s elegant — and, as we’ll see, a little dangerous. What if the model never stops asking? What if a tool fails? What if a step needs to happen exactly once but the program crashes mid-loop? Hold those questions; they’re the entire second half of this guide.

See it turn

You’ve now built the agent loop in your head. In the very next lesson you get to watch one run, step by step — the same deadline task, click by click.

• Next up: 1.1 The agent loop — the loop, live and steppable.
• Optional pit stop: 0.4 The vocabulary map — every term so far on one page, if you’d like it all pinned down before we continue.

Where we are

Model + tools + a loop = an agent. It works. Now we push on it until it breaks — because that’s where the interesting engineering begins.