Foundations — Tool use and function calling

Before you can read the parent note, you need a small toolbox of words. The parent note casually uses "JSON", "schema", "API", "argument", "context", "the loop". If any of those are fuzzy, the whole chapter blurs. This page builds each one from nothing, in an order where every idea rests on the one before it.

0. The picture we keep coming back to

Everything in this chapter is a message being passed around a small circle of three players. Fix this picture in your head now; every symbol below is a label on some part of it.

• The model (left) can only write and read text.
• The runner — your own program (middle) — is the only thing that can actually do anything.
• The outside world (right): weather services, databases, calculators.

The model never touches the right-hand side directly. It hands a note to the runner; the runner acts and hands an answer back. Keep this loop in view.

1. Text, tokens, and "the model only writes"

Why start here? Because every "magic" thing the model seems to do is really just it writing text that looks like an instruction. Understanding this removes 90% of confusion later: when the model "calls a tool," it is literally typing characters. Someone else reads those characters and acts.

2. Structured text vs. free text

The author could write "please bring me a large coffee, no sugar, thanks!" — but a robot parsing free English is fragile. So we agree on a rigid form instead.

The parent topic lives entirely in the second column. The single most important skill a tool-using model has is: switch from writing prose to filling in a rigid form on command. (See 5.2.03-JSON-mode-and-structured-outputs for how models are constrained to stay in that column.)

3. JSON — the shape of the form

The specific rigid shape this whole chapter uses is called JSON.

Read the figure slowly. A brace { opens an "object" — a bag of labelled slots. Every slot is "key": value. Commas separate slots. That is essentially the entire language.

Why JSON and not, say, a table or English? Because JSON is (a) plain text — so the model, which only writes text, can produce it; and (b) unambiguous — a program can validate it exactly. It sits perfectly at the meeting point of "a model can write it" and "a computer can trust it."

4. Function, argument, parameter

The model's letter is a request to run a function. Three words travel together here; they're easy to mix up.

So "the model generates a function call" means: the model writes which button (name) and what to write in each blank (arguments). That's the whole content of Step 2 in the parent note.

5. Schema — the description of the form

Before the model can fill a form, it must know the form exists and what its blanks are. That description is the schema.

The parent note's "required": ["location"] is a schema rule: this blank must not be left empty. The "enum": ["celsius","fahrenheit"] is another rule: only these two answers are legal in this blank. These rules exist so the model can't invent nonsense, and so the runner can reject a bad form early.

6. API — the thing on the other side

When the runner acts, it usually talks to an API.

Why does the chapter need APIs? Because APIs are where real, live facts live — today's weather, this user's calendar. The model's training data is frozen in the past; the API is the pipe to now.

7. Context, message, and role

The model's memory of the conversation is its context, and that context is a list of messages, each stamped with a role.

This is the key to understanding the loop. The model has no memory between turns — it re-reads the whole context every time. So when the runner gets a weather result, it can't just "tell" the model; it must append a new function-role message to the stack and let the model read the whole thing again. That appending is Step 4 in the parent note ("inject result back into context"). Nothing is remembered; everything is re-read.

8. The loop, now that every word is defined

With the vocabulary built, the parent note's four-step loop reads cleanly:

Every box uses only words this page defined. The dashed loop back to "model writes a function call" is the difference between a single-turn call (no loop) and an agentic loop (loop until done) — the two patterns in the parent note.

9. How these foundations feed the topic

Read bottom-up: an agent is just this loop running; the loop needs function calls, an API, and a growing context; a function call needs JSON, a schema, and correct arguments; and all of that rests on the single fact that the model only ever writes text.

Related paths once you're solid here: 6.2.02-Agent-architectures-and-planning (what wraps the loop), 4.3.02-Prompt-engineering-techniques (how the schema descriptions are written), 7.1.01-RAG-fundamentals (a common tool: retrieval), and the parent Hinglish version.

Equipment checklist

Cover the right side and answer aloud. If any answer is fuzzy, re-read that section.