Tool Use Patterns for AI Agents: Best Practices

An AI agent without tools is just a chatbot with delusions of grandeur.

Tools are what make agents useful. They turn "I think the answer might be" into "I checked, and here's what I found." They transform suggestions into actions. Without them, you have a very articulate parrot. With them, you have something that actually gets work done.

But here is the thing most people get wrong. The tool itself matters less than how you describe it to the agent.

Your agent decides which tool to use based entirely on the description you wrote. That is it. No magic. No deep understanding of your codebase. Just a text description and a prayer. So if your description is vague, your agent will pick the wrong tool. Guaranteed.

Write descriptions like you are explaining to a smart new hire on their first day. What does this tool do? When should they use it? What do they need to give it? What will they get back? Skip any of those four questions and you are asking for trouble.

I learned this the hard way. Had an agent with two similar tools. One queried live data, one queried cached data. The descriptions were almost identical. The agent picked randomly between them. Users got stale data half the time and nobody could figure out why. Added one sentence to each description clarifying the freshness tradeoff. Problem gone overnight.

Composite Tools Beat Primitives

This is counterintuitive if you come from a software engineering background. We are trained to build small, composable functions. Single responsibility. Unix philosophy. All of that.

Agents do not think like developers.

Give an agent five granular tools and it has to make five correct decisions in sequence to accomplish one task. Read file. Parse JSON. Filter results. Format output. Send response. Five chances to go wrong. Five places where the chain breaks.

Give it one tool called "query_and_format" that handles the entire pipeline internally. Now it makes one decision. One chance to get it right. And the success rate jumps dramatically.

I have seen this pattern repeatedly across dozens of agent deployments. The teams that build fewer, smarter tools consistently outperform teams that expose every internal function as a tool. It is not even close.

There is a limit to this, obviously. A tool that does everything is just another monolith. The sweet spot is what I call "task-level tools." Each tool completes one meaningful unit of work from the user's perspective. Not one function call. One task.

A user does not think "read file, parse JSON, filter by date." They think "get me last week's sales numbers." Build the tool around the user's mental model, not your code's architecture.

Error Messages Are Instructions

Most developers treat error handling as an afterthought in tool design. Return an error code. Maybe a generic message. Move on.

For agent tools, error handling is arguably more important than the happy path.

When a tool fails, the agent needs to decide what to do next. Retry? Try a different tool? Ask the user for help? Give up? That decision depends entirely on what information the error message provides.

A bad error message: "Error: table not found."

The agent has no idea what to do with this. It does not know what tables exist. It does not know if it made a typo or if the table was deleted. So it either gives up or retries the exact same query. Neither helps.

A good error message: "Table 'user_metrics' not found. Available tables: users, orders, products, analytics_events. Did you mean 'analytics_events'?"

Now the agent can self-correct. It has context. It has options. It can try the suggested alternative without bothering the user. This is the difference between an agent that feels intelligent and one that feels broken.

Validation Before Execution

Smart tool design validates inputs before doing anything destructive. If an agent is about to delete records, the tool should first confirm how many records match the criteria and return that count for approval. Do not trust the agent to ask for confirmation on its own. Build it into the tool.

This is a pattern I call "preview mode." Every tool that modifies state should have a dry-run option. The agent calls the tool with "preview: true", gets back what would happen, presents that to the user, and then executes with "preview: false" after approval.

Sounds like extra work. Saves you from explaining to a client why their production database is empty.

Rate Limiting and Timeouts

Tools need guardrails that the agent cannot override. Set maximum execution times. Limit how many times a tool can be called per session. Cap the amount of data a tool can process in one call.

Agents are optimistic by nature. They will happily call your API tool a thousand times in a loop if the first 999 calls did not return the result they wanted. Without rate limits, you get a surprise bill and an angry infrastructure team.

Build these limits into the tool itself, not into the agent's instructions. Instructions are suggestions. Tool-level limits are enforced.

The Testing Gap Nobody Talks About

Here is what nobody warns you about. Testing tools in isolation tells you almost nothing about how they perform with an actual agent. A tool can work perfectly in unit tests and fail catastrophically when an agent uses it in unexpected ways.

Agents call tools with inputs you never imagined. They chain tools in orders you did not design for. They pass the output of one tool as the input of another in ways that technically work but produce garbage results.

The only testing that matters is integration testing with a real agent running real scenarios. Build a test suite of 20-30 common tasks. Run them daily. Track success rates over time. When a tool change breaks agent behavior, you will catch it before your users do.

Tool design is not a one-time activity. It is an ongoing conversation between your code and your agent. Pay attention to what the agent does with your tools. Watch where it struggles. Refine relentlessly. The quality of your tools determines the ceiling of your agent's capabilities.