Part XIII's language models generated text, one token at a time, from whatever they'd learned in training — nothing more. Ask one to multiply two four-digit numbers and it can only pattern-match toward a plausible-looking answer. What changes the moment it's allowed to call a calculator instead?
Flip the tool switch. With no tool, the model's answer is a rounded, pattern-matched guess — often close, sometimes wildly off. With the calculator available, the exact same question gets a structured call instead: name the function, pass the arguments, return the exact result.
Function calling gives a model a menu of callable tools — each with a name, a description, and a typed argument schema — and trains it to emit a structured call instead of free text whenever a call would serve the request better than a guess:
- — what the model actually outputs for a given request.
- — the specific tool chosen from the menu, identified by name.
- — the object of arguments passed to that tool, filled in from the request.
- — the structured object — a function name plus its arguments — that gets executed outside the model.
- Same frozen-mechanism idea as prompting
Nothing about the model's underlying weights changes between the two cases — this is the exact same "frozen mechanism, environment provides the option" idea from Part XIII's prompting chapter, just applied to which tools are on the menu instead of which examples are in the prompt.
- A tool call is a structured object
The tool call itself is just a structured object (a function name plus a JSON (JavaScript Object Notation) object of arguments) that gets executed outside the model and its result fed back in.
Every one of these bars represents a real gap between "sounds plausible" and "is correct." None of them is a training failure — a model genuinely can't multiply four-digit numbers reliably from pattern matching alone, any more than a person can in their head. The fix isn't a bigger model; it's a calculator.
The query , answered two ways:
- Free-text guess (no tool)
Round each operand to one significant figure:
Guess: .
- True answer
exactly — the guess is off by , or of the true value.
- With a tool: an exact structured call
calculator(127, 38)returns — not an estimate refined by more thought, but the exact value a calculator always returns, because the model isn't doing the arithmetic anymore.
Find the query, among the three, with the largest guess error when no tool is available.
This chapter's decision rule — "tool exists → call it" — is a simplification of a real, harder problem: a model has to decide whether a tool applies at all (is this actually an arithmetic question?), which tool among several fits, and how to fill in its arguments correctly from the request's natural language. Get any of those wrong and the call itself can be well-formed but pointed at the wrong function or the wrong numbers. The next chapter builds on a single call into a full loop: reason about what to do, act, observe the result, and reason again.