Tool use

Tool use is the pattern underneath every other one. A model on its own can only produce text; give it tools — functions it is allowed to call, such as “read a file”, “run this command”, “search the web” — and the same model starts to act. The agent loop is short: the model reads the goal and the tools available, emits a call (a tool name and its arguments), your harness runs that call and feeds the result back into the model’s context, and the loop repeats until the goal is met or it gives up.

For example, a coding agent given three tools — read a file, edit a file, run the tests — can fix a bug on its own: it reads the failing test, edits the source, runs the tests, reads the new failure, and tries again. None of that is the model being smarter; it is the model given tools and a loop.

Everything else in this handbook assumes this pattern. Multi-agent orchestration is several tool-using agents coordinating; retrieval (RAG) is a “search the documents” tool; the multi-machine stack is tool-using agents spread across machines.

Designing the tools

The agent is only as reliable as the tools you hand it, so the work is in the tool set, not the prompt. A few rules, in rough order of how often they matter:

1. Start with few tools, add slowly. A small set the agent uses correctly beats a large set it uses unpredictably. Add a tool only once the agent reliably handles the ones it has.
2. Make each tool hard to misuse. Clear names, validated arguments, and safe defaults — because an agent will eventually call every tool it has, sometimes with the wrong arguments. The tool, not the model, is where you enforce what is allowed.
3. Return errors the agent can act on. A clear message (“file not found: X”) lets it recover on the next turn; a vague or silent failure sends it into a loop or a confident wrong answer.
4. Scope what each tool can reach. Every tool an agent can call is one it will call by mistake, so give it the narrow capability the task needs and no more — read-only where reads are enough, a single directory rather than the whole disk.

What tools do not fix

Tools make an agent capable, not careful. More of them widen what it can do and, in the same step, what it can get wrong — so the goal is a small set of reliable tools, not a big set of possible ones. A tool that can delete data, deploy, or spend money is one the agent will eventually trigger at the wrong moment, which is why the risky ones belong behind a confirmation or outside the agent’s reach entirely.

Where to go next

• Coordinate several tool-using agents: Multi-agent orchestration .
• See the loop defined plainly: What agentic AI is .