hawkes.aiKey ideas
- The one idea — A model can't run code — "tool calling" means it emits a structured request (function name + JSON arguments), and the surrounding program (the harness) executes it and feeds the result back into context.
- How it is shown — The model, needing live weather, emitting get_weather(city="Paris") as JSON; the harness running the real API; the result pasted back; the model continuing with data it never had.
- The trap to avoid — Thinking the model itself runs the function — it only emits text describing the call; something outside executes it.
- What it sets up — Those tool descriptions you pasted in aren't free — they cost tokens every call.
Your AI never actually runs any code. When it checks the weather, it just writes a tiny structured request — and something else does the work. Here's who.
The one idea
A model can't run code — "tool calling" means it emits a structured request (function name + JSON arguments), and the surrounding program (the harness) executes it and feeds the result back into context.
A model is a text predictor. It can't check the weather, query a database, or send an email; it only produces tokens. And yet you've seen AI use tools, call functions, take real actions in the world. How? A clean trick, built entirely on the structured output you just learned. Here's the setup. Along with the user's question, you hand the model a list of tools it may use, each with a name, a description, and the arguments it takes. Get-weather takes a city; send-email takes a recipient and body. Now the model knows what's available. When the model decides it needs a tool, it doesn't answer in prose. It emits a structured request: the function's name and the arguments, as clean JSON.
How it works — the demo
The model, needing live weather, emitting get_weather(city="Paris") as JSON; the harness running the real API; the result pasted back; the model continuing with data it never had.
Get-weather, city Paris. That's the structured output from last group, often locked valid by constrained decoding. Producing that request is its whole job. Now the crucial part: the model does not run it. It can't. It only produced text describing the call. Something outside, the surrounding program or harness, reads that request and actually calls the real API. The model asked; the harness acted. That division never blurs. Then the result comes home. The harness takes the real answer, Paris, eighteen degrees, and pastes it back into the model's context as a new message.
The trap to avoid
Thinking the model itself runs the function — it only emits text describing the call; something outside executes it.
Why it matters — and what’s next
Those tool descriptions you pasted in aren't free — they cost tokens every call.
Now the model continues, holding live data it never had, and writes its reply. Ask, execute, feed back, continue. The trap: believing the model ran the code. It never does. It emits a request, just tokens, and a normal program does the doing. Every action is really two steps: the model choosing, and your code executing. Security, reliability, and control all live in that gap. So calling a function is the model emitting a structured request and a harness running it: text prediction plus plumbing. That's the atom every agent is built from. But those tool descriptions aren't free; they sit in your context, costing tokens every call. Next: your tools are eating your prompt.
This is one short episode in AI: Zero → Frontier, a step-by-step climb through how AI actually works. Each episode builds only on the ones before it.
Full transcript 2:45 of narration
A model is a text predictor. It can't check the weather, query a database, or send an email; it only produces tokens. And yet you've seen AI use tools, call functions, take real actions in the world. How? A clean trick, built entirely on the structured output you just learned.
Here's the setup. Along with the user's question, you hand the model a list of tools it may use, each with a name, a description, and the arguments it takes. Get-weather takes a city; send-email takes a recipient and body. Now the model knows what's available.
When the model decides it needs a tool, it doesn't answer in prose. It emits a structured request: the function's name and the arguments, as clean JSON. Get-weather, city Paris. That's the structured output from last group, often locked valid by constrained decoding. Producing that request is its whole job.
Now the crucial part: the model does not run it. It can't. It only produced text describing the call. Something outside, the surrounding program or harness, reads that request and actually calls the real API. The model asked; the harness acted. That division never blurs.
Then the result comes home. The harness takes the real answer, Paris, eighteen degrees, and pastes it back into the model's context as a new message. Now the model continues, holding live data it never had, and writes its reply. Ask, execute, feed back, continue.
The trap: believing the model ran the code. It never does. It emits a request, just tokens, and a normal program does the doing. Every action is really two steps: the model choosing, and your code executing. Security, reliability, and control all live in that gap.
So calling a function is the model emitting a structured request and a harness running it: text prediction plus plumbing. That's the atom every agent is built from. But those tool descriptions aren't free; they sit in your context, costing tokens every call. Next: your tools are eating your prompt.