Why More Tools Make AI Agents Less Reliable, Not More Capable

Capability Is Not the Same as Choice

The prevailing instinct in agent design is additive: if an AI agent fails, give it another tool. Add a second search provider, another database connector, three ways to send a message and a generic code executor for everything else. The agent appears more capable because its action space has expanded. In practice, each addition creates another decision the model must get right before it can complete the real task. Tool count becomes a hidden source of error, latency and cost.

Consider an agent with one approved function for retrieving customer records. Once it has correctly identified the user’s intent, tool selection is nearly trivial. Give the same agent six functions that can all return customer information—search_customer, get_contact, find_account, query_crm, lookup_user and run_sql—and the problem changes. The model must infer distinctions that may be obvious to the engineers who named them but absent from the prompt. A 95 per cent chance of choosing correctly at each of four decision points produces an end-to-end success rate of roughly 81 per cent. Reliability compounds downwards.

The mistake is to measure capability by the number of actions exposed rather than the number of tasks completed correctly. A smaller, well-bounded toolset can solve fewer theoretical problems while delivering far more dependable outcomes on the problems that matter. Production agents should be judged by successful task completion, safe failure and recovery—not by the length of their function catalogue.

Overlapping Tools Create Routing Ambiguity

Overlap is especially damaging because language models route tools through semantic similarity. If two descriptions contain the same verbs, entities and outcomes, the model has little evidence for choosing between them. A function described as “searches orders by customer details” competes directly with one that “finds customer orders using account information”. Engineers may know that the first queries a warehouse and the second calls the live commerce platform. Unless that distinction is explicit and relevant to the request, the agent is effectively guessing.

The consequences are not merely cosmetic. A warehouse may lag production by four hours, while the live API reflects cancellations immediately. An agent handling “Where is my order?” could confidently report that a cancelled item is still being prepared. In a financial workflow, choosing a reporting database instead of the ledger may expose stale balances. In an operations workflow, selecting a read-only preview function instead of the execution endpoint can produce a reassuring message without changing anything.

The usual response is to write longer descriptions, but verbosity cannot rescue a fundamentally duplicated interface. The stronger remedy is consolidation. One order lookup tool can accept a freshness requirement or internally select the correct source. Where separate tools are necessary, their names and descriptions should state the decision boundary: use live_order_status for fulfilment and cancellation questions; use historical_order_report for analysis ending before yesterday. Good routing depends on contrast, not prose volume.

Vague Descriptions Turn Schemas Into Guesswork

A tool description is part instruction manual, part contract and part safety control. “Gets data from the CRM” is not a useful contract. It does not say which records are available, whether the operation is read-only, what identifiers are accepted, how fresh the data is or what happens when multiple matches exist. The model must fill those gaps from statistical intuition, which is precisely where plausible but incorrect behaviour enters the system.

Parameter design has the same problem. A field called id may mean a contact UUID, email address, account number or external billing reference. Optional parameters multiply uncertainty further. If a scheduling tool accepts timezone, locale, start, end, duration, calendar_id and attendee_policy without clear defaults, the agent can construct a syntactically valid call that books the wrong hour or invites the wrong people. Schema validation catches malformed JSON; it does not catch a perfectly formatted mistake.

Descriptions should specify purpose, preconditions, exclusions, side effects and output shape. Parameter names should carry domain meaning: customer_account_id is better than id, and start_time_iso8601_with_offset is better than time. Enumerations should replace free text where possible. A refund reason with five permitted values is easier to validate than an open string. These constraints reduce flexibility, but they also reduce interpretation—and interpretation is where reliability is lost.

Every Additional Tool Expands the Failure Surface

Tool proliferation creates operational risk beyond model selection. Each integration has credentials, rate limits, version changes, timeout behaviour, error formats and data-retention implications. Twenty tools are not simply twice as difficult to operate as ten; they create more interactions, more fallback paths and more states to test. If an agent can read a document, write to a ticket, message a customer and execute code, a single task may cross four security boundaries before it is complete.

Latency also accumulates. Suppose an agent spends 700 milliseconds deciding on an action, each external call takes 800 milliseconds and one in ten calls requires a retry. A workflow using two calls may still feel responsive. A loosely designed workflow that chains eight calls can easily exceed ten seconds once reasoning passes, network variance and retries are included. Longer workflows also consume more tokens because each result re-enters the context, increasing both cost and the chance that relevant instructions are displaced.

Permissions become harder to reason about as the catalogue grows. A generic HTTP client or code-execution tool can silently bypass the safeguards built into narrower functions. There is little value in restricting refund_order to £500 if the same agent can call an unrestricted payments endpoint through execute_request. Broad tools may be useful in supervised engineering environments, but they are dangerous defaults for autonomous customer, finance or administrative workflows.

Tool Choice Consumes a Limited Decision Budget

Agents do not reason over unlimited context with uniform attention. Every tool name, description, schema and example competes with the user request, system rules, conversation history and retrieved data. A catalogue of 60 tools can occupy thousands of tokens before the task begins. Even when the model supports a large context window, capacity is not the same as focus. More material creates more opportunities for partial matches and missed constraints.

Choice architecture matters. Humans take longer and make poorer decisions when options are numerous and weakly differentiated; agents exhibit an analogous pattern. A customer-support agent asked to update an address should not evaluate tools for analytics exports, marketing campaigns and warehouse reconciliation. Those options are irrelevant, yet their presence can still distort selection, especially when descriptions share terms such as customer, account or update.

The practical answer is dynamic exposure. Route the request first to a domain such as billing, fulfilment or account management, then present only the relevant tools. An account-management agent might see four functions rather than the organisation’s full catalogue of 80. This introduces an initial routing step, and that router can fail, but the tradeoff is favourable when domains are clear: one coarse decision followed by a small, distinct action set is easier to evaluate than a single decision across dozens of near-neighbours.

Disciplined Design Starts With Fewer, Stronger Interfaces

Reliable tool design begins with task analysis, not integration inventory. List the high-value user outcomes, trace the minimum actions required and expose only those actions. If support staff need to identify an account, inspect recent orders and issue approved refunds, the agent may need three purpose-built tools—not direct access to the CRM, warehouse, payment gateway, data lake and internal API platform. The underlying systems can remain complex while the agent-facing interface stays simple.

Tools should be designed around business operations rather than vendor endpoints. A raw payments API may require separate calls to fetch a charge, calculate eligibility, create a refund and record a note. A refund_customer_payment tool can perform those steps transactionally, enforce the £500 limit, reject charges older than 30 days and return a clear result. The compound tool sacrifices some generality, but it removes opportunities for skipped checks and partial completion.

Defaults should be safe, side effects explicit and irreversible actions separated from exploratory ones. Preview and commit are valuable patterns when the distinction is unmistakable: prepare_refund returns amount, destination and policy checks; execute_refund requires the approved preview token. Idempotency keys prevent duplicate actions after retries. Structured error codes such as CUSTOMER_NOT_FOUND or POLICY_LIMIT_EXCEEDED let the agent recover predictably instead of interpreting an opaque paragraph from a vendor API.

Reliability Must Be Measured at the Tool Boundary

Teams often evaluate agents on the quality of their final text while overlooking whether the correct tools were selected and used. A fluent answer can conceal a stale lookup, a failed write or an invented confirmation. Evaluation should separate routing accuracy, argument accuracy, execution success, policy compliance and final-response fidelity. If 98 per cent of calls execute but only 88 per cent target the right system, improving uptime will not solve the dominant problem.

A useful test set includes common requests, ambiguous phrasing, missing identifiers, conflicting instructions, duplicate submissions and adversarial attempts to trigger privileged functions. Measure not only successful completion but unnecessary calls, retries and unsafe actions. For a mature production workflow, a team might target more than 97 per cent correct tool selection, fewer than 1.2 calls per simple lookup and zero unauthorised writes across thousands of red-team cases. The exact thresholds vary, but explicit numbers force design choices into the open.

Tool catalogues should also be reviewed like product portfolios. Track usage, confusion pairs and failure contribution. If two tools are repeatedly mistaken for one another, rename, merge or gate them. If a function is invoked in fewer than 0.1 per cent of tasks but appears in every prompt, expose it only on demand. Reliability improves when the catalogue is pruned continuously rather than treated as permanent infrastructure.

The Most Capable Agent Knows Its Boundaries

A dependable agent is not one that attempts everything. It recognises when information is missing, when authority is insufficient and when a human should take over. Tool design should make those boundaries concrete. High-risk actions can require confirmation, dual approval or escalation. Low-confidence identity matches should return a request for clarification rather than the “closest” customer. A tool that refuses safely is more valuable than one that produces a result at any cost.

There is a genuine tradeoff. Narrow tools demand more upfront engineering, and aggressive pruning can leave unusual requests unsupported. Consolidated business functions may also reduce portability across vendors. Yet those costs buy observability, enforceable policy and repeatable behaviour. The right strategy is not permanent minimalism but controlled expansion: add a tool only when a validated task cannot be served by the existing interface, define a distinct decision boundary and prove through evaluation that the addition improves end-to-end performance.

The central discipline is subtraction. Remove duplicate routes, hide irrelevant capabilities, constrain arguments and move deterministic business logic out of the model. AI agents become useful in production when their choices are legible and limited. More tools enlarge the map; better tools create a road the agent can follow reliably.