The other tools — tool calling.
A model is sharp with language and blind to a trajectory. So you give it instruments to call on.
A model reasons about words, but it cannot reliably do arithmetic, look up today's score, or measure where a ball was heading. For those it needs help — so you hand it a set of tools it may use, and let it call on them. This is tool calling (also “function calling”).
Here is the part that trips people up: the model does not run the tool. It requests one — naming the tool and the inputs — and a real program on your side runs the actual tool. The reading comes back to the model as text, which it reads and trusts like any other input.
The third umpire works this way. It cannot trace a ball's path in its head, so it calls for Hawkeye; it cannot hear a faint touch, so it calls for the snickometer; it cannot see heat, so it calls for hot-spot. The umpire names the instrument, the instrument measures, and the umpire rules on what it reports.
So the model's real skill here is judgement: turning a vague appeal into the right tool with the right inputs, then reading the answer correctly.
Send up an appeal the umpire can't settle from words alone. Watch it call the right instrument, and rule on what the instrument reports back.
Ask, run, read.
You hand the model the tools; it hands you back a request; your code runs the tool and gives it the result. The model only ever reads text.
The model decides; the tool does.
Tools give a model powers it lacks on its own — exact measurement, live data, real actions. But the split holds: it picks the tool and inputs, your code does the running, and the model reads back the result and continues. Its job is judgement, not execution.
Retrieval, last lesson, was really just one tool — a search. Tool calling is the general version: give the model a whole kit of instruments, and let it call whichever the moment needs.