0.2 Tools — giving a model hands

We just established that a model has no hands — it only emits text. Yet agents clearly do things: they search, send messages, update records, run code. How?

The answer is a single, slightly sneaky idea that everything else depends on.

The model asks; the program acts

The model never performs an action. When it needs one, it produces a request — a little structured message that says “please run this tool with these inputs.” The program wrapped around the model reads that request, runs the real function, and hands the result back.

A tool is nothing more exotic than a function the surrounding program agrees to run on the model’s behalf. getWeather, sendEmail, searchDocs — ordinary code. The model can’t call them; it can only ask for them.

Step through one real tool call and watch the hand-off happen:

Tools this agent hasgetWeatherreads the worldsearchDocsreads the worldsendEmailchanges the worlddeleteRecordchanges the world

1The question

user

What's the weather in Paris right now?

The user asks something the model can't possibly know on its own.

Step 1 of 4

The moment that matters is step 2. Look at what the model produced: not the sentence “Let me check the weather,” but a structured object —

{ "tool": "getWeather", "args": { "city": "Paris" } }

That’s the whole trick. Because the output is structured data instead of prose, the program can reliably act on it. Then the program — never the model — runs the function and feeds the result back for the model to phrase nicely.

Safe tools and dangerous tools

Notice the tool shelf at the top of the demo had two colours. That split is going to matter for the rest of the guide, so let’s name it now.

Safe tools read the world — getWeather, searchDocs. If the model asks for one at the wrong time, the worst case is a wasted lookup.
Dangerous tools change the world — sendEmail, deleteRecord, runCode. If the model asks for one at the wrong time, it sends the wrong email or deletes the wrong row. There is no undo.

A demo agent happily runs both. A production agent cannot — which is exactly why later we put a policy gate in front of every tool (2.2 Sandboxed tools) and require a human’s approval before the dangerous ones fire (2.6 Human-in-the-loop).

The catch that creates everything else

Re-read the demo’s last two steps. The model made a request, the tool ran, and the result came back… to the model, which then had to be called again to use it.

One tool call already needed two trips to the model. A real task needs many. The model can’t drive that repetition itself — it runs once per call, remember. Something has to keep calling it.

That something is the loop, and it’s next.