Agent Failure Modes

I combine two complementary detection signals to catch loops without false positives. The first signal is exact action repetition: compute a signature of (action_name, sorted(args.items())) for each step and track consecutive repetitions within a sliding window. If the same signature appears 3+ times, that indicates an action-level loop — the agent keeps calling the same tool with the same arguments. This is common when a tool returns insufficient information and the agent tries the exact same call expecting a different result. The second signal is semantic thought similarity: split consecutive thought texts into word sets and compute Jaccard similarity (intersection over union). If similarity exceeds a threshold (typically 0.7-0.8) for 3+ consecutive steps, the agent is in a reasoning rut — thinking the same thing without progress. I combine these with OR logic because they catch different failure modes. Recovery follows a two-stage escalation: first, inject a gentle observation like "You have called the same tool 3 times. Consider a different approach or produce a Final Answer." If the pattern continues for 3 more steps, escalate to a forced Final Answer with whatever partial result exists. This prevents infinite token burn while preserving any work done before the loop started.

This is stuck-reasoning where the agent lacks a stopping criterion. It found the answer in step 1 but continues seeking confirmations. The root cause is the system prompt did not specify when to stop gathering and produce a Final Answer. Three mitigations ordered by invasiveness: first, a prompt-level fix — "Once you have found information directly answering the question, produce a Final Answer. Do not search for additional confirmations." This costs nothing. Second, a programmatic guard — after 3 tool calls on the same topic, override the LLM and inject "You have sufficient information. Produce a Final Answer." Third, semantic deduplication — use an embedding model to compute similarity between consecutive queries. If similarity exceeds 0.85 for 3 steps, force termination. Start with the prompt fix and escalate if the problem persists.

The failure-aware loop has detection, classification, response selection, and adaptation layers. Tool hallucination detection checks action name against the registry; if absent, inject observation listing all tools with brief descriptions. Context loss detection uses embedding similarity between the current query and all past observations — if a match exists above threshold, inject a reminder with the relevant past result. Stuck reasoning uses the sliding-window repetition detector from my earlier answer, escalating from warning to forced-synthesise. Instruction ignoring is detected by structural validation against expected output format — on failure, re-prompt with few-shot example. The adaptation layer maintains a counter per failure category per session. If the same failure occurs twice, the response escalates one level — from gentle re-prompt to firmer instruction to forced override. The failure log is included in the final session summary for offline analysis. This ensures the loop is not endlessly forgiving of the same mistake.