How low can the limit go? Model calls needed in the example: 2 for a one-fact lookup, 3 to 4 for anything that combines facts. Limit 1 gets 0% right, 2 gets 42%, 3 gets 67%, 4 or more gets 100%. A limit set below what real tasks need turns correct runs into failures; set it from measured run lengths with some headroom, not from a guess.
Each pass also makes the next prompt longer, because the whole history is resent:
Prompt size at each model call, for a task that finishes and one that is stuck
The four-call task sent 387 prompt words in total; the stuck agent stopped at eight calls sent 1,216, about three times as much for twice the calls. Cost grows faster than steps, which is one reason long loops need compaction (Level 7) and tight limits (module 6 of this level).
Loop, or not?
Use a loop when the path depends on what you find: research, debugging, "look at the file, then decide". Use a fixed workflow (Level 3) when the steps are known in advance: it is cheaper, faster, easier to test and cannot wander. A common mistake is using an agent where a three-step script would do. A good test: could you draw the flowchart before seeing the input? If yes, build the flowchart.
Production code often uses the API's native tool calling (Level 2) instead of parsing Thought and Action text: the provider returns a structured tool call and you skip the parser. The loop is the same; the parser disappears and some of the format errors with it.
Practical checklist
Keep the loop small and in plain code you can read in one screen.
Always have a step limit, chosen from measured run lengths.
Send errors back as observations that say what to do.
Check for repeats; nudge once, then stop.
Log every step (module 7 of this level): thought, action, arguments, observation.
Return something useful when you stop: the reason and the partial result.
Ask whether a workflow would do.
Interview angle
"Your agent loops forever. How do you find out why, and how do you stop it?" Stop it with limits in code: a maximum number of steps, a time and cost budget, and a repeated-action check. Find out why from the trace: read the last steps and classify the loop: the same action repeated (the model ignores observations, or the tool returns something unhelpful), alternating actions, or progress that never converges on an answer. Fix the cause: make tool errors and "no result" messages explicit, tell the model what to do on failure, add a "finish when you have enough" instruction, and test the loop with a model that misbehaves on purpose. Add that guards cannot replace fixing the prompt or tool description, and that you would log traces for every run so the next failure is a five-minute read.
Check yourself
The model writes Action: lookup but your tool is called search. What should the next observation say, and why does it list the tools? (It says the tool is unknown and lists the available ones, so the model can correct itself on the next step instead of repeating the mistake.)
For the curious A calculator bug found in the example
The safe calculator rejected negative numbers: 3-5 worked but -5+3 and 2*-3 returned an error, because a leading minus is a separate operation in Python's parse tree. It also accepted True as the number 1 and could return inf for a huge result. It now handles a leading minus or plus, refuses booleans, and reports an overflow as an error the model can read.
What you will use daily at work
Practice
What it looks like
A step limit and a repeat check
Every loop has both, and the stop reason is logged.
Errors as observations
Tool and format errors go back to the model as text it can act on.
The provider's tool-calling API
Instead of parsing "Action:" lines yourself, you use the structured tool calls from Level 2.
Draft: confirm how your provider's tool-calling format maps to this loop.