Hands for the Machine: Tools and APIs
By the end you'll be able to
- Explain tool use: the model writes a structured request, software executes it, results return to the desk.
- Explain why tools give exactness where the model alone approximates (arithmetic, dates, live data).
- Identify the new risk surface: the model can now act, so wrong actions replace wrong words.
- Predict
- Route
- Decide
- Field note
⚡ 30-second warm-up: from Lesson 5, what actually changed inside the model when it corrected an error you pointed out?
Nothing. The frozen dials never moved. Using it isn't training it. Today you'll meet a different way its abilities appear to grow, not by learning, but by phoning someone who already knows.
Ask a bare model 847 × 362 and it may miss. It's predicting digit patterns, not calculating. Ask a tool-equipped version and it's always right. It didn't get better at maths.
Start with a clean trick
Ask a plain assistant to multiply two large numbers and it sometimes stumbles. It's continuing a pattern of digits, not calculating (Lesson 1). Ask the same question to a tool-equipped version of the very same model, and it gets it exactly right, every time. Something else did the arithmetic.
Commit to a prediction
What changed to make the second answer always exact?
This lesson changes one thing: stop imagining the model "getting better" at maths, dates or live facts. Instead, picture it writing work orders. Each one is a structured request that other software carries out exactly, with the result handed straight back onto the desk.
Discover the mechanism
Developers describe the available tools to the model, right there in its context. It's a bit like handing the concierge a card: "there's a calculator; to use it, fill in this form." Mid-generation, instead of answering, the model can emit that form. This is a structured request sent through an API, a set format that another program can accept and act on. The surrounding system spots the request, runs real software, and pastes the result onto the desk (Lesson 10). Generation then resumes, now grounded in a true value.
The same shape covers weather lookups, calendar bookings, database queries, sending emails, running code. Notice what did and didn't change here. The model still only predicts tokens (Lesson 9). It has simply learned the pattern "for arithmetic, fill in the calculator form." Execution is exact; the decision to reach for it is still pattern-based guesswork. That's exactly where the new failure mode lives: a confidently mis-dialled work order now does something in the world, instead of just saying something.
real systems use formal function-calling formats and emerging shared tool protocols. This lesson keeps the "work order" shape as the load-bearing idea. Lesson 16 chains several of these calls into a self-directed loop.The concierge can't cook, drive or fix a leaking tap. But they can phone the kitchen, the taxi rank or the plumber, relay your need precisely, and fold the answer back into what they tell you. Their skill is knowing who to call and what to say. The phone directory itself is set by the hotel, not the concierge.
- Phone calls = structured tool requests. Kitchen, taxi rank, plumber = calculator, search, calendar, company systems.
- The callback = the tool's result, returned to the desk. Hotel management choosing the directory = developers deciding which tools exist and what they're allowed to do.
- Where it breaks: a human concierge understands what the guest actually needs and would raise an eyebrow at an absurd request. The model just emits the most plausible work order. That means it can call the wrong tool, or misread the result, fluently and with none of the friction a real person on the other end of the phone would provide.
Run the switchboard yourself
A scripted switchboard: fixed outcomes, so you can see the mechanism clearly. Three requests are queued. Route each one, then inspect the exact work order it produces.
Where this bites at work
Zane's assistant now checks live course availability through a tool, instead of asserting a plausible intake date from patterns. The very failure that opened this whole series (Lesson 1) is finally cured, at least for this one task. He's started asking any assistant the professional's question: "is this looked up, or generated?"
Before trusting an AI's "action", ask what it actually did. Did it generate words, look something up, or execute a change? Insist on approval gates for the third.
Retire this idea: "tool-using AI has learned maths, or gained real-world abilities." It hasn't. The abilities live in ordinary software; the model just gained a dialling pattern. That's still impressive, and still different, and it matters for judging reliability, because a wrongly dialled work order executes exactly as flawlessly as a correct one.
Now make the call
A prospective student emails Zane's team asking whether the January intake is still open. What should the assistant handling this do?
Try skipping the tool too. It's worth seeing, one more time, the fluent, confident, unverified guess this series opened with.
Apply it to your work
Find one AI-driven step at your workplace that actually does something, such as sending, booking, updating or paying, rather than just drafting words. Decide, explicitly, whether it needs a human approval gate before it acts. Write the rule down.
Prove it to yourself
Two quick questions, untimed and retryable. Answer both correctly, along with completing the lesson and the decision, and you earn ★ Mastered. This is what stops "that made sense" from evaporating by next week.
Explain it in your own words
Two or three sentences for a colleague. Then compare against the rubric, which checks ideas, not wording. Only you see your note.
✓ Lesson 14 stamped: Switchboard Operator
You routed three requests and watched exactness and live action replace pattern-based guessing. You also saw exactly where a human approval gate belongs. Lesson 15 asks: what does an assistant actually keep about you between chats?
Evidence & review — how we know what this lesson claims
| Claim | Type | Basis | Review risk |
|---|---|---|---|
| Tool use: the model emits a structured request; external software executes it; the result returns to context | How it works | Architecture documentation | Low |
| Tools provide exactness (arithmetic, dates, live data) where pure text generation only approximates | How it works | Architecture documentation | Low |
| Tool ecosystems and shared protocols are an actively evolving product area | Product behaviour | Provider / industry documentation | High — reviewed quarterly |
| The concierge switchboard demo | Teaching device | Deterministic, scripted illustration | Medium |
| The hotel-concierge analogy | Useful mental model | Limits stated in the lesson | Low |
Concept review due: January 2027. Product-behaviour claims: quarterly.
Where you are in the machine
The machine can now act in the world, not just describe it. Select any layer to see its role, its lessons, and your live progress.
The machine, bottom to top: training data (2) → token pieces (3) → prediction engine (1, 4–9) → the desk (10–11) → senses (12) → live knowledge (13) → tools (14) → memory (15) → agent loops (16) → human judgement (17–21).
Next: what it actually keeps
Retrieval gave it a library. Tools gave it hands. Both vanish when the conversation ends. Next: what AI systems can actually retain, the truth about "memory".