The Agent Loop, in Depth

An agent is a loop: look at the situation, decide one next step, take it with a tool, look again. Everything else is detail.

Building with AI · Lesson 36 · 10 min read

Back in Module 5 you built your first agent — “the model in a loop.” It worked, but why the loop, exactly? You could imagine asking the model for a full plan up front and just executing it. Yet real agents almost never do that; they take one step, look at what happened, then decide the next. Getting crisp about that cycle — and the little bit of memory it carries — is the difference between an agent you can debug and a black box that mysteriously flails. Hold the question: what does looping give an agent that a single upfront plan can’t?

Perceive → decide → act, on repeat

An agent loop has three beats. Perceive: assemble what the model can currently see — the goal, the history so far, and the latest tool result. Decide: the model picks the single next action (call a tool with specific arguments, or declare it’s done). Act: your code runs that tool and captures the result. Then you feed that result back in and loop. The model never “does” anything itself (from Module 5): it only ever emits a decision; your code performs it and reports back. One decision, one action, one observation — around and around until the goal is met.

The loop carries state — the running transcript

What makes the loop smart is the state it carries between turns: the growing record of “I tried X, got Y.” Each iteration, the model sees the whole story so far, so its next decision is informed by what already happened. This is usually just the accumulating conversation/transcript in the context window (recall the context window from Module 1 — and note it can fill up, which is a whole lesson later). The agent isn’t remembering in some magic way; it’s re-reading the transcript each turn. Lose that state and the agent forgets what it just did and repeats itself.

One turn of the loop, concretely:
• Perceive: goal = “find the cheapest flight,” history = “searched airline A → $420.”
• Decide: model outputs search_flights(airline: "B").
• Act: your code runs it → “$380.”
• The transcript now holds both results, so next turn the model can compare and either search a third or answer “B, $380.” The comparison only works because the earlier result is still in state.

Why iterate instead of planning it all upfront

Here’s the payoff. The world is uncertain: a search returns something surprising, a tool errors, a page says the item is sold out. A giant upfront plan is a guess made before seeing any of that — the first surprise breaks it. Looping lets the agent react to reality: it decides the next step using information that literally didn’t exist when it started. That’s exactly why an LLM’s occasional wrong turn isn’t fatal — the next observation can correct it. The cost is that loops can wander or never stop, which is precisely what the rest of this module (goals, termination, recovery) is about taming.

The loop recovering from a surprise:
1. Goal: book a table for 4 at 7pm. The agent calls check_availability(7pm).
2. Observation: “7pm full; 6:30 and 8:00 open.” An upfront plan that assumed 7pm would now be stuck.
3. Because it’s a loop, the agent perceives the new info and decides a new step: book(6:30pm) (or asks the user).
4. It reached the goal by reacting to information that didn’t exist when it started — the whole reason to loop instead of pre-plan.