Cycles and Loops

What you will be able to do

• ✓Explain what a cycle is and why agents need one
• ✓Build the agent -> tool -> agent loop with an edge back and a conditional exit
• ✓Map Thought, Action and Observation onto nodes, state and edges
• ✓Give a loop a stopping condition and a step limit - and know what happens without them
• ✓Run a real ReAct cycle with llama3 choosing the actions
• ✓Read a loop’s run step by step to find wasted or wrong steps

The idea, in plain English

Module 1’s agent was a for loop: ask the model, parse an action, run the tool, append the observation, repeat until a final answer or max_steps. A graph expresses the same thing with one extra edge: add_edge("tools", "agent") sends every tool result back to the agent. That edge back is a cycle.

A cycle alone runs forever. What makes it a loop you can trust is a conditional edge after the agent - should_continue(state) - with exits: an answer goes to END, too many steps goes to a give-up node, anything else goes to the tools. The state carries what the loop needs to decide: the history of actions and observations, the step count, the answer once there is one.

We built it twice. First with a hard-coded agent, to see the mechanics. Then with llama3 choosing each action through a schema-enforced Step (Lesson 2.14’s approach, since llama3 cannot call tools). Asked "Should I bring an umbrella in Mumbai, and what’s 12 * 8?", it called get_weather, then calculate, then answered: "Yes, bring an umbrella in Mumbai, and the result of 12 * 8 is 96."

The real runs also showed what loops do wrong: llama3 repeated calls it had already made, and once passed the calculator the wrong expression. The graph executed every step faithfully. A loop is only as good as its exits, its limits, and what you check inside it. LangGraph 1.2.14 throughout.

Worked example: The ReAct loop from Module 1, rebuilt as a graph cycle.

From a for loop to a cycle

Module 1 wrote the loop as code: for step in range(max_steps): ask the model, stop on a final answer, parse the action, run the tool, append the observation. The loop lived inside a function, and the only way to see what it did was to print from inside it.

The graph version has the same parts, laid out as structure: an agent node (ask the model), a tools node (run what it asked for), a conditional edge after the agent (answer, limit, or another round), and a plain edge from tools back to agent. Nothing about ReAct changed. What changed is that the loop is now something you can draw, stream, and extend.

The mechanics, without a model

The first version uses a hard-coded agent: with no observation yet it asks for calculate; with one it writes the answer. The calculator returns "30". Streaming the run with stream_mode="updates" shows the cycle exactly: agent -> {step 1, action calculate}, calculator -> {observation "30"}, agent -> {step 2, answer "The calculation result is 30"}.

The agent runs twice because it has to see the tool’s result. That is the whole idea of ReAct: think, act, observe, think again.

Every loop needs an exit and a limit

A cycle plus a stopping condition is a loop; a cycle without one is a runaway. The stopping condition is should_continue: answer present -> END. The limit is a step count in state, incremented by the agent, checked by the same router.

We tested both failures. An agent that never answers, with MAX_STEPS = 5, ran agent -> calculator four times and stopped on the fifth agent step - with an empty answer. Better to route to a give_up node that says so: "Stopped after 6 steps without an answer." With no limit at all, LangGraph’s own guard caught it - after 10,007 node runs, the default recursion_limit. With a real model that is around five thousand LLM calls before anything stops.

Watch out: LangGraph’s default recursion_limit is 10,007. Treat it as a crash barrier, not a step limit: count steps in state, route to a give-up node, and pass a recursion_limit sized to your loop.

A real ReAct cycle with llama3

The agent node asks llama3 for a Step - action ("calculate", "get_weather" or "final_answer") and action_input - with structured output, so the reply is always a valid action. The tools node looks the action up and runs it: the model decides, the program executes. The observation goes into the history the agent sees next time.

The umbrella question took exactly the path a person would: get_weather("Mumbai") -> Rainy, 27°C; calculate("12 * 8") -> 96; then the answer. Mixed questions worked the same way - weather in Hyderabad, then the arithmetic. Each run took about 4 seconds.

What the real runs got wrong

Repetition. For "What is 125 * 48?" llama3 called calculate("125 * 48"), got 6000, and called it again before answering; for the Delhi weather it called get_weather three times. The loop still ended, but every repeat is a wasted model call and a wasted tool run. A small guard in the tools node fixed most of it: if the exact call is already in the history, do not run it again - reply "you already have this result (Sunny, 34°C); answer now". Delhi dropped from three weather calls to one.

A wrong argument. For "(250 - 37) * 4" llama3 sent calculate("250 - 37 * 4") - brackets dropped. The calculator correctly returned 102, and the model answered "the result of (250 - 37) * 4 is 102". Every node did its job; the answer is wrong. No loop guard catches that - it needs a check on what the model sends, or a test set of questions with known answers.

Debugging a loop

Stream the run and read it as a sequence of state changes. For each step ask: which node ran, what did it change, which route did should_continue pick, and why. Every trip around the cycle should move the state closer to an answer - a step that does not (the same call, the same observation) is the first thing to fix.

Keep the loop in the graph, not inside a node. A while True inside the agent node hides exactly what streaming would show you, and you do not need recursion either: the edge back is the loop.

Cycles beyond agents

The same shape covers retries (call -> failed -> attempts < 3 -> call), validation (generate -> validate -> fix -> validate), review (draft -> review -> revise -> review) and planning (plan -> execute -> observe -> re-plan). Each needs the same three parts: work, a decision, and an exit - plus a count so the exit is guaranteed.

Lesson 3.5 replaces the hand-written tools node with LangGraph’s prebuilt ToolNode.

Step-by-step code

Tip: Pass a recursion_limit sized to your loop - two nodes per round, plus a little: with MAX_STEPS = 6, recursion_limit=20 is ample and still stops a bug long before 10,007.

Loops at a glance

builder.add_edge("tools", "agent")

add_conditional_edges("agent", should_continue, [...])

if state["step"] >= MAX_STEPS: return "give_up"

return {"answer": "Stopped after ..."}

graph.invoke(state, {"recursion_limit": 20})

from langgraph.errors import GraphRecursionError

Try it yourself

The code does not change. Swap the content string and the program does something else entirely.

What usually goes wrong

✗ def should_continue(state):
    return "tools"

✓ def should_continue(state):
    if state["answer"]:
        return END
    ...

✗ if state["step"] >= MAX_STEPS:
    return END

✓ if state["step"] >= MAX_STEPS:
    return "give_up"   # writes "Stopped after N steps"

Quick check before you move on

1. 1.

   In the hard-coded example, why does the agent node run twice?

   Show answer
2. 2.

   An agent hits MAX_STEPS and the router returns END. What is wrong with that?

   Show answer
3. 3.

   What did the repeat guard change?

   Show answer
4. 4.

   The loop answered (250 - 37) * 4 with 102. Which part failed?

   Show answer

Interview questions