Tools for Agents: Giving Them Hands
In the agent loop we explored earlier, the decide step wants to take action but has nothing to grip with. That void is filled by tools. A language model, left to its own devices, can only produce words. Give it tools, and it can produce results. Tools are the hands attached to the model's brain — the conversion layer that turns a thought into a deed.
The name barely matters: tools, plug-ins, actions, functions, or skill libraries. What matters is that each one is a door the agent can open to touch the outside world. This article explains the common kinds of tools, how to define them for the model, and the practical discipline of keeping them safe and effective.
Why Tools Transform Agents
Before tools, an agent could answer questions about the world only from what it memorized during training. That memory goes stale and is riddled with gaps. A tool like an API call lets the agent pull fresh, ground truth whenever it needs it.
"A model without tools lives in a museum of its training data. A model with tools lives in the present."
Tools also confer agency. Reading is passive; calling an API that books a meeting is active. This shift from observer to participant is what separates a research assistant from an executive who can get things done.
The Toolbox
Most agent deployments rely on a small set of reusable tool families. Knowing them helps you decide what your agent needs first.
- Web search and browsing: the agent's eyes on the outside world — up-to-date news, documentation, pricing pages, and answers it did not memorize.
- REST and GraphQL APIs: the agent's hands reaching into your SaaS products — CRM, ticketing, calendars, payments, message platforms.
- Code execution: a sandbox where the agent can run Python, JavaScript, shell commands, and inspect results. Letting a model compute is like letting a human use a calculator instead of mental arithmetic.
- Filesystem and document tools: reading, writing, and transforming files, spreadsheets, and rich documents in an agent's working directory.
- Database access: querying rows, aggregating reports, and updating records with proper constraints.
- Knowledge retrieval: vector search over your internal documents so answers reflect your data, not just public training text.
That list covers the overwhelming majority of practical use. Most agents need only two or three of these to be genuinely useful.
How the Model Learns a Tool
The bridge between the model and a tool is a formal description. The model never sees the implementation — only a specification that declares what the tool does, what arguments it takes, and what the caller gets back. Think of it as a job posting for a function.
A good tool definition includes:
- A clear name you will recognize at a glance.
- A description of what the tool does and the situations where to use it.
- Parameters with names, types, and whether each is required.
- Documentation of defaults and parameter semantics.
Quality of these descriptions directly drives how often the model chooses the right tool with the right arguments. Write them like you are explaining to a capable colleague who has never seen your system. Ambiguous descriptors lead the model astray, so be specific about units, formats, and edge cases.
The Execution Boundary
Between "the model asked for a call" and "the call happened," there is a safety boundary where you decide whether to honor the request. This is the permission layer, and it deserves deliberate design.
- Read-safe by default: searches and reads are inexpensive to allow.
- Write actions require care: creating records, sending messages, and deleting data are higher risk and may need approval or guarded scopes.
- Idempotency: design so a repeated call does not multiply effects; an LLM might retry a mutation that already succeeded.
Sandboxing deserves special mention for code execution. Running model-generated code is powerful and hazardous. Industry practice is to run it in an isolated environment with no network, no secrets, and a hard time limit. The sandbox turns a dangerous ability into a useful one.
A Simple Recipe for Wiring a Tool
Here is the mental recipe for adding any tool to an agent. It looks trivial, and that is the point — the discipline is in the details.
- Write the function with a normal, documented interface.
- Define its schema so the model knows what to provide.
- Implement the caller that invokes the function and returns a structured result or error.
- Include enough in the result that the model can judge success and proceed.
- Apply permissions and sandboxing before exposure.
- Test with both happy paths and a deliberately messy input.
Done right, this is a few dozen lines per tool. Done sloppily, it is where every security incident lives.
Great Result Shape
The output of a tool is what the model reads to decide its next move. Shape it to help the loop. Prefer structured data — JSON objects with stable fields — over walls of prose. Summarize long results, truncate at sensible bounds, and always return errors explicitly.
Consider a search tool. Returning ten full web pages will blow a context budget and dilute the signal. Returning ten headlines, dates, and two-line snippets keeps the model focused. Tools that respect the loop's attention are tools the model actually uses.
Earned Capability
Teams that master agent tools tend to follow a predictable progression. They begin with unimpeachably safe tools: search and knowledge retrieval. Answers improve immediately. Next they add read-only data access so the agent can produce grounded reports from real records. Then, as trust builds, they add write actions scoped tightly — drafting, updating one field, sending under a quota.
Figure 1. Tools are the interface between the model's reasoning and the world's resources.
Each expansion should be reversible and logged. When an agent's write succeeds, someone should be able to see it, understand it, and undo it. This is how delegation becomes safe enough to trust.
Common Pitfalls
Practice reveals a reliable set of mistakes. Naming them now will save you debugging time later.
- Under-described tools: the model calls the wrong tool or supplies nonsense arguments because no one documented the interface.
- Overloaded tools: one tool that does three unrelated things is harder for the model to reason about than three focused tools.
- Unbounded execution: no timeout, no max resource use, no sandbox — and a runaway call costs you dearly.
- Vague results: the tool returns raw blobs, and the model cannot tell whether its action succeeded.
If your agent is misbehaving, audit the tool layer before blaming the model. The model learns its behavior largely from what the tools tell it. Clarity upstream shows up as competence downstream.
Tasting the Power
The day an agent runs real code in a sandbox and returns a computed answer, something clicks. The model is no longer reciting — it is computing. The day it probes an API, receives a fresh record, and crafts a reply from that live data, it stops being a parlor trick and becomes a colleague.
Figure 2. Live data flows in, actions flow out, and the model's answers are grounded in reality.
That is the promise of giving agents hands. But hands alone are not enough — the agent needs a place to write things down and remember what happened between turns. That is the subject of the final article in this series: memory and state.
"Give a model a brain, and you have a poet. Give it tools, and you have a worker. The difference is entirely in the hands."
