Tool Use & Function Calling
Lesson 1 showed that a model's output can be a structured call instead of prose. This lesson is about the rest of the loop, the part that makes tool use actually useful. The model emits a call, something outside the model executes it for real, and the real result gets fed back into the model's context so it can give a final answer grounded in something it didn't have to guess at.
Predict before you look
The tool here is a real calculator, and the arithmetic shown is really computed, not invented for the lesson. Before you look, do you expect the model to attempt the multiplication and division itself, or reach for the tool instead?
Asked to compute 847 times 39, divided by 12, rounded to two decimal places, the model didn't attempt the arithmetic itself, it reached straight for the calculator tool, emitting a call built around the exact expression it needed evaluated. The tool result here isn't invented for this lesson, it's the real output of that real expression, 2752.75. Handed that number back in a follow-up call, the model's final answer restated the computation in slightly roundabout wording, real model output tends to do that, and landed on the same correct number.
This is really the same mechanism as chain-of-thought from Prompt Engineering, more tokens in the context before the model has to commit to an answer, except this time one of those tokens didn't come from the model at all, it came from a real computation running outside it. That handoff, the model decides it needs something, something else provides it, the model continues, is the actual mechanical definition of tool use. Everything past this lesson is a variation on that same loop.
Why does feeding the calculator's real result back to the model matter, instead of just trusting the model's own arithmetic?