You will be able to explain how a language model uses tools such as search, calculators and code without doing those things itself.
Open an AI assistant and ask how much interest S$18,750 would earn at 3.1 percent a year, compounded monthly, over three years (an example figure; no result is given here). Watch what the assistant does on the way to its number, since that tells you more than the number itself.
An older or simpler assistant will often write a figure straight away. It can look right and still be wrong by a few dollars, and sometimes by much more. A newer assistant may pause, show a note such as "Analysing" or "Running code", and then return the exact amount. The newer assistant has not got better at arithmetic. It hands the sum to something else, and that something is a tool. How a model uses tools explains much of what modern assistants can and cannot do.
Lesson 5.1 described the hidden instructions that sit in the context window ahead of your question. These often include a list of tools. A tool is an outside program the model can ask to do work for it, such as web search, a calculator, a code runner, a calendar, or a way to read files. Each tool on the list has a short description of what it does and what input it needs, so a search tool needs words to look up and a code runner needs code.
While the model is working out its reply, it may reach a point where a tool would help. It then writes a tool request in place of an answer: text in a fixed format that the app recognises, asking a tool to run. For the compound interest question, the request might be a short block of code that does the sum. For a question about today's weather in Ang Mo Kio, the request might be a search containing the words to look up.
Writing a tool request is still next-token prediction, the idea covered in Lesson 3.2. During fine-tuning (Lesson 4.2), the model was trained on many examples where a tool request was the right next step. For a question containing a hard sum, the most likely next tokens are therefore a tool request and not a guessed answer.
Once the request is written, the model stops and ordinary software does the work. The app spots the request and sends it to the right program: a search engine runs searches, a code runner runs code, and a calculator does sums. These are the same kinds of programs that have been reliable for decades, and they compute or look things up without predicting anything.
The result comes back as text, either search results or the exact figure. The app pastes it into the context window, and only then does the model carry on writing, with the result in view. If one call is not enough, the model can make several in a row before writing its final answer.
Each side ends up doing the work it handles well. A model sees numbers as tokens, which is why it can stumble on long sums or on counting letters (Lesson 3.1), while a calculator or a few lines of code have no such problem. A model also knows nothing after its training cutoff (Lesson 4.4), and a search tool can fetch a page published that morning. With good tool use, arithmetic is done by something good at arithmetic and fresh facts come from a fresh source. The model's part shrinks to understanding the question, deciding what to ask the tools, and turning the results into a readable answer.
Tool use cuts some errors but adds new points of failure, and the model is involved at every one:
Choosing the tool. The model may answer from memory when it should have searched, or skip the calculator because the sum looked easy. The input it sends. A search for an interest rate may use last year's date, or code may have the right formula with the wrong number typed in, such as 1.3 percent in place of 3.1 percent. Reading the result. A search may return a bank page listing several rates for different periods, and the model may pick the rate for the wrong term.
In all three cases the final answer can look as solid as a correct one, so the wording of the reply gives you no warning.
Many assistants show when a tool was used, through a "Searched the web" note, a list of sources, or a panel you can open to see the code that ran. Opening these is worth the few seconds it takes. Check the search words, the inputs to the sum, and the page any figure came from, which is much faster than redoing the whole task yourself. Then check whether the final answer actually uses what the tools returned, since the model can still slip when it writes up the results.
A good test is a question that needs both a fresh fact and a calculation, such as how much interest a sum would earn at a rate a local bank is offering this month. Ask one like that, watch for signs of which tools it used, and then check whether the final answer actually used what those tools returned.
Ask an assistant a question that needs both a calculation and a recent fact. Note which tools it seemed to use and whether its final answer used their results correctly.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).