Agent Memory Errors Handbook: Cases 61–65

This installment is part of the Agent Memory Errors: 100 Cases Handbook series.

Case 61: Tool Use Memory Errors — Tool Result Caching Stale Data Usage

Scenario

The Agent calls a weather API and caches the result for 30 minutes. During the cache window the user asks, “Based on the current weather, should I bring an umbrella?” The Agent uses the cached “sunny” result, but the weather actually turned to heavy rain 30 minutes ago.

Error Manifestation

The Agent advises, “No need for an umbrella,” and the user gets soaked. The user complains, “Didn’t you say it was sunny?”

Solution

1. Use semantic TTL: weather forecasts 15 minutes, stock prices 5 minutes, user info 1 hour
2. Label data freshness in answers, e.g., “Based on weather data from 30 minutes ago…”
3. For time-sensitive tools, prefer real-time calls on user query and update cache asynchronously

Principle

Caching trades freshness for performance. In time-sensitive scenarios such as weather, stock prices, and inventory, stale caches cause decision errors. Semantic TTL adapts cache policy to data type.

Case 62: Tool Use Memory Errors — Tool Parameter Memory Type Confusion

Scenario

The Agent previously called an API with user_id as integer 12345. The API later upgraded and requires user_id as string "12345". The Agent’s memory stores historical call templates and reuses them without checking current type requirements.

Error Manifestation

The API returns 400: “user_id must be a string.” The Agent cannot complete the task and repeatedly retries, triggering API rate limiting.

Solution

1. Store parameter schemas (JSON Schema) rather than concrete values, and validate against the current API schema at call time
2. Invalidate parameter memories when tool definitions change
3. Use defensive calling: pre-validate parameters and auto-convert or report mismatches

Principle

API parameter types and constraints evolve. Reusing historical call values as templates ignores API evolution. Schema-based calls are more robust than instance-based calls.

Case 63: Tool Use Memory Errors — Tool Chain Intermediate Result Loss

Scenario

The Agent runs a three-step tool chain: T1 query user ID → T2 query orders → T3 cancel order. The T1 result (user_id) is stored in short-term memory, but before T2 is called, context compression truncates and loses user_id, so T2 lacks the required parameter.

Error Manifestation

T2 returns “missing user_id.” The tool chain breaks, the task is unfinished, and the Agent loops by restarting from T1.

Solution

1. Lock pipeline parameters: key passed parameters cannot be evicted by context compression until the chain completes
2. Manage tool chains with an external state machine: intermediate results live in external storage (e.g., Redis), not LLM context
3. Implement breakpoint resumption: on failure, check missing parameters and re-obtain them instead of restarting

Principle

Tool chains depend on passing intermediate results. The unreliability of LLM context makes context-based pipelines fragile. External state machines provide more reliable persistence.

Case 64: Tool Use Memory Errors — Tool Selection Bias Recent Usage

Scenario

The Agent has five search tools: Google, Bing, DuckDuckGo, internal Wiki, and an academic database. Because the most recent successful call in memory is Google, the Agent keeps choosing Google even for academic queries such as “mathematical principles of the Transformer attention mechanism.”

Error Manifestation

The Agent searches academic content on Google, gets low-quality blog posts instead of papers, and produces inaccurate, shallow answers.

Solution

1. Base tool selection on query-tool match rather than usage frequency: define capability descriptions and compute similarity between query and tool descriptions
2. Force tool exploration: periodically require the Agent to try less-used tools to avoid fixation
3. Evaluate tool selection after the fact and use selection-result quality to optimize future choices

Principle

Tool-selection bias resembles human habit. If the Agent always picks the handiest tool instead of the most suitable one, its effective capability boundary shrinks.

Case 65: Tool Use Memory Errors — Api Rate Limit Memory Exhaustion

Scenario

The Agent receives HTTP 429 rate limiting from an external API and should retry after one minute. But its rate-limit memory does not update correctly, so retries happen every ten seconds. The Agent keeps hitting the limit and the API provider temporarily blocks the IP.

Error Manifestation

All API calls fail and any task depending on that API cannot complete. Users see “Service temporarily unavailable” errors.

Solution

1. Parse the Retry-After header and store the exact retry time
2. Use exponential backoff with jitter after rate limiting
3. Apply a circuit breaker: pause calls after repeated failures and return degraded responses

Principle

API rate limiting protects services. Clients that ignore rate-limit signals are treated as attackers and blocked harder. Correct rate-limit memory and backoff are basic requirements for reliable integration.

Source: Agent Search