Summary: How tool use turns a model into an agent

A language model cannot run code, so how does an agent “call” a tool? It does not run anything. It emits a structured request, and the loop around it runs the tool and feeds the result back. The model proposes; the loop disposes. That one division of labor is the mechanism behind every example in this track. This summary is the scan version of the full lesson.

Core ideas

• The key move: the model never executes a tool. It produces a small piece of structured text naming a tool and its arguments. The loop reads that request, runs the real function, and returns the result to the model as new input.
• One tool call is a four-step exchange. (1) Describe: the loop hands the model a menu of tools (each tool’s name, what it does, the inputs it expects, the tool schema). (2) Request: the model emits a tool call instead of a final answer. (3) Execute: the loop runs the real tool and feeds the result back. (4) Decide: the model reads the result and either answers or calls again.
• Steps 2 to 4 trace Lesson 1’s perceive-decide-act loop entered at the decide point. Tool use is the mechanism that makes the loop able to act in the world.
• In any one step the model does one thing: it either requests a tool or replies. The final answer comes on a later trip around the loop, after the results are back.
• The model picks the right tool from the descriptions and the request, with no hand-written routing rule. Given a weather tool and a calendar tool and a question that needs both, it calls each in turn. Vague descriptions cause wrong or skipped calls (the subject of a later lesson).
• A failure is just another result. When a tool errors, the loop feeds the error back as the step-3 input, and the model reacts: retry with a fix, try a different tool, or tell the user. Feeding the result back is not optional; it is how the model learns what happened and can correct itself.
• A tool call is just text in an agreed shape. The model is still only predicting tokens. The loop scans the output, recognizes the tool-call shape, and acts on it instead of showing it to the user. That is why the same model is a chatbot without the scaffolding and an agent with it.
• Providers expose this as “function calling” or “tool use,” and agent frameworks automate the menu-building and the watch-and-execute loop so you do not write that plumbing yourself.

What changes for you

The word “tool use” probably sounded like a feature you switch on. Now you can see it for what it is: a four-step conversation between a model that writes requests and a loop that runs them. When an agent does something impressive, you can ask the right questions: what tools was it given, did it pick the right one, did the result get fed back? And when an agent misbehaves, you know where to look first, the seam between the request the model wrote and the result the loop returned, rather than blaming the model alone.