Lesson 4 — Tools and agents
A model that only produces text is limited to what its weights contain. Give it the ability to call things, and the limitation largely disappears — along with a new set of problems.
Function calling, which is simpler than it sounds
You describe the available tools to the model: names, what they do, what arguments they take. When the model decides a tool would help, it emits a structured request instead of prose:
{"tool": "get_weather", "arguments": {"city": "Tunis"}}
Your code sees that, calls the actual function, and puts the result back into the context. The model continues with the answer in hand.
Two clarifications that matter, because this is widely misunderstood:
The model never executes anything. It emits a request; your code decides whether and how to honour it. Every security control lives on your side of that boundary, which is the good news in lesson 5's bad news.
The tool descriptions are just text in the context. The model chooses tools by reading their descriptions, so a badly-worded description produces a badly-chosen tool. Writing tool descriptions is prompt engineering with a different name, and it is where most tool-selection failures originate.
This one mechanism removes several structural weaknesses at once:
| Weakness | Tool that removes it |
|---|---|
| Cannot do arithmetic | A calculator, or code execution |
| Knowledge cutoff | Web search |
| Does not know your data | A database query, or retrieval |
| Cannot act | An API call |
| Cannot verify its own code | Running it |
Note the pattern: rather than making the model better at arithmetic, you stop asking it to do arithmetic. Delegating to a component that is exactly right is more reliable than improving a component that is approximately right, and it is the most productive idea in this lesson.
From tools to agents
An agent is a model in a loop, deciding what to do next.
The pattern — reason about what to do, act, observe the result, reason again — is often called ReAct, and it is what allows a system to research a question across several searches, or debug code by running it and reading the error.
The appeal is obvious. So is the problem.
Why reliability decays, in numbers
Each step has an error rate, and the steps multiply.
| Per-step reliability | 5 steps | 10 steps | 20 steps |
|---|---|---|---|
| 95 % | 77 % | 60 % | 36 % |
| 90 % | 59 % | 35 % | 12 % |
| 99 % | 95 % | 90 % | 82 % |
A model that gets each individual step right ninety-five percent of the time — which is good — completes a twenty-step task about a third of the time. And the failures are not clean: a wrong intermediate result gets built upon, so the agent proceeds confidently down a path that was invalidated ten steps ago.
This is why demonstrations of open-ended autonomous agents impress in a demo and disappoint in production. The demo is a successful sample from a distribution with a long tail of failures.
Worse, the failure modes are specific and recognisable:
Loops. The agent repeats an action that did not work, sometimes indefinitely.
Compounding errors. One wrong assumption propagates through everything after it.
Cost explosion. Every step is a model call. A stuck agent can spend real money going nowhere, which is why hard step and budget limits are not optional.
Silent wrongness. The agent produces a confident, plausible, wrong result. This is the dangerous one, because nothing signals failure.
Tool misuse. Wrong tool, or right tool with wrong arguments, particularly when many tools have overlapping descriptions.
What actually works
The designs that survive production share a shape:
Few steps. Three to five, not thirty. Decompose a long task into several short bounded ones with checkpoints between.
Few tools. Five well-described tools beat thirty overlapping ones. Selection accuracy falls as the menu grows.
Verification after each step. Where a step's output can be checked programmatically — schema validation, running a test, a range check — check it. This raises per-step reliability, and per-step reliability is what the table above compounds.
Hard limits. Maximum steps, maximum spend, maximum time. Every one of them, enforced in code.
Human approval before consequential actions. Reading is safe; sending, paying, deleting and publishing are not. Gate those.
Constrained scope. "Research this question using these two sources" works. "Handle this customer's problem" does not.
The reliable pattern in 2026 is a narrow agent: a small, well-specified task, a handful of tools, a few steps, verification, and a human at the point where something irreversible happens.
Multi-agent systems
Several models with different roles, passing work between them — a planner, a researcher, a critic, a writer.
The genuine benefits: separation of concerns makes each prompt simpler, and a dedicated critic step catches errors that the producing model will not catch in the same turn.
The genuine costs: every handoff is a place to lose information, cost multiplies by the number of participants, debugging becomes considerably harder, and the reliability arithmetic above now applies across the whole ensemble rather than one chain.
Worth trying when a single agent has a clearly identifiable weakness that a second role addresses. Not worth adopting as a default architecture, which is the mistake the current enthusiasm encourages.
Standardising tool access
A practical development worth knowing about: rather than every application implementing its own integration for every tool, protocols such as the Model Context Protocol define a common way for models to discover and call external capabilities. Connect a compliant server once and any compliant client can use it.
This is plumbing rather than a capability change, and plumbing determines what gets built. The security implication is direct and covered in lesson 5: the easier it becomes to connect tools, the more carefully you need to think about what a compromised model could reach.
In three sentences
Function calling lets a model emit a structured request that your code executes, which removes whole classes of weakness — arithmetic, currency, private data, action — by delegating to components that are exactly right rather than improving a component that is approximately right. An agent is that mechanism in a loop, and its reliability compounds badly: a model that is right ninety-five percent of the time per step completes a twenty-step task about a third of the time, with failures that build confidently on invalidated assumptions rather than stopping. The designs that work in production are narrow — a handful of well-described tools, three to five steps, programmatic verification after each one, hard step and spend limits, and human approval before anything irreversible.