insideout Get Pro

06 · Letting the model call functions

Pro

Prompting, lesson 6

Letting the model call functions

Tool definitions, tool calls, and the loop that runs them.

You know how a chat request is put together ("How a chat request is built") and how a model can be held to a schema ("JSON that always parses").

Part 1. The model asks, your code acts

Ask a chat model "Is it hot in Pune right now?" and it has a problem. It was trained months ago. It has no thermometer and no internet. The best it can do from memory is a guess about Pune in general.

Now give it one extra piece of the request: a note saying "there is a function called get_weather, it takes a city". The model's reply changes shape. Instead of a sentence, it sends back a small structured message: call get_weather with {"city": "Pune"}.

Your turn

The model has replied with "call get_weather with city Pune". Who actually fetches the weather?

A model only produces tokens. The "call" is text in an agreed shape, nothing more. Your program reads it, decides whether to run it, runs the real function and sends the answer back. That split is the most useful thing to remember about tools: the model asks, your code acts.

Tool call

The model's reply when it wants a function run: the function's name, its arguments as a JSON object, and an id to match the answer to. Providers call the feature function calling or tool use. They mean one idea.

Because your code sits in the middle, you get a say. You can check the arguments, refuse a call, ask the user first, or log it. That matters a lot once untrusted text is involved, as Production AI shows from "How prompt injection works" on.

Part 2. Describing a tool to the model

Keep going with Pro

You've done the first part. Pro opens the rest of this lesson, and every other one.

Still to come
  1. Describing a tool to the model
  2. One trip round the loop
  3. Your code is the gatekeeper

Prompting overviewSpotted a mistake? Tell us.