Most talk about AI agents focuses on the model: which one is smartest, which one is newest. In practice, what decides whether an agent is useful to your business is something far less exciting. It is the set of tools the agent is allowed to use. A brilliant model with no tools can only talk. An ordinary model with the right four tools can take real work off your team.
What a tool is
A tool is a small, specific action the agent can ask the surrounding software to perform. Examples:
- Look up the stock level for a product code.
- Find a customer’s last five orders by phone number.
- Calculate the courier charge for a district and weight.
- Create a draft order that waits for approval.
- Send a message on WhatsApp using an approved template.
Each tool has a name, a description, a list of details it needs (such as the product code) and a result it returns. The model reads the descriptions and decides which one to call. The software then does the actual work and hands back the result.
This separation is important. The model never touches your database directly. It asks, and the software decides whether and how to answer. That is where you get control.
Why tools matter more than the model
Think about hiring a capable new staff member and then giving them no access to the order book, the stock sheet or the phone. They would be pleasant to talk to and useless in practice. Agents are the same.
The tools decide:
- What the agent can know. If there is no tool to check stock, it cannot tell a customer whether something is available. It might guess, which is worse.
- What the agent can do. If there is no tool to create an order, it can only tell a person to create one.
- What the agent cannot do. If there is no tool to issue refunds, it cannot issue one by mistake, however confused it gets.
That last point is the one managers often miss. The tool list is also your safety fence. Anything not on the list is simply impossible for the agent.
Designing good tools
One job per tool
A tool called “manage order” that can create, edit, cancel and refund is hard for the model to use correctly and hard for you to control. Split it into separate tools. Then you can give the agent “create draft order” and keep “cancel order” for people.
Plain names and honest descriptions
Name tools the way you would explain them to a new employee. “check_stock: returns the current quantity on hand for one product code. Use before confirming any order.” Say when not to use it too, if that is likely to cause confusion.
Return clear results, including failures
If a product code does not exist, the tool should say “no product found with code TEA-RED-500”, not return an empty result. The agent can act sensibly on a clear failure. It often misreads silence as success.
Draft rather than commit
Where an action affects a customer, money or something hard to undo, make the tool create a draft or a pending item. A person approves it. This one design choice removes most of the serious risk from an agent.
Limiting tools properly
Every tool should come with limits enforced by the software, not by the agent’s good behaviour:
- Scope. The “find customer orders” tool only returns orders for the customer in the current conversation, never the whole database.
- Value caps. A tool that offers a discount refuses anything above a set amount.
- Rate limits. A tool that sends messages will not send more than a set number per hour, so a loop gone wrong cannot flood your customers.
- Read-only where possible. Many useful agents only need to read. Give write access only where the task truly needs it.
Each tool call should also be logged: which tool, what details, what came back and when. When something goes wrong, the log tells you whether the agent chose badly or the tool behaved badly.
Where tools run out
Tools depend on your existing systems being reachable. If your stock lives in a spreadsheet on one laptop, or your orders are in a notebook by the till, there is nothing for a tool to connect to yet. The first step in those cases is not an agent at all. It is getting the information into a system that software can read. That work is less glamorous, but it is often where the real gain lies, and it helps your staff even if you never build an agent.
Tools also do not fix unclear processes. If your team does not agree on when an order counts as confirmed, no tool design will settle that for you.
A useful exercise: list the five actions a staff member takes most often when handling one customer request. For each, note which system holds the information and whether it can be read by software today. That list is the draft tool set for your first agent, and the gaps in it show where the preparation work lies. If you want a structured way to sketch this, the agent blueprint tool can help.