Inside the Claude-agent tool loop

Video segment: 14:24–16:34

The key idea in this demonstration is simple:

The LLM proposes what should happen. The surrounding program decides whether and how to execute it.

This distinction is easy to miss because a tool call can look like an action in the model's response. In the speaker's explanation, however, the language model only generates likely next words. It cannot execute an external tool by itself. A client program reads the model's response, extracts the proposed tool call and its parameters, and performs the call.

The while True loop on the slide is the mechanism that connects these parts. It lets the system repeat the cycle of generate → possibly act → observe → generate again.

First, map the moving parts

The example contains four main pieces:

1. The prompt and messages describe the problem and the conversation so far.
2. The model generates a response. That response may contain ordinary text or a request to use a tool.
3. The tool is an external capability, such as an operation that retrieves information or performs an action.
4. The client program controls the loop. It sends messages to the model, examines the response, invokes the tool when appropriate, and adds the result back to the context.

The model is therefore one part of the agent, not the entire agent. The loop around it supplies the control flow and the connection to the outside world.

Click to enlarge

Source visual: The slide directly shows the requested Python agent pattern. A while True loop asks for a response, chooses a tool-use branch when indicated, passes the predicted parameters to external execution, or prints the final response. The tool result is then added to the running context. The adjacent panel also shows two validation gates around the tool call; the next chapter explains those gates in detail.

The loop, one turn at a time

The following is a teaching reconstruction of the slide's control flow. It preserves the important decisions without claiming to reproduce every identifier or library detail from the example:

context = [user_prompt]

while True:
    response = client.messages.create(
        model=model,
        tools=tools,
        messages=context,
    )

    if response.stop_reason == "tool_use":
        call = extract_tool_call(response)
        result = run_tool(call)
        context.append(tool_result(call, result))
    else:
        print(response.text)
        break

1. Start with a running context

The program begins with the user's task in a context list. Each later model request receives the conversation so far. When a tool returns a result, that result is appended to the same running context.

This context is important because the next model call must know what happened in the previous turn. Without the tool result, the model would not have an observation to interpret. The loop would have no new information with which to choose its next step.

2. Ask the model what to do next

The client sends the model several inputs:

• the selected model;
• the available tools; and
• the current messages or context.

The model then produces a response. It may finish with text, or it may formulate a tool-use request. The tool-use request contains the context needed by the client to identify the tool and the parameters to pass to it.

In the speaker's description, that response carries the model's proposed call, its parameters, and the context or prompt-related information needed for the surrounding program to handle the request. It is still not a completed external action.

The model's output is a proposal, not proof that the requested operation has happened. This is the generation–execution boundary:

LLM generates a proposed call
             ↓
client interprets the response
             ↓
client invokes the external tool

Teaching context: This is similar to a person filling out an action form. Writing “send this payment to X” is different from a service actually sending the payment. The program between the model and the service is where the proposed request can be checked and executed.

3. Let stop_reason choose the branch

The response includes stop reason metadata. This is control information that tells the surrounding program why generation stopped. In the tool-use case, the relevant value indicates that the model wants the program to handle a tool call.

The program can then follow this decision:

Stop reason indicates…	Program does…
Tool use	Extracts the proposed call and its parameters, then routes it toward tool execution
No tool use or a finished response	Uses the response text as the final response and leaves the loop

The stop reason is not itself the tool result. It only selects the next control-flow branch. The tool result arrives later, after the client has made the external call.

4. Extract the call and execute it

When the tool-use branch is selected, the surrounding code obtains the tool call from the response. The call identifies the requested operation and carries its arguments. The client then passes that call to the tool executor.

The slide uses a refund call with an order identifier as an illustrative tool request. The important lesson is not the particular refund operation. It is the handoff:

model response
    → tool name and arguments
    → tool executor
    → external result

The model has not silently reached into a database or service. The client has explicitly taken the model-produced call and invoked the tool on its behalf.

5. Append the observation and continue

After execution, the program appends the tool result to the context. The next pass through the loop sends that updated context to the model.

This creates the agent's repeated perceive–decide–act pattern in concrete form:

1. The model interprets the current problem and context.
2. It decides whether another tool is needed.
3. The program acts by invoking the requested tool.
4. The tool returns an observation.
5. The model receives that observation and decides what comes next.

The loop can repeat several times. A tool result may lead to another tool call, or it may give the model enough information to produce a final answer.

Click to enlarge

Source visual: The same code slide remains clearly visible in this later frame. It directly depicts the second code chunk described in the talk: a tool-use stop_reason selects the branch that extracts a tool call and executes it, after which the result is added to the running context.

Why the while True matters

The while True statement means “keep taking turns unless some branch stops the loop.” In the example, the non-tool branch prints the response and executes break. A tool-use turn does not break. It executes the tool, appends the result, and returns to the top.

This is the concrete form of the agent loop discussed in the previous chapter. Repetition gives the system more capability than a single model response. It can gather information, use that information, and act again.

But the loop also carries the risks introduced earlier:

• If the system keeps requesting tools, it may fail to terminate.
• If multiple turns move away from the original task, the agent can drift.
• Every additional turn can increase the amount of context and the token cost.

The example shows the control flow. It does not, by itself, provide a complete policy for limiting turns, detecting drift, or deciding whether a tool result is safe. Those checks are the subject of the next chapter.

Generation is not execution

A common wrong mental model is:

LLM says “call the tool” → tool runs automatically

The example supports a more precise model:

LLM generates a response containing a proposed call
    ↓
client checks the response's control metadata
    ↓
client extracts the tool and parameters
    ↓
client executes the external action
    ↓
client returns the result to the context

This separation matters for reliability. Because the program sees the proposed call before execution, it has a place to validate the call, reject it, ask the model to try again, or involve a human. The speaker identifies this space around the tool call as where ontology-based checks can later be added.

Takeaway

The Claude-agent example is a small program with a large architectural lesson. An LLM generates the next response, including a possible tool name and parameters. A surrounding client uses stop_reason to decide whether to execute that proposal. The tool returns an observation, the client appends it to the running context, and the model gets another turn.

The model supplies flexible interpretation and planning. The loop supplies repeated control and access to external actions. The next design question is how to check the proposed call and returned result before allowing this loop to continue.