TracksStudyAbout
Sign in
Start studying
Module 11 · AI Agents Module contents
Module 11  ·  Card 5 / 17beginner

Agent Loops

An agent loop cycles through think, act, observe, repeat.

The model decides on an action, the action runs, and the result comes back.

That result informs the next decision.

The loop ends when the goal is met or a limit is hit.

Always cap iterations, or a confused agent will loop until it exhausts your budget.

Back Next
Learn in depth ↓
Module 11 · AI Agents · 17 concepts
In depth  /  15 lines

Agent Loops, in more detail

An agent loop is the cycle of think, act, observe, repeat.

The model decides on an action, your code runs it, and the result comes back.

That result joins the context and informs the next decision.

The loop ends when the goal is met, or a limit is reached.

That limit is not optional, since a confused agent will loop indefinitely.

Cap the number of iterations, the wall-clock time and the token spend.

Every iteration adds to the context, so cost grows faster than linearly.

A twenty-step run can cost far more than twenty single calls.

Watch for the common failure of calling the same tool with the same arguments repeatedly.

Detect that and break out, since it will not resolve itself.

Log every step with its inputs and outputs, because agents fail in the middle.

Without a trace, debugging is guesswork.

Give the model a way to declare it is finished, and a way to declare it is stuck.

An agent that cannot give up will invent a result instead.

Streaming the steps to the user makes a slow loop tolerable and failures visible early.

Want the full technical article? Wikipedia ↗
Deep dive

What is underneath Agent Loops

The loop, written out

An agent is not a model. It is a loop around a model, and the loop is where every property of the system comes from.

  1. Build the context: the system prompt, the task, the history so far.
  2. Call the model and read its output.
  3. If it asked for a tool, run that tool.
  4. Append the call and its result to the history.
  5. Go back to step one, until the model answers instead of calling, or a limit is hit.
ct+1=ct  ∥  at  ∥  ot\mathbf{c}_{t+1} = \mathbf{c}_t \; \Vert \; a_t \; \Vert \; o_t
  • ata_t: the action the model chose.
  • oto_t: what the tool returned.

The model is stateless. Every iteration re-reads the whole history, which is what makes the loop's memory management the central design problem.

The context grows, and the cost with it

∣cT∣=∣c0∣+∑t=1T(∣at∣+∣ot∣)|\mathbf{c}_T| = |\mathbf{c}_0| + \sum_{t=1}^{T} \big( |a_t| + |o_t| \big)
total tokens=∑t=1T∣ct∣∼O(T2)\text{total tokens} = \sum_{t=1}^{T} |\mathbf{c}_t| \sim O(T^2)

Each step re-sends everything before it, so a twenty-step task costs on the order of the square of a one-step task, not twenty times.

∣ot∣ dominates|o_t| \text{ dominates}

Tool results are the bulk of it. A file read or a search result can be thousands of tokens, and it is re-sent at every subsequent step.

Truncating tool output at the boundary, before it enters the history, is worth more than any other single optimisation in an agent.

The limits are load-bearing

Cap the loop three ways: Tmax⁡T_{\max} steps, a token budget and a wall clock limit.

A loop with no step limit does not terminate on the hard cases, it repeats. Two tools that undo each other produce a cycle that looks like progress.

Detecting a repeated action and injecting a message saying so is cheap and breaks most loops, which a step limit only ends after paying for every iteration.

Budgets belong to the loop rather than to the model, because the model has no way to know how much it has already spent.

Where the errors compound

P(success)=pTP(\text{success}) = p^{T}

If each step succeeds independently with probability pp, a ten-step task at p=0.95p = 0.95 succeeds 60 percent of the time.

That is the structural argument for fewer, larger steps, and for tools that do more per call rather than being primitive.

It is also the argument for making the loop recoverable at every step.

An error returned to the model as an observation is one the model can route around, and an exception that kills the loop is not.

What the loop owns and the model does not

Validation of arguments, because a malformed call should be corrected rather than executed.

Permission, because whether a tool may run is a policy question and the model is not the right place to enforce policy.

Persistence, so that a loop interrupted at step twelve resumes rather than restarts.

history≠context\text{history} \neq \text{context}

The full history is stored by the loop. What is sent to the model is a view of it, and choosing that view, by summarising, dropping or reordering, is most of the engineering.

Test yourself

One question on this card. Every option explains itself once you pick, right or wrong.

Question 1
Why should agent loops have an iteration cap?
AI Agents

17 concepts in this module, then a graded test with every answer explained.

Study this module →
↑↓ move↵ openesc close