trendingAI & ML — INTERMEDIATE
How Tool Calling Actually Works, and the Reason+Act Loop
The Introduction level showed an agent calling tools without explaining what that call actually is under the hood. It’s a more mechanical, more limited process than it might sound — and understanding exactly where the model’s role ends is the key to understanding agents at all.
The Quick Answer
A model never runs a tool itself. The application gives it a list of tool definitions— each one a name, a plain-language description, and a schema describing the arguments it expects. When the model decides a tool is relevant to the user’s request, it generates a structured request naming that tool and the arguments to call it with. The application then actually executes the real action, and sends the result back to the model in a separate step, so it can use that result to answer or decide what to do next.
The Round Trip, One Step at a Time
Here’s a real tool-call round trip, following the exact structure used by production tool-use APIs — a tool definition, the model’s call, the application executing it, and the result flowing back:
Notice that step 3 — actually running the tool — never touches the model at all. That separation is what makes tool calling safe to build real systems around: the model only ever proposes an action, and the application decides whether and how to actually run it.
Chaining Calls: The Reason+Act Loop
A single tool call answers a simple question. A task that needs several pieces of information — like the Tokyo temperature example from the Introduction level, where converting units required first knowing the live temperature — needs the round trip above to repeat, each time informed by what the last one found. This is the loop the ReAct paper formalized: Reasonabout what’s known so far and what’s needed next, Act by calling a tool, Observe the result, and repeat — reasoning again with the new information now available — until the task is actually complete.
Here’s that loop laid out visually, walked through with the same Tokyo temperature task from the Introduction level — two full iterations, each one starting from what the previous iteration’s Observe step revealed:
This is exactly why the model can’t simply plan every tool call up front in one shot for tasks like this: it genuinely doesn’t know Tokyo’s temperature until the first tool result comes back, so it can’t decide what to convert until that point. Each reasoning step depends on real information the previous action revealed.
Why the Description Field Matters So Much
A model decides whether to call a tool by matching the user’s request against that tool’s description— not its internal code, which the model never sees. A vague description (“handles data”) gives the model far less to work with than a precise one (“Get the current weather for a given location”). Writing clear, specific tool descriptions is one of the most direct levers an application has over which tools actually get used, and when — closely related to the same precision that matters in Prompt Engineering.
Fun Fact
A model can be given dozens of tools at once, but every tool’s name, description, and schema counts against its context — the same limited space covered in Context Window. Giving an agent too many tools it rarely uses has a real cost, even before it calls any of them.
Test Yourself
When a model “calls a tool,” what does it actually do?
What are the three parts of a tool definition given to a model?
In the ReAct loop, what happens between two tool calls in a multi-step task?
Ready for the different kinds of agent memory, real tool-calling code, and the production failure modes — runaway loops, hallucinated arguments, and cost explosion? Continue to the Advanced level →