Hand a language model read access to your ticketing system and write access to your refund API, and the conversation changes. It stops composing a polite paragraph about the problem and starts closing the ticket, issuing the refund, and logging the reason. That leap, from text to action, is what people mean by AI agent tools: the functions, endpoints, browsers, and file systems an agent can call to affect something outside its own context window.
The models get the headlines. The tools decide whether the thing actually works.
The tool layer is where talking turns into doing
Every tool an agent can use is described to the model in a structured schema: a name, a plain-English description of what it does, and a list of typed parameters. The model never executes anything itself. It emits a request to call refund_order with an order ID and an amount, your code runs the real API call, and the result gets fed back in as context.
That sounds like a plumbing detail until you watch it go wrong. Vague parameter names produce malformed arguments. A missing list of allowed values makes the model invent a status like “partially_refunded_pending” that your billing system has never heard of. Descriptions that don’t say when not to use a tool cause the agent to fire it at exactly the wrong moment.
Tool descriptions are product decisions
Compare two descriptions for the same endpoint. One reads “Refund an order.” The other reads “Use only when a customer disputes a charge under $50, the order is younger than 90 days, and no refund already exists. Never use for subscription billing.” The second one is a prompt, just written in JSON, and it will outperform the first every single time. Most agent failures blamed on the model are really documentation failures in the tool catalogue.
The tool categories that show up in nearly every stack
Strip away the vendor branding and most agent deployments are built from the same handful of parts:
- Retrieval and search. Vector stores, internal wikis, documentation indexes. The agent needs to find the right page before it can cite it.
- Code execution. A sandboxed Python runtime for arithmetic, data wrangling, and file conversion. It eliminates an entire class of confidently hallucinated maths.
- Browser automation. Headless Chrome with click, type, and screenshot actions. Usually the last resort for sites with no usable API.
- Business system APIs. CRM records, billing, ticketing, inventory, shipping. This is where the money and the risk both live.
- Communication channels. Email, Slack, SMS, voice. Any agent with a send tool needs guardrails before it gets a sender identity.
Everything else on the market is a variation on those five.
Integration work is the silent budget killer
Connecting one agent to one API takes an afternoon. Connecting it to twelve, each with its own auth flow, pagination quirks, and rate limits, takes a quarter. Auth is the usual culprit: OAuth tokens that expire mid-run, per-tenant credentials, scopes that behave differently in sandbox than in production.
This is the specific headache Composio’s approach to giving AI agents real tools is aimed at, abstracting authentication and normalising dozens of integrations behind a single interface so you aren’t rebuilding a Salesforce connector from scratch for every project. Buy that layer or build it, but budget for it. It’s rarely the part anyone puts in the demo.
What happens when tools misbehave
Tools fail in ways models handle badly. A 429 rate limit looks like a temporary hiccup to your retry logic and like an open invitation to an agent that just keeps trying. Earlier this year, OpenAI’s agents hammered Wikipedia’s tools and flooded the site with traffic, a textbook case of well-intentioned automation overwhelming an endpoint it never understood.
Three failure modes worth designing around
Loops. The agent searches, gets nothing useful, searches again with a near-identical query, and burns several dollars in tokens before a timeout stops it. Cap iterations at five or six and make the cap a hard stop rather than a guideline in a system prompt.
Over-permissioned credentials. The tool was scoped for read-only access during testing and shipped with an admin key because swapping it was a Friday afternoon problem nobody owned. Give every tool the narrowest scope that still lets it pass its tests.
Silent partial success. An API returns 200 with an empty array. The agent reports that the job is done. Nothing happened. Validate the response shape, not just the status code, and treat an empty result as a failure worth surfacing.
Open source tools versus managed tools
Open source agent frameworks ship with generous tool libraries you can wire up in an afternoon, and the licence cost is genuinely zero. The operational cost isn’t. You inherit upgrade churn, security patches, and the debugging burden when a community connector breaks against a vendor’s API change on a Tuesday. What open source AI agents actually cost to run is worth reading before you commit a team to one.
Managed platforms flip the trade. Less wiring, more predictable behaviour, an invoice every month, and a hard ceiling on how far you can bend the tool layer when your workflow doesn’t match their template.
The line item nobody budgets for: tool definitions are tokens
Every tool you register gets sent to the model on every single turn. Thirty tools with 200-token descriptions is 6,000 tokens of context consumed before the user has typed a single character. At volume that’s real money, and it also crowds out the actual conversation.
Two fixes work. Prune aggressively and load tools dynamically based on the task rather than sending the whole catalogue every time. Then read the pricing page properly, because per-tool and per-seat charges stack on top of token costs. If you’re building a budget, the breakdown of AI agent software costs and where the numbers break has concrete figures rather than hand-waving.
Test the tool catalogue before you trust it
Demos run on the happy path. A tool stack earns its keep on the other one. Four checks catch most of the damage early:
- Run each tool in isolation, with hand-written arguments, before letting the model choose it. If you can’t call it manually, the model won’t reliably call it either.
- Break it on purpose. Expire the token, return a 500, send back an empty list. Watch what the agent does next, not what it says it did.
- Log every tool call with its arguments and latency for the first two weeks. The expensive one announces itself fast.
- Count the tokens your tool definitions consume per turn and multiply by realistic daily runs. That’s your true floor cost.
A support agent with eight well-documented tools beats one with forty vague ones, and it costs less to run.
Pick tools that survive your systems, not your demo
Your real environment is messier than any sandbox: legacy fields with inconsistent casing, a CRM with duplicate accounts, an internal API nobody has documented since 2019. The platforms that hold up are the ones that degrade gracefully when they hit that mess, returning something usable rather than a stack trace. Choosing agent platforms that survive your actual systems is a better filter than any feature comparison table.
The tool that earns its place next quarter will probably be the boring one nobody demoed: a plain read-only endpoint that returns the same shape every time and fails loudly when it can’t. Agents don’t need clever tools. They need predictable ones with narrow permissions, honest error messages, and a description that tells the model exactly when to leave them alone.