The Improviser · Lesson 9 — Calling In a Guest ← Course

Calling in a guest — tool calling.

Fluent with language, a model still can't count exact beats, look up last night, or transpose note-for-note. So you give it a roster of specialists to call.

When a model hits something it can't do reliably on its own, you don't want it guessing. So you hand it a set of tools it's allowed to use, and let it call on them. This is tool calling (also “function calling”).

Here's the part that trips people up, and it's the same shape as retrieval last lesson: the model does not run the tool. It requests one — naming the tool and its inputs — and a real program on your side runs it and hands the result back. The model reads that result and plays on.

A band leader works the same way. Can't keep flawless time in their head? Call the metronome. Can't recall last night's exact set? Check the session log. Can't transpose a chart on the spot? Hand it to the arranger. The leader calls the specialist in, the specialist does the work, and the leader folds the result back into the tune.

So the model's real skill here is judgement: turning a vague ask into the right tool with the right inputs, then reading the answer correctly. And in a real LLM that answer comes back as plain text dropped into its context — the model can't confirm the tool actually ran, only trust what it reads.

Ask the soloist something it can't settle by ear alone. Watch it call in the right specialist — then play on from what they hand back.

Pick an ask. The soloist calls for a specialist — it never does the work itself.
the ask
① the model asks for a tool model · requests, doesn't run
② the specialist runs and hands it back the tool · not the model
③ the model reads it and answers model

Ask, run, read.

You hand the model the tools; it hands you back a request; your code runs the tool and gives it the result. The model only ever reads text.


      

The model decides; the tool does.

Tools give a model powers it doesn't have on its own — exact timing, live facts, real actions. But it never does them itself: it picks the right tool and inputs, your code runs the tool, and the model reads the result and plays on. Its job is judgement, not execution.

Retrieval, last lesson, was really just one tool — a search. Tool calling is the general version: hand the model a whole kit of specialists, and let it call whichever the moment needs.

Go deeper — how tool calling really works optional

The request is structured, not a wish

A tool call isn't the model muttering “grab the metronome”. It's a precise, machine-readable request — the tool's name and its inputs, filled in from a schema you provided. That is what lets your code actually run it. Half the craft is describing each tool clearly enough that the model fills the inputs correctly.

The model can't execute — you do

The model produces text, full stop. It has no hands: it can't hit an API, run a query, or press record. Everything real happens in your code, which chooses to honour the request, runs the tool, and passes the result back. That gap is also your safety boundary — you decide which requests to allow.

It can ask for the wrong thing

The model can pick the wrong tool, or fill an input badly — call the arranger when it needed the session log. Tools don't make it infallible; they just extend its reach. Validate the request before running it, and check the result makes sense.

Tools are how a model acts on the world

Reading data is one thing; tools can also do things — send an email, book the studio, kick off a render. The same ask-run-read loop applies, but now the “run” step has real consequences, which is why an action tool deserves far more caution than a read-only one.