Claudeエージェントのツール・ループの内部

This chapter follows the order of operations in the small Python Claude agent shown by the speaker. The important point is to distinguish something that appears to be the LLM's thinking from the fact that an external tool actually runs.

The following is an organized explanation of the speaker's description of the code. The slide shows the shape of the loop, but this chapter does not reproduce uncertain variable names or detailed Python syntax. It focuses on the roles and flow that the speaker presents.

First, see the map of the whole code

This example has a model, a prompt, messages, a tool, and a client that connects them. The client is the surrounding program that handles requests to the LLM and external processing. The work can be divided as follows.

1. Build a request to the LLM from the model and prompt.
2. Examine the response returned by the LLM.
3. Look at stop_reason (the reason generation stopped) and choose the next operation.
4. If a tool is needed, pass the tool name and parameters in the response to a separate tool-execution process.
5. Add the tool result to the current context so it can be used by the continuing process.
6. If no tool is needed, display the response text as the final answer.

What the LLM does and does not do

In the speaker's explanation, the LLM itself is a mechanism that probabilistically generates likely next words. The LLM does not directly execute an external tool. When it decides that a tool is needed to solve the problem, it returns a response containing information for using that tool.

That response contains a proposed tool call, its parameters, context for continuing the process, and information related to the prompt. What comes back is a proposal: “Please call this tool with these values.” It does not mean that the external operation has been completed.

Check the generation-execution boundary with an example

Example (for learning): Suppose a user asks, “Please check the weather in Tokyo.” The LLM can indicate in its response that a weather tool should be used and that the location should be Tokyo. However, the client-side tool-execution process is what actually sends a request to the weather service. This example is an additional explanation to clarify the division between “proposal” and “execution” described by the speaker.

The agent loop created by while-true

At the center of the code is a while-true loop. This loop repeats the request to the LLM, examination of the response, tool execution, and addition of the result. This lets the agent observe, decide, and act as needed instead of explaining the problem once and stopping.

One iteration proceeds as follows.

1. The client asks the LLM using the model, prompt, messages, and available tools.
2. The LLM either answers in text or proposes a tool call.
3. The program reads stop_reason.
4. If the reason indicates tool use, the program passes the response to an execution process called get-tool.
5. The external tool runs, and its result is added to the current context.
6. The loop asks the LLM again using the updated context.

Here, stop_reason is not just explanatory text. It is control metadata used by the program to branch. If it indicates that generation stopped for tool use, the surrounding program executes the proposed call. If it indicates that a final text response was returned instead, the program displays the answer without calling a tool.

This while-true loop is useful, but it also has the risks of loops discussed in the previous chapter. If no termination condition or other branch works correctly, the process may continue forever. In exchanges between agents, drift can also occur as the direction of the conversation gradually changes. If iterations continue, the number of tokens in the context may grow and costs may rise. This code example does not completely solve these risks. It makes visible where the loop continues and where it moves to another operation.

Figure 1: A Claude agent loop repeatedly requests the model, executes a predicted tool call, adds the tool result, or displays the final response.

This slide directly shows the Python pattern described by the speaker. Inside while-true, the model either proposes a tool call and its parameters or finishes the process with text. When the tool runs, its result is returned to the ongoing context. The adjacent part of the slide also shows two validation gates, but this chapter first focuses on the tool-loop flow.

Follow the branch and repetition on the second slide

Figure 2: A slide showing the process of checking stop_reason, executing a tool call, adding its result, and continuing the loop.

This code slide makes the second code section described by the speaker visible. When stop_reason indicates tool use, the program extracts and executes the tool call. It then adds the result to the current context and lets the LLM continue processing the same problem. In other words, the LLM response does not itself become an external action; the client intervenes, reads the response, and executes it.

Understanding this example as an agent

This structure connects to the idea of an agent as “a system that receives a problem, decides, and acts.” The model interprets the problem and assembles the information needed for the next tool call. The tool returns external information or performs an external action. The client's loop passes that result to the next decision. Therefore, the agent's capability does not come from the LLM alone. The model, tools, and control process connecting them work together.

The most important distinction

The phrase “the LLM called a tool” is convenient, but internally there are two stages.

• Generation: The LLM probabilistically proposes the needed tool and parameters.
• Execution: The client receives the proposal and actually calls the external tool.

Because this distinction exists, a later process can check the proposal. In the speaker's talk as a whole, this leads to using ontologies and validators for that checking. This chapter's code example shows the basic boundary and loop before that validation is added.