05 / Systems & trust · Start here

Tool use: letting a system act

A model can propose a tool call; application code validates it, runs it, and returns the result.

6 min read
In this lesson
THE IDEA TO HOLD ON TO

Generating a request to use a tool is different from executing that request.

A boundary between language and execution

A language model produces output tokens. In a tool-enabled system, some outputs represent structured requests: call a calculator, search a collection, or read a calendar. The application interprets that request and decides whether and how to execute it. The external result then becomes new context for another model step.

The 2023 Toolformer study explored training models to decide when and how to call several APIs. The earlier WebGPT project used a text-based browsing environment for question answering. These are concrete research systems, not evidence that every model has browser access.

An exact operation can complement an uncertain model

Consider the original question “What is 137 × 24?” A calculator evaluates the expression exactly within its arithmetic rules: 3,288. The model can help interpret the request and explain the result, while the calculator performs the arithmetic. The accuracy of the calculation does not guarantee that the model selected the correct expression.

Likewise, a database tool can return a correct row for the wrong query. Tool success must therefore be checked at several levels: the request matches the user’s intent, the arguments are valid, the tool returns a meaningful result, and the final explanation represents that result accurately.

SEE THE IDEA

The host runs the action.

  1. Model requestCalculate 12 × 7
  2. Host applicationValidate + execute
  3. Tool result84
  4. Model receives resultCompose response
Producing a tool request is not executing it. This illustrative calculator call separates the model, host application, and tool.

Permissions belong to the application

Reading a public document and sending a payment have very different consequences. A robust application limits which tools are available, validates arguments, enforces authorization, and asks for confirmation where appropriate. A model’s generated text must not be treated as sufficient permission for an external action.

Tool results are data with provenance. A failed request, empty search, or timeout should be represented explicitly. If a model invents a successful result after an error, the user sees a false account of what the system did. Useful interfaces make the difference between a proposed action, an executed action, and a verified outcome visible.

A loop, not an unlimited power

A tool workflow can repeat: inspect a result, choose another call, then answer. The application needs stopping rules, budgets, and recovery behavior because a model can make redundant or unhelpful requests. A longer sequence of calls does not by itself mean better reasoning.

The demonstrations here simulate only the educational control flow and use local data or arithmetic. They do not access accounts, browse live pages, or send messages. This keeps the mechanism inspectable: you can see exactly what the tool knows and distinguish that knowledge from the model-like text surrounding it.

A CONCRETE EXAMPLE

A complete calculator loop

User asks for a product → model proposes multiply(137, 24) → application validates numbers → calculator returns 3288 → response reports the result. If argument validation fails, the correct next step is an error or correction, not a fabricated answer.

A COMMON MIX-UP

If a model writes “I searched,” a search must have happened.

Only an actual tool execution can establish that. Natural-language claims about actions can themselves be mistaken.

Take it with you

  • A tool call crosses from generated text into application execution.
  • Validate intent, arguments, results, and reporting.
  • Tool access is a configured system capability.
YOUR TURN · ABOUT 30 SECONDS

Check your understanding.

Choose an answer, then see the explanation. You can try again.

Practice only. Your answer is not stored or sent anywhere.

Optional · saved only on this browser
UP NEXT

Hallucinations: fluent text without support

Continue when you’re ready. Marking this lesson as read is optional.

Next lesson →

Sources & further reading

Primary references for this lesson. The explanation and examples above are original.

  1. Toolformer: Language Models Can Teach Themselves to Use Tools ↗Timo Schick et al. · 2023-02-09 · checked 13 Nov 2026
  2. WebGPT: Browser-assisted question-answering with human feedback ↗Reiichiro Nakano et al. · 2021-12-17 · checked 13 Nov 2026