The short answer
An AI agent tool is a clearly described capability — its name, purpose, and the inputs it needs — that the agent can call while executing a task. It might be an API request, a knowledge base search, a database lookup, or a write into an external system like a CRM. The agent does not inherently "know" the tool; it reads the description and decides when to use it based on the task at hand.
What a tool actually is
Technically, a tool is a schema that defines a function name, a text description of what it does, and a list of required parameters with their types. When the agent decides to call a tool, it fills in those parameters based on its understanding of the task, and the actual request is sent to the code or service that executes it. The quality of the description drives the quality of tool use: a vague description of an "update record" tool leads the agent to misjudge when and how to call it.
- External API example: checking a shipment's status through a carrier's interface.
- CRM example: reading a lead's data or updating its stage in the sales pipeline.
- Database example: checking stock availability before confirming an order.
- Search example: searching an internal knowledge base or the web for current information.
Read vs write tools
Read tools fetch information without changing anything: search, retrieval, status lookup. Their risk is relatively low because the worst outcome is inaccurate information that can be corrected. Write tools have a real-world effect: sending an email, updating a record, issuing a refund, deleting data. This distinction should shape design — not just at the tool level, but at the level of what permissions the agent holds in a given context.
Selecting and chaining tools
In multi-step tasks, an agent does not call a single tool in isolation; it chains several: looking up a customer in the CRM, then checking an order's status in a database, then writing a reply or updating a ticket's state. This chaining is part of the agent's internal planning, and it works well when each tool is described precisely enough to stop the agent from confusing two tools with a similar purpose.
Illustrative workflow: a support agent receives a complaint about a delayed shipment. It first calls a read tool to verify the order number, then an external carrier-tracking tool, and if the delay is confirmed it calls a write tool to issue compensation within a pre-set cap — or hands the decision to a staff member if it exceeds that cap.
Permissions and scopes
Giving an agent full access to an entire system is a common mistake. It is better to define a scope per tool: which tables can be read, which fields can be edited, and which operations are off-limits entirely (such as permanent deletion). These are the same scopes typically managed through custom tools and integrations on an agent platform, and they should be tested against real scenarios, not only hypothetical ones, before launch.
Error handling and human approval
A tool call can fail: a timeout, invalid data, or an external service being down. A well-built agent distinguishes an error worth retrying automatically (a network timeout) from one that warrants stopping and asking for clarification or human intervention (conflicting data). Irreversible actions — cancelling a subscription, a financial transfer, deleting data — should always route through an explicit human approval step before execution, regardless of how confident you are in the agent's accuracy.
- Log every tool call: who, when, with what parameters, and what the result was — this is what makes later observability and auditing possible.
- Cap the number of automatic retries to avoid repeated failure loops.
- Separate test and production environments when granting write permissions.
Risk and control table
| Tool category | Example | Risk level | Recommended control |
|---|---|---|---|
| Search/retrieval | Searching the knowledge base | Low | Usually no extra constraints |
| API/CRM read | Fetching customer data | Low to medium | Read scope limited to needed fields |
| CRM write | Updating a deal stage | Medium | Audit log plus limits on editable fields |
| Financial write | Issuing a refund | High | Amount cap plus mandatory human approval |
| Data deletion | Deleting a record or account | Very high | Always human approval; disable the tool by default when possible |
When not to grant a tool
Do not give an agent a tool simply because it is available. If a task is rare and high-risk, it may be better for a human to execute it directly after the agent prepares the necessary information. Similarly, tools that require fine ethical or legal judgment (terminating an employee, a final credit decision) should remain human decisions, no matter how well the agent can prepare a recommendation.