Tools

You ask an AI assistant to summarise a file on your computer, and a moment later it tells you what the file says. It looks as if the model opened the file. It did not. A language model can only read text and write text. It has no way to touch a disk, a website, or anything else outside itself.

Something else opened the file: the program that sits between you and the model. That program offered the model a tool, the model asked for the tool to be used, and the program did the work. The lesson on AI agents introduced agents as systems that can take actions. This lesson explains the part that makes actions possible.

After this lesson you can say what a tool is, who owns it, how the model learns that it exists, and what happens between the moment a model asks for a tool and the moment it gets an answer back.

1. Tools belong to the software, not to the model

The phrase "the model's tools" makes it sound as if the tools are part of the model. They are not. A tool belongs to the software that stands next to the model. The model is only told about it.

This matters for understanding everything else in the lesson. When a model "uses" a tool, two different things are involved:

• The model, which reads text and writes text.
• The software around it, which is an ordinary computer program and can do what programs do: open files, fetch web pages, send requests to other systems.

The tools live on the software's side.

2. Which software this means

The software in question is whatever sits between you and the model. It takes what you type, passes it to the model, and shows you what comes back. It takes several forms:

It does not matter where this software runs. It can run on your own computer or on a company's servers somewhere else. The way tools work is the same in both cases.

The rest of this lesson calls it "the surrounding software" or "the agent software". A later lesson gives it a more specific name.

3. The software sends the model two things

When you give a task to an agent, the software speaks to the model on your behalf. It sends more than you typed. Two things go across.

The first is your task, in your words:

Summarise the Q3 review notes
in the project folder, then
list the risks that are still
open.

Keep it to one page.

The second is a list of tools, which the software adds:

available to you:

  read_file(path)
      open a file on this machine

  web_search(query)
      look something up online

"Q3" means the third quarter of a business year. The task comes from you. The tool list comes from the software. Both arrive at the model together, as text, in the same request. This is the "tool definitions" part of the context from an earlier lesson.

Each entry in the list has three pieces. read_file is the name of the tool. path in the brackets is the detail the model has to supply, in this case which file to open. The line below is a short description in plain words, so the model can tell when the tool is useful.

4. Who decides what is on the list

The model does not choose its tools. The software does.

The software can only offer what it is able to carry out. If the program has no code for sending email, there is no email tool on the list, and the model cannot send email no matter how capable the model is.

The reverse is also true. A tool that is not on the list does not exist as far as the model is concerned. The model cannot invent a working tool by naming one. If it writes a request for a tool that was never offered, the software has no code to run for it, so nothing happens except an error.

5. How ordinary code becomes a tool

A tool starts as plain program code inside the app. The model comes into the picture last. There are three stages.

flowchart LR
    A["Code the app already has<br/>open a file on disk<br/>fetch a page from the web"] --> B["Written up as tools<br/>read_file, needs: path<br/>web_search, needs: query"]
    B --> C["What reaches the model<br/>You may use read_file(path)<br/>and web_search(query)."]

1. Code the app already has. The program can open a file on disk and fetch a page from the web. This is ordinary built-in code. Programs could do these things long before language models existed.
2. The same abilities, written up as tools. Each ability gets a name and a blank to fill in. Opening a file becomes read_file with a blank called path. Fetching from the web becomes web_search with a blank called query (the words to search for).
3. What reaches the model. A piece of text, sent next to your prompt, that says something like "You may use read_file(path) and web_search(query)."

The third stage is the whole handover. No code is given to the model, and no access is given either. The model receives a description, which is text. From that text it learns that these two abilities exist and how to ask for them.

6. The model asks, and the software acts

Now the model knows the list. Suppose it decides that it needs the review notes to do your task. It cannot open the file, so it writes a request to have the file opened. This written request is called a tool call.

flowchart LR
    M["The large language model<br/>knows the list:<br/>read_file, web_search<br/>can reach neither"] -- "read_file(...)<br/>a request, not an action" --> S["The surrounding software<br/>the app or agent<br/>this is where the call happens"]

The diagram shows the two sides. On the left, the model holds the list of tools but cannot reach any of them. On the right, the software can reach all of them. The arrow between them carries a request, not an action.

A tool call is text, like everything else a model writes. It names the tool and fills in the blank, for example read_file("project/q3-review-notes.md"). The software reads this text, recognises it as a request, and runs its own code to do the work.

The phrase "the model called a tool" is common, and it is slightly misleading. The accurate version is: the model asked for a call, and the software made it.

An everyday comparison is a customer in a restaurant. The menu lists what the kitchen can make. The customer reads the menu and places an order. The kitchen does the cooking. The customer maps to the model, the menu to the tool list, the order to the tool call, and the kitchen to the software. The comparison stops being accurate in one place: a customer could walk into the kitchen, and a model has no such option. Writing text is the only thing it can do.

7. What travels in each direction

After the model writes its request, the software makes the real call and then hands the answer back.

What the software runs:

read_file(
  "project/q3-review-notes.md"
)

opens the file on disk
reads it, start to end
hands the text on

What it sends back to the model:

Q3 review - draft

Renewals slipped two weeks.
Two accounts still unsigned.
Support backlog cleared.
Pricing page still unfinished.

The text that comes back is called the tool result. The software places it into the model's context, and the model reads it like any other text.

The whole exchange in order:

sequenceDiagram
    participant U as You
    participant S as Surrounding software
    participant M as Model
    U->>S: Task
    S->>M: Task plus tool list
    M->>S: Tool call: read_file("project/q3-review-notes.md")
    S->>S: Opens and reads the file
    S->>M: Tool result: the text of the file
    M->>S: Summary and open risks
    S->>U: Shows the answer

The model never touched the disk. It received text and carried on deciding from there. With the notes in its context, it can now write the one-page summary and list the risks that are still open, such as the two unsigned accounts and the unfinished pricing page.

Two consequences follow from this design.

First, the software is a checkpoint. Because every action passes through it, the software can refuse a request, limit it, or ask you for permission before running it.

Second, the model depends on what comes back. If the tool returns the wrong file or an error message, the model works from that. It has no other view of the outside world.

8. The definition in three parts

A tool is a capability, exposed by the agent software, and handed to the language model. Each part of that sentence carries a piece of the idea.

9. A model can reach only what it was given

Put together, these facts set a hard limit. A model's reach into the outside world is exactly the set of tools the surrounding software chose to hand over. It has nothing beyond that set.

This explains a common observation. The same model can behave very differently in two products. In one app it can read your files and run searches. In another it can only chat. The model is the same in both. The tool list is different.

It also gives a practical way to judge any agent. To find out what an agent can do, and what it could do by mistake, look at its tool list. An agent with a "delete file" tool can delete files. An agent without one cannot.

Interview points

• A tool is a capability that the agent software exposes to the language model. The software owns the code. The model receives only a description.
• The surrounding software can be an agent such as Claude Code, an app such as ChatGPT, or a program a developer writes. Where it runs does not change how tools work.
• Each request carries two things: the user's task and the tool list. The tool list is text in the context and uses tokens.
• A tool definition has a name, the inputs the model must fill in, and a plain description of what the tool does.
• The software decides which tools exist. The model cannot add tools and knows only the ones it was told about.
• A tool call is text written by the model that names a tool and supplies its inputs. It is a request, not an action.
• The software runs the real code and returns a tool result as text. The model continues from that text.
• Because every action passes through the software, the software is the place to enforce permissions and limits.
• The same model has different abilities in different products because the tool lists differ.

Summary

• Tools belong to the software around the model, not to the model.
• The software describes its tools to the model in text, next to the user's task.
• The model asks for a tool by writing a tool call.
• The software does the work and sends back the result as text.
• The model never touches files, websites, or other systems directly.
• A model can do in the outside world only what its tool list allows.