Tool Thrashing

Intermediate🚫 Anti-Pattern⚙️ Anti-Patterns: Tool UseIndustry observation / Academic

🚫Anti-Pattern— This describes a common mistake to avoid, not a pattern to follow.

The Anti-Pattern

Agent calls tools excessively, redundantly, or incorrectly — searching for the same thing multiple times, calling tools in the wrong order, or making unnecessary API calls.

Why It Happens

Poor tool descriptions, too many tools exposed at once, or lack of working memory cause the agent to ‘forget’ what it already found and re-query. Or it calls every available tool hoping something works. Each unnecessary tool call adds latency, cost, and noise to the context. The problem compounds: redundant tool outputs fill the context, causing more confusion, causing more redundant calls.

How to Fix It

Write precise, unambiguous tool descriptions that clearly state what each tool does and when to use it. Use progressive tool discovery to limit visible tools to what’s relevant for the current step. Implement working memory so the agent tracks what it has already found and doesn’t re-query. Monitor tool call patterns to detect thrashing. The rule of thumb: if an agent calls the same tool with the same arguments twice in a session, something is architecturally wrong.

Diagram

  Tool Thrashing:                    Efficient Tool Use:
  ┌───────┐                          ┌───────┐
  │ Agent │──▶ search('refund')      │ Agent │──▶ search('refund')
  │       │──▶ search('refund')  ✗   │       │        │
  │       │──▶ search('policy')      │       │◀── result (cached in
  │       │──▶ search('refund')  ✗   │       │    working memory)
  │       │──▶ lookup('returns')     │       │──▶ lookup('returns')
  │       │──▶ search('refund')  ✗   │       │        │
  └───────┘                          └───────┘◀── done
  6 calls, 3 redundant               2 calls, 0 redundant

Symptoms

Same search query appears multiple times in a single conversation’s tool calls
Tools called with identical parameters returning identical results
Agents calling tools that aren’t relevant to the current task
Tool calls appearing in illogical order (e.g., update before read)

False Positives

Legitimate retries after transient API errors with appropriate backoff
Iterative search refinement where each query is intentionally different
Exploratory tool use during a discovery phase with genuinely new queries

Warning Signs & Consequences

Warning Signs

Tool call logs showing repeated identical queries
High ratio of tool calls to useful results (5+ calls per useful piece of data)
API costs dominated by tool execution rather than LLM reasoning
Slow response times caused by unnecessary serial tool calls

Consequences

Inflated API costs from redundant external calls
Increased latency — users wait while the agent re-discovers what it already knows
Hitting rate limits on external APIs from excessive requests
Context pollution — redundant tool outputs fill the window with noise

Remediation Steps

1Audit all tool descriptions for clarity and specificity
2Reduce the number of tools exposed at once — use progressive discovery
3Implement working memory that caches tool results within a session
4Add tool call deduplication — detect and skip identical calls
5Monitor tool call patterns and alert on thrashing signatures

Real-World Example

Knowledge Base Triple Query

A customer support agent searches the knowledge base for ‘refund policy’ three separate times in the same conversation. Each time it gets the same result, but without working memory, it doesn’t know it already has the answer. The tripled API calls triple the response latency (1.5s → 4.5s) and the three identical results pollute the context window.