Somewhere in the last part, a model stuck inside a frozen file made a plan involving a weather tool. This part opens that door, and behind it sits the most important demystification in the series after the transcript trick. Ready? The model cannot do anything. It cannot browse, click, fetch, run, save, or measure. It has no hands. Everything in this part, tool use, agents, "the AI booked my flight", is built on a machine that can only do what Part 1 said: continue text. What the layers add is a way for continued text to cause things.
The model can only ask
Remember the tools line in Part 5's order ticket. When an app sends a request, it can include a list of actions that it, the app, is able to perform: "I can check the weather for a city. I can search the web. I can read a file." Each comes with a plain description of what it does and what details it needs.
Now the model has an option it did not have before. Instead of replying with prose, it can reply with a tool call: a small structured request, not meant for human eyes, that says in effect, call get_weather, city = Paris. And then it stops.
Read that again, because the phrasing is doing careful work. The model emitted a request. It did not check the weather. It cannot. The app receives the request, and the app, ordinary software written by ordinary programmers, actually calls the weather service. The answer, 24°C and sunny, gets pasted into the transcript as a new message, the same way every other message in this series has travelled. The whole, now-longer conversation runs through the layers again, the model reads the tool's result sitting there in the text, and this time it writes the human sentence: "It's 24°C and sunny in Paris right now."
So when a product announces that "the AI searched the web", the truthful version is always: the AI asked, the app searched, and the transcript grew. The model never touches the internet, a file, or a thermometer. What was engineered is a conversation protocol in which certain continuations of text, the structured ones, get acted on by the software around the model. If you build things and want the practical version, the tool calling article in the Building AI Agents series picks up exactly here.
An agent is a loop
Which brings us to the most inflated word in the industry. An AI agent is this: the model proposes an action, the software performs it, the result goes into the transcript, and the model proposes the next action, around and around, until the model declares the job done. That is the whole secret. Take tool calling, put it in a loop, and you have an agent.
Everything else agents are known for is guardrails bolted onto that loop by sensible engineers: budgets on how much it may spend, limits on how many steps it may take, and a human-approval gate in front of the risky actions, the deletes and the payments and the emails. A coding agent that "worked on the problem for an hour" ran that loop a few hundred times. "Agentic" names a loop, not a new kind of mind, and whenever a headline says an AI "did something on its own", you can now ask the precise question: what was in the loop, and who wrote the guardrails? The Building AI Agents series covers constructing these loops, and its guardrails article covers fencing them.
Why the words arrive one at a time
A smaller mystery this part can retire on the way past: the typewriter effect. Words appearing one at a time is not an animation, and it is not the interface being dramatic. That is generation, live. Each token is drawn from Part 1's ranked list and shipped to your screen as it happens, at anywhere from tens of tokens per second on a home setup to low hundreds from a fast cloud service. Streaming also explains a real limitation: a model cannot go back and repair the start of a sentence it is halfway through, because those tokens are already part of the text being continued, and already on your screen. When an answer starts badly, the model's only options are to plough on or contradict itself, which is worth remembering next time you watch one do exactly that.
When the answer must fill a form
Sometimes the app needs an answer that a program can read: a table, a form, a precise yes-or-no. There is a protocol for that too, called structured output. The app describes the required shape, and the server constrains generation so that only text fitting that shape can emerge. The mechanism is a neat callback to Part 1: at every step the model produces its ranked list as usual, and the server strikes out every candidate token that would break the structure before one is chosen. The model is not being obedient. Its options are being filtered, one word-chunk at a time.
When models talk to each other
Finally, the sci-fi one: systems where several models cooperate, or a "manager" model directs "specialist" models. It is easy to picture something exotic, models murmuring to each other over a private channel. Here is the reality, and after six parts you can guess it: one model's output is pasted into another model's input by ordinary software, through the same waiters and the same order tickets as everything else in this series. A multi-agent system is a group chat where software plays postman. The one honest wrinkle in that analogy: this postman also decides who speaks next, because the orchestrating software chooses which model sees which text and when.
Two closing notes for the curious. The manager-and-specialists arrangement is called an orchestrator pattern, and it is tool calling wearing a suit: to the manager model, each specialist is another tool to ask for. And the plug problem, a thousand apps needing to offer tools to a thousand models, is being standardised by something called MCP, the Model Context Protocol, doing for tools what the OpenAI-compatible format did for chat. (It brings its own security puzzles, which I've written about on the blog.)
Every layer has now been visited. One thing remains, and it is the payoff the whole series has been assembling: running our Paris message through the entire stack, top to bottom and back, in ten numbered steps you can keep.
Next: The Whole Journey, End to End: ten steps, one diagram, a glossary to keep, and why any of this matters to what you pay, what you trust, and what you believe about AI.