The Agentic Loop and stop_reason

What you need to know

The Messages API is stateless. Claude never runs a tool itself and never remembers the last call. An agentic loop is the code you write around the API that makes repeated calls look like one autonomous piece of work.

Each pass through the loop does four things:

1. Send the full conversation so far, with the tool definitions, to Claude.
2. Inspect stop_reason on the response.
3. If it is "tool_use", execute every tool Claude requested, in your code.
4. Append Claude's response and a tool_result for each tool call to the history, then go back to step 1.

When stop_reason is "end_turn", Claude has finished and the loop stops.

messages = [{"role": "user", "content": request}]
while True:
    response = client.messages.create(model=MODEL, max_tokens=4096,
                                      tools=TOOLS, messages=messages)
    messages.append({"role": "assistant", "content": response.content})
    if response.stop_reason != "tool_use":
        break                      # end_turn, or a case handled below
    results = []
    for block in response.content:
        if block.type == "tool_use":
            output = run_tool(block.name, block.input)
            results.append({"type": "tool_result",
                            "tool_use_id": block.id, "content": output})
    messages.append({"role": "user", "content": results})

Two details carry marks in the exam. Each tool_result must carry the tool_use_id of the call it answers, and the results go back in a user message. That is the only way the model sees what a tool returned.

Other stop reasons

"tool_use" and "end_turn" are the two that drive the loop, but a robust harness handles the others explicitly rather than treating them as success.

The Agent SDK runs this loop for you. You still need to understand it, because the SDK's turn limits, budgets and hooks all attach to these same steps.

Model-driven, not scripted

In an agentic loop Claude decides which tool to call next, based on what earlier results showed. That is different from a pre-configured decision tree or a fixed sequence of tool calls written in your code. The model-driven loop handles cases nobody scripted; a fixed sequence is cheaper and more predictable when the steps never change (lesson 1.6 covers that choice).

In the exam

Expect a harness with one flaw. Common ones: the loop stops on text content; it stops after a fixed number of iterations; tool results are not appended, so Claude repeats the same call; a max_tokens response is shown to the customer as a finished answer. Pick the option that makes stop_reason the control signal and keeps the history complete.

Check your understanding

Apply it: Write Cedar Ridge's loop contract