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. Ask a tool-equipped one and it's always right. It didn't get better at maths.
Start with a clean trick
A plain assistant asked to multiply two large numbers sometimes stumbles — it's continuing a pattern of digits, not calculating (Lesson 1). A tool-equipped version of the very same model 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: you'll stop imagining the model "getting better" at maths, dates or live facts, and start seeing it write work orders — structured requests other software carries out exactly, with the result handed straight back onto the desk.
Discover the mechanism
Developers describe available tools to the model in its context ("there is a calculator; to use it, write this form"). Mid-generation, instead of answering, the model can emit that form — a structured request through an API, a set format another program accepts. The surrounding system spots it, runs real software, and pastes the result onto the desk (Lesson 10). Generation resumes, now conditioned on a true value.
The same shape covers weather lookups, calendar bookings, database queries, sending emails, running code. Notice what did and didn't change: the model still only predicts tokens (Lesson 9); it has simply learned the pattern "for arithmetic, emit the calculator form". Perfect execution, pattern-based dialling. That asymmetry defines the new failure mode too: 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 taps — but can phone the kitchen, the taxi rank and the plumber, relay your need precisely, and fold the callback into their answer. Their skill is knowing when to call whom and what to say; the phone directory 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 may do.
- Where it breaks: a concierge understands the guest's need and notices absurd requests; the model emits the most plausible work order, so it can call the wrong tool or misread the callback — fluently, and without the friction a human on the other end of a phone would provide.
Run the switchboard yourself
Conceptual illustration — a scripted switchboard, deterministic. Three requests are queued. Route each one, then inspect the exact work order.
Where this bites at work
Zane's assistant checks live course availability through a tool rather than asserting a plausible intake date from patterns — the very failure that opened this whole series (Lesson 1) is finally cured, for this one task. He now asks any assistant the professional's question: "is this looked-up, or generated?"
Before trusting an AI's "action", ask what it actually did: generated words, looked something up, or executed a change — and insist on approval gates for the third.
"Tool-using AI has learned maths, or gained real-world abilities" is the misconception to retire. The abilities live in ordinary software; the model gained a dialling pattern. Impressive, different, and important for judging reliability — 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 — worth seeing the fluent, confident, unverified guess this series opened with, one more time.
Apply it to your work
Find one AI-driven step at your workplace that actually does something (sends, books, updates, pays) rather than just drafting words. Decide, explicitly, whether it needs a human approval gate before it acts — and write the rule down.
Prove it to yourself
Two quick questions — untimed, retryable, and they count toward ★ Mastered (completed + decision + self-check all correct). This is what defeats the feeling of "that made sense" evaporating by next week.
Explain it in your own words
Two or three sentences for a colleague. Then compare against the rubric — it checks ideas, not wording, and only you see your note.
✓ Lesson 14 stamped: Switchboard Operator
You routed three requests and watched exactness and live action replace pattern-based guessing — and 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 for its role, 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".