Why do production agents need a tool use taxonomy?
Without a structured taxonomy, teams reinvent tool integration patterns ad-hoc for each agent, leading to inconsistent error handling, permission models, and retry logic that become the primary source of production failures in agent systems.
I analyzed tool call logs from 12 production agent systems over 4 months. The systems spanned document processing, customer support, data analysis, and code generation domains. They made a combined 890,000 tool calls per day. The most common source of agent failure was not model reasoning errors. It was tool interaction failures: malformed parameters (12% of failures), permission denials (18%), timeout and retry storms (23%), and mishandled error responses (31%). These are integration engineering problems, and they have patterns.
What are the 6 tool use patterns?
The 6 patterns, ordered by complexity, are: direct invocation, parameterized delegation, chained pipelines, fallback cascades, parallel fan-out, and conversational negotiation.
- Pattern 1: Direct Invocation: The agent calls a single tool with predetermined parameters. Example: “get the current weather for coordinates 40.7128, -74.0060.” This is the simplest pattern. Error handling is straightforward: retry on transient failure, report on permanent failure. Permission scoping is static. This pattern accounts for 45% of tool calls in the systems I analyzed.
- Pattern 2: Parameterized Delegation: The agent constructs tool parameters dynamically based on user input and context. Example: the agent parses a user’s question, extracts search terms, and constructs a database query. This pattern introduces parameter validation risk. I enforce JSON schema validation on all dynamically constructed parameters before tool execution, which catches 89% of malformed parameter errors.
- Pattern 3: Chained Pipelines: The output of one tool call becomes the input to the next. Example: search for documents, extract relevant sections, then summarize the sections. This pattern requires intermediate result validation. If the search returns no results, the extraction step should not execute. I implement chain-of-responsibility with explicit precondition checks at each stage.
The critical design decision in chained pipelines is error propagation. When step 2 of 5 fails, should the chain abort, retry step 2, or skip to step 3 with a default value? The answer depends on the domain. In a financial analysis pipeline, I abort on any step failure because partial results are worse than no results. In a research assistant, I skip with a default and note the gap, because partial information is better than no information. This decision must be explicit in the architecture, not left to the model’s judgment.
- Pattern 4: Fallback Cascades: The agent tries a preferred tool first and falls back to alternatives on failure. Example: query the primary database, fall back to the read replica, fall back to a cached snapshot. This pattern mirrors the circuit breaker pattern in microservice architecture. I implement cascades with a preference ordering, per-tool failure counters, and automatic circuit breaking (if a tool fails 3 times in 5 minutes, skip it for the next 10 minutes and go directly to the fallback).
A subtle risk in fallback cascades is quality degradation masking. If the primary tool produces high-quality results and the fallback produces lower-quality results, the system may silently degrade without detection. I tag every agent response with the tool chain that produced it, enabling quality monitoring to detect when fallbacks are being triggered at abnormal rates.
- Pattern 5: Parallel Fan-Out: The agent calls multiple tools simultaneously and aggregates results. Example: search 3 different knowledge bases in parallel and merge results. This pattern introduces aggregation complexity. Results from different tools may conflict, overlap, or use different formats. I implement a dedicated aggregation step (often using the model itself) with explicit conflict resolution rules.
Timeout management in parallel fan-out is critical. If 2 of 3 parallel tool calls complete in 200ms but the third takes 4 seconds, should the agent wait or proceed with partial results? I use a configurable timeout with a “sufficient results” threshold: if 2 of 3 tools return acceptable results within the timeout window, proceed. The late-arriving result can be incorporated asynchronously if it arrives before the response is finalized.
- Pattern 6: Conversational Negotiation: The agent engages in a multi-turn interaction with a tool that has its own state and logic. Example: interacting with a legacy API that requires a multi-step authentication flow, or navigating a menu-driven system. This is the most complex pattern and the most error-prone. I avoid it when possible by wrapping complex tool interactions in a simplified adapter that the agent sees as a simpler pattern (typically direct invocation or parameterized delegation).
How should error handling differ across patterns?
Error handling should escalate in sophistication with pattern complexity: direct invocation needs simple retry logic, while chained pipelines need transaction-like rollback or compensation mechanisms.
- Step 1: Classify every tool call by pattern type at design time.
- Step 2: For Patterns 1-2, implement retry with exponential backoff (max 3 retries, base delay 500ms). On permanent failure, return a structured error to the agent with enough context to reason about alternatives.
- Step 3: For Pattern 3 (chains), implement precondition checks between steps and explicit abort/skip/retry policies per step. Log the chain state at each transition for debugging.
- Step 4: For Pattern 4 (cascades), implement circuit breakers with health checks. Monitor fallback trigger rates and alert when they exceed baseline by 2x.
- Step 5: For Pattern 5 (fan-out), implement timeout-based partial result acceptance and conflict resolution. Tag responses with their source tool chain.
- Step 6: For Pattern 6 (negotiation), wrap in an adapter that absorbs multi-turn complexity and presents a simpler interface to the agent. If the adapter cannot simplify the interaction, this tool may not be suitable for agent use.
The architectural parallel to microservice integration is not coincidental. Agent tool use is distributed systems engineering applied to AI workflows. The same patterns that make microservices reliable (circuit breakers, retries, timeouts, idempotency, observability) make agent tool use reliable. The teams that recognize this and apply established distributed systems wisdom to their agent architectures are the ones building systems that survive contact with production traffic.