What is Tool Use? — one analogy

1The analogy

Say you are reheating a bag of frozen dumplings. The kitchen has a microwave, an air fryer, and a steamer. Which one you pick changes the result completely. Want it fast, use the microwave. Want the outside crisp, use the air fryer. Want it soft and moist, use the steamer.

Once you pick, you set the time and press start. That is not the end, either. When it is done, you open it up and check, and if the middle is still cold, you run it a little longer. And on days you are fine eating straight from the bag, you do not reach for any of them.

Deciding what to hand the job to, handing it off, checking the result, and deciding again: that whole loop is tool use.

2In detail

Why hand it a means at all

A model is extremely good at continuing text based on what it has learned. What it cannot do is a separate matter. It has never learned about something that happened yesterday, long arithmetic tends to drift when done by continuing text, and it has simply never seen the document sitting in your own drawer.

Anything happening out in the world is even further out of reach. Sending an email or booking an appointment does not happen just because a sentence describing it was written well. However well-crafted the words, they do not turn into an email on their own.

So it gets handed a means: a way to look things up, a way to calculate, a way to open a document, a way to actually carry something out. It is a way of splitting what it is good at from what it is not, and pushing the parts it is not good at outward.

Deciding what to use

Handing over several means does not automatically mean it uses them well. It has to judge whether this question needs a means at all, and if so, which one. That judgment is half of what tool use actually is.

Pick wrong and the whole result wobbles. Sometimes it slows itself down looking things up when it already knew the answer; other times it makes something up on the spot when it should have looked something up instead. Either way, it can look just as convincing to a person reading it, which makes the mistake hard to catch.

Having more means to choose from actually makes choosing harder, the same way ten different appliances in a kitchen just gets confusing. Each means needs a short, clear description of exactly what it is for, or the picking goes wrong more often.

Taking the result and continuing

Handing something off gets a result back. That result does not automatically become the answer. The model reads what came back, weighs it against the question, and pulls together only the part it needs into a sentence.

One more judgment call happens right here. If the result comes back empty or off-target, it has to try again: rephrase the search and look again, switch to a different means, or just say plainly that it could not find anything. It is the same as opening the dumplings back up and running them a little longer if the middle is still cold.

The fact that this loop can run more than once matters too. Some things finish in one pass; others keep going, where a search result leads to another search.

Calling something and using it are different things

There is a narrower, plainer idea sitting next to this one: the fixed, agreed way of calling a means. That one is about the calling convention — each means has a name, a fixed shape for what goes in, and a fixed shape for what comes back out. Think of it as the procedure for filling out a form and handing it over.

Tool use sits a layer above that. It assumes the form exists, and deals with when to pull that form out, whether to trust what comes back, and what to do next. Having the form with no judgment behind it means nothing happens at all.

Push this one step further and it becomes an agent. Once the loop of reaching for means runs on for a while and starts touching things that cannot be undone, that is the point where a person needs to be checking in.

3More precisely

Reaching for a means does not mean the model physically does anything itself. What actually happens is it writes out a description of what means to call and how, an outside program reads that and carries it out on its behalf, and the result gets turned back into text and handed to the model. From start to finish, the model only ever trades in text.

The kitchen comparison breaks down somewhere too. A person can see and tell when a dumpling is undercooked; a model has a much harder time checking on its own whether the text that came back is actually correct. It can end up trusting and carrying forward a wrong value a means handed it. A broken appliance at least shows some sign of it; a means can quietly hand back a wrong value with no sign at all.

It is worth noting, too, that handing over a means is really handing over permission. A means that only reads and one that changes something carry very different stakes when they go wrong. That is why, when attaching a means, what it is allowed to do usually gets narrowed down to exactly what is needed, alongside a log of what got called and when.

4Try it yourself

5Common misconceptions

It's easy to think attaching a means makes the model smarter, but actually the model stays the same — what widens is the range of things it can get done.
It's easy to think a result that comes back is always correct, but actually it can come back empty or wrong, and trusting it and moving on regardless is a common failure.
It's easy to think more is always better, but actually the more there are to choose from, the more often the wrong one gets picked.

7One-line summary

In shortTool use is handing off what a model cannot do to an outside means and continuing from the result, and the judgment behind what to use is what separates it.

Did this analogy help?

Spotted an error or have a better analogy? Suggest an edit · Last updated2026-09-02