Only as many as its role needs, and usually fewer than teams start with. Each tool is a choice the model must get right and a capability the platform must bound and certify. A narrow role with a handful of distinct tools beats a broad one with dozens. When the list keeps growing, the role is probably two roles.
Why does tool count matter?
Three costs rise with every tool you add.
Selection errors. The model chooses tools by reading their names and descriptions. With a few distinct tools, it rarely picks the wrong one. With many overlapping ones, such as three ways to update a customer, it picks a near miss more often.
Governance surface. Each tool maps to a capability with its own depth, limits and approvals. More tools mean more bounds to set, review and keep current.
Certification effort. Each capability must be proven on real cases. A tool the agent uses rarely is hard to certify, because there are few cases to replay, and it tends to sit at low depth anyway.
None of these is a hard ceiling. They are reasons to justify each tool rather than add tools in case they are useful.
Which factors push the number up or down?
| Factor | Pushes the count | Why |
|---|---|---|
| Breadth of the role | Up | More business actions need more tools |
| Overlap between tools | Should push down | Overlapping tools confuse selection |
| Mixed reversibility | Up, deliberately | Read, draft and act should be separate tools at different depths |
| Rare actions | Down | Rare actions are better held for a person than given a tool |
| Generic tools | Down, but at a cost | One generic tool replaces several, and cannot be bounded precisely |
| Shared reference lookups | Neutral | A common lookup tool used by many agents is fine |
Note the trade-off in the generic row. Replacing ten narrow tools with one "call the API" tool reduces the count and destroys the ability to govern what the agent does. Fewer is better only if each tool still maps to one business action. Design guidance is in how to design tools for AI agents.
How do you plan the right set?
- List the business actions the role needs. Not system endpoints: actions such as "change delivery address" or "waive a late fee".
- Split by reversibility. Read, draft and perform are separate tools, because they sit at different depths.
- Merge true duplicates. Two tools that do the same action for different channels can usually be one.
- Drop the rare ones. If an action happens a few times a month, let the agent draft a request and have a person do it.
- Check the count against the role. If the list is long and covers unrelated actions, split the agent.
- Review after certification. Tools the agent never uses, or uses badly, are candidates for removal.
What does this look like in practice?
Take a support agent at a utility. The first version had over thirty tools, one for nearly every endpoint the billing system exposed. It frequently chose a meter-reading update when asked about a bill, because both tools mentioned "readings".
The team rebuilt the set around the role: look up account, look up bill, explain a charge, submit a customer meter reading, draft a payment arrangement, book a callback, and a draft-only tool for anything else. Seven tools. Selection errors dropped, and each tool now had a clear depth. Submitting a reading is depth 3 within a plausibility range; payment arrangements are drafts for a person. Billing adjustments moved to a separate agent with its own role.
What should happen when a tool is refused?
A refused tool call is not a failure to fix by adding another tool. If the agent keeps reaching for an action outside its bounds, the answer is to make refusal clear and route the case, not to widen the toolset. The argument is set out in refusal is a gate, not a nice-to-have.
Where do tools connect?
Each tool reaches its system through a controlled path, often an API gateway; see how to put an API gateway in front of an AI agent's tools. The basic mechanics are in how an AI agent uses tools, and the governing layer is described in the governed agentic operating system guide.
Questions people ask
Is there a maximum number of tools a model can handle?
Models can technically be given many tools, and the limit grows as context windows grow. The practical limit is lower: the point at which selection errors and governance effort outweigh the benefit of one more tool.
Should every agent get read-only lookup tools?
Most need some, scoped to the data the role requires. A lookup tool that reaches every system gives the agent more data than it needs and more to leak.
Can tools be loaded only when needed?
Yes. Some setups show the agent a smaller set for each task type. That helps selection, but each tool still needs its depth and bounds whether or not it is loaded.