Agent Failure Modes | TechByteByByte

Begin with the problem

An agent may loop forever, choose the wrong tool, lose state, repeat an action, or stop too early. Failure handling begins by naming the failing stage.

failed outcome → inspect trace → locate first bad stage → retry, fallback, escalate, or stop

What you will learn

Classify failures by stage: model, plan, tool, state, memory, loop, safety, or infrastructure.
Distinguish a wrong tool choice from correct-tool execution failure.
Use traces and reproducible cases to locate the first bad decision.
Design retries, fallbacks, escalation, and stopping behavior for each failure type.

Current real-system grounding: OpenAI’s evaluation guidance supports dataset-based testing, and Google’s tools guide makes the application/tool execution boundary explicit.

These official links document available product features. They do not reveal every provider’s private implementation, hidden reasoning, default setting, or internal limit.

1. The problem this module solves

Module 18 covered security-specific risks. This module closes Level 7 with the complete failure landscape — every real way an agent’s operation can go wrong, security-related or not, giving you a systematic diagnostic vocabulary directly connecting to Module 21’s observability discussion.

2. The Complete Failure Landscape

Failure Mode	What It Is	Connects To
Hallucination	The LLM generates plausible-sounding but ungrounded claims	Module 5, Section 6
Wrong tool selection	The agent picks a inappropriate tool for the situation	Module 6, Section 7
Wrong parameters	The agent picks the right tool but generates incorrect arguments	Module 7, Section 6
Tool failure / API timeout	The underlying system the tool calls fails	Module 6, Section 6
Invalid output	The agent’s output doesn’t match the expected format or schema	—
Infinite loops / repeated actions	The agent gets stuck, repeating an unproductive action	Module 4, Section 8
Bad planning	A flawed initial decomposition	Module 8
Wrong retrieval	irrelevant or incorrect information retrieved	Module 14
Stale memory	Outdated information persisting in long-term memory	Module 11
Conflicting information	contradictory data from different sources	Your RAG course
Cost / latency explosion	excessive resource consumption	—

3. For Each Failure — The Diagnostic Pattern

Problem
   ↓
WHY it happens
   ↓
A concrete EXAMPLE
   ↓
IMPACT
   ↓
MITIGATION

This is the same structure as your RAG course’s Module 24 failure-mode diagnostics — worth applying with the same discipline here.

4. Three Detailed Examples

Hallucination

Stage	Detail
Problem	The agent confidently states something not actually supported by its context
Why	The LLM’s generation is fundamentally a probabilistic process (your Generative AI course) — plausible completions can be produced without real grounding
Example	An agent claims a refund was processed when the tool call actually failed silently
Impact	misleading the user or downstream system
Mitigation	Groundedness verification (directly your RAG course’s Module 23) before presenting a claim as fact

Wrong Tool Selection

Stage	Detail
Problem	The agent calls a inappropriate tool for the situation
Why	Ambiguous or overlapping tool descriptions (Module 6, Section 4) confuse selection
Example	Calling `check_shipping_carrier` when the customer’s actual question was about a refund, not shipping
Impact	Wasted steps, incorrect final answer
Mitigation	Clearer, more distinct tool descriptions; fewer overlapping tools

Cost Explosion

Stage	Detail
Problem	A single agent task consumes excessive tokens or API calls
Why	Unbounded looping (Module 4), excessive reflection retries (Module 10), or an overly broad multi-agent system (Module 15) with too many unnecessary agent calls
Example	A reflection loop never satisfies its own requirements, retrying up to its max limit every single time
Impact	unpredictable, potentially large costs at scale
Mitigation	Max iterations/retries (Module 4, 10), cost monitoring and alerting (Module 20)

5. A Real Developer Example

TechCorp reviews a batch of failed agent tasks and classifies each:

Failed Task	real Failure Mode	Root Cause
Agent claimed a refund succeeded, but no refund was recorded	Hallucination	Tool call actually failed silently; agent didn’t verify
Agent called `check_shipping_carrier` for a billing question	Wrong tool selection	Overlapping, ambiguous tool descriptions
Agent retried the same failing API call 50 times	Infinite loop	No max-iterations limit configured
Agent’s answer referenced a policy that was updated last month	Stale memory	Long-term memory not refreshed since the policy change

6. A Simple Agentic AI Connection

Every failure mode in this module maps to a specific, prior module’s mitigation — this module’s real value is the systematic catalog, letting you quickly recognize which category a real failure belongs to and go directly to the relevant mitigation, rather than debugging from scratch each time.

7. How Is This Used in AI?

🤖 How Is This Used in AI?

Production agent teams maintain real, systematic failure taxonomies like this one — classifying real production failures into these categories directly informs where engineering effort should focus, exactly mirroring your RAG course’s Module 24 diagnostic discipline, now applied to the complete agent operation.

8. Real-World Applications

Systematic debugging and root-cause analysis for underperforming production agents
Designing observability (Module 20) to capture enough detail to distinguish these failure modes from logs alone
Prioritizing engineering investment toward the failure category causing the most real production issues

9. Common Mistakes

Incorrect idea: Treating every agent failure as “the model being bad.”

Why it is incorrect: As shown directly throughout Section 2, failures span many distinct categories, most fixable through specific, targeted mitigations rather than simply “using a better model.”

Incorrect idea: Not distinguishing wrong tool selection from wrong parameters.

Why it is incorrect: As shown directly in Section 4, these are different failures with different fixes — one is a description-quality problem, the other an argument-generation problem.

Incorrect idea: Ignoring cost and latency as real failure modes.

Why it is incorrect: As shown directly in Section 4’s third example, these are just as real and consequential as functional failures.

10. Limitations

This taxonomy covers common failure categories, but real systems may exhibit failures that span multiple categories simultaneously, requiring real judgment to fully diagnose
Recognizing WHICH category a specific failure belongs to often requires detailed observability (Module 20) — without enough logged detail, diagnosis becomes guesswork

11. Quick Reference

flowchart TD
    F[Agent Failure] --> Gen{Generation-related?}
    Gen -->|Yes| Hall[Hallucination]
    F --> Tool{Tool-related?}
    Tool -->|Wrong tool| WT[Wrong Selection]
    Tool -->|Wrong args| WP[Wrong Parameters]
    Tool -->|External failure| TF[Tool Failure]
    F --> Loop{Loop-related?}
    Loop -->|Stuck| IL[Infinite Loop]
    F --> Know{Knowledge-related?}
    Know -->|Outdated| SM[Stale Memory]
    Know -->|Contradictory| CI[Conflicting Info]
    F --> Res{Resource-related?}
    Res -->|Cost/Latency| CE[Cost/Latency Explosion]

12. Code — Implementing a Failure Diagnostic Catalog

🎯 Target of this example: implement Section 5’s real developer example directly — a systematic catalog correctly classifying real failure scenarios into their proper category, with each classification linked to a concrete mitigation, exactly Section 3’s diagnostic pattern made into working, queryable code.

Example 1 — Simple

from dataclasses import dataclass
from enum import Enum

class FailureMode(Enum):
    HALLUCINATION = "hallucination"
    WRONG_TOOL = "wrong_tool_selection"
    WRONG_PARAMETERS = "wrong_parameters"
    TOOL_FAILURE = "tool_failure"
    INFINITE_LOOP = "infinite_loop_repeated_actions"
    STALE_MEMORY = "stale_memory"
    COST_EXPLOSION = "cost_explosion"

@dataclass
class FailureDiagnosis:
    mode: FailureMode
    why_it_happens: str
    mitigation: str

FAILURE_CATALOG = {
    FailureMode.HALLUCINATION: FailureDiagnosis(
        FailureMode.HALLUCINATION,
        "The LLM generates a plausible-sounding but ungrounded claim not supported by actual context.",
        "Groundedness verification before acting on generated claims.",
    ),
    FailureMode.WRONG_TOOL: FailureDiagnosis(
        FailureMode.WRONG_TOOL,
        "Ambiguous or overlapping tool descriptions confuse the LLM's selection.",
        "Clearer, more distinct tool descriptions; fewer overlapping tools.",
    ),
    FailureMode.INFINITE_LOOP: FailureDiagnosis(
        FailureMode.INFINITE_LOOP,
        "The agent repeatedly takes the same unproductive action without recognizing it isn't helping.",
        "Max iterations, timeout, and repeated-action detection.",
    ),
}

def diagnose(mode: FailureMode) -> FailureDiagnosis:
    return FAILURE_CATALOG.get(mode, FailureDiagnosis(mode, "Not yet cataloged", "General debugging needed"))

for mode in [FailureMode.HALLUCINATION, FailureMode.WRONG_TOOL, FailureMode.INFINITE_LOOP]:
    diagnosis = diagnose(mode)
    print(f"[{diagnosis.mode.value}]")
    print(f"  Why: {diagnosis.why_it_happens}")
    print(f"  Mitigation: {diagnosis.mitigation}\n")

Expected Output:

[hallucination]
  Why: The LLM generates a plausible-sounding but ungrounded claim
not supported by actual context.
  Mitigation: Groundedness verification before acting on generated
claims.

[wrong_tool_selection]
  Why: Ambiguous or overlapping tool descriptions confuse the LLM's
selection.
  Mitigation: Clearer, more distinct tool descriptions; fewer
overlapping tools.

[infinite_loop_repeated_actions]
  Why: The agent repeatedly takes the same unproductive action
without recognizing it isn't helping.
  Mitigation: Max iterations, timeout, and repeated-action detection.

What we conclude from this example: each failure mode’s real cause and mitigation is directly retrievable from a structured catalog — exactly Section 3’s diagnostic pattern, made into queryable, reusable reference material rather than something re-derived from scratch for every new failure encountered.

Example 2 — Intermediate

def classify_failure(observed_behavior: str) -> str:
    """Directly implements Section 5's real developer example --
    classifying REAL, observed failure descriptions into their
    real category."""
    behavior_lower = observed_behavior.lower()

    if "claimed" in behavior_lower and ("no" in behavior_lower or "not" in behavior_lower):
        return "hallucination"
    if "retried" in behavior_lower and ("same" in behavior_lower or "50 times" in behavior_lower):
        return "infinite_loop_repeated_actions"
    if "called" in behavior_lower and "wrong" not in behavior_lower and "billing" in behavior_lower:
        return "wrong_tool_selection"
    if "outdated" in behavior_lower or "updated last month" in behavior_lower:
        return "stale_memory"
    return "uncategorized"

failures = [
    "Agent claimed a refund succeeded, but no refund was recorded",
    "Agent retried the same failing API call 50 times",
    "Agent called check_shipping_carrier for a billing question",
    "Agent's answer referenced a policy that was updated last month",
]

for failure in failures:
    category = classify_failure(failure)
    print(f"[{category}] {failure}")

Expected Output:

[hallucination] Agent claimed a refund succeeded, but no refund was
recorded
[infinite_loop_repeated_actions] Agent retried the same failing API
call 50 times
[wrong_tool_selection] Agent called check_shipping_carrier for a
billing question
[stale_memory] Agent's answer referenced a policy that was updated
last month

What we conclude from this example: all four of Section 5’s real developer scenarios are correctly classified into their real failure category — exactly the systematic classification a real team reviewing a batch of failed tasks would need to perform, made into working, repeatable logic.

Example 3 — Production Grade

from dataclasses import dataclass, field
from enum import Enum
from collections import Counter

class FailureMode(Enum):
    HALLUCINATION = "hallucination"
    WRONG_TOOL = "wrong_tool_selection"
    INFINITE_LOOP = "infinite_loop"
    STALE_MEMORY = "stale_memory"

@dataclass
class FailureRecord:
    task_id: str
    mode: FailureMode
    description: str

class FailureAnalyzer:
    """A production-style analyzer AGGREGATING failure records across
    many tasks -- directly supporting Section 7's real production
    practice: classifying failures to identify WHERE engineering
    effort should focus."""

    def __init__(self):
        self.records: list = []

    def record_failure(self, task_id: str, mode: FailureMode, description: str):
        self.records.append(FailureRecord(task_id, mode, description))

    def failure_frequency(self) -> dict:
        """Directly supports Section 7's prioritization use case --
        which failure category is most common, and
        therefore most worth fixing first?"""
        counts = Counter(r.mode.value for r in self.records)
        return dict(counts.most_common())

    def examples_for_mode(self, mode: FailureMode) -> list:
        return [r.description for r in self.records if r.mode == mode]

analyzer = FailureAnalyzer()
analyzer.record_failure("task_101", FailureMode.HALLUCINATION, "Claimed refund succeeded, none recorded")
analyzer.record_failure("task_102", FailureMode.WRONG_TOOL, "Called shipping tool for a billing question")
analyzer.record_failure("task_103", FailureMode.HALLUCINATION, "Claimed order was shipped, tool call had failed")
analyzer.record_failure("task_104", FailureMode.INFINITE_LOOP, "Retried failing API call until max iterations")
analyzer.record_failure("task_105", FailureMode.HALLUCINATION, "Fabricated a tracking number not in any tool result")

frequency = analyzer.failure_frequency()
print("Failure frequency (most common first):")
for mode, count in frequency.items():
    print(f"  {mode}: {count} occurrence(s)")

print(f"\nMost common failure mode: '{list(frequency.keys())[0]}' -- prioritize fixing this first.")

Expected Output:

Failure frequency (most common first):
  hallucination: 3 occurrence(s)
  wrong_tool_selection: 1 occurrence(s)
  infinite_loop: 1 occurrence(s)

Most common failure mode: 'hallucination' -- prioritize fixing this
first.

What we conclude from this example: aggregating failures across multiple tasks correctly reveals hallucination as the most frequent failure mode in this batch — exactly the kind of data-driven prioritization Section 7 describes, letting a real team focus their mitigation effort (groundedness verification, Module 23 of the RAG course) on the failure category actually causing the most real production problems, rather than guessing.

13. Interview Questions

Q: Why is it a mistake to treat every agent failure as simply “the model being bad”?

Ans: Agent failures span many distinct, specific categories — hallucination, wrong tool selection, wrong parameters, tool failures, infinite loops, stale memory, and more — each with a different root cause and a different, targeted mitigation. Treating every failure as a generic model-quality problem misses that many failures are actually fixable through specific fixes like clearer tool descriptions, better max-iteration limits, or memory refresh strategies, rather than requiring a fundamentally more capable model.

Q: Distinguish “wrong tool selection” from “wrong parameters” as failure modes, and explain why they need different fixes.

Ans: Wrong tool selection means the agent chose a inappropriate tool for the situation entirely — the fix is improving tool descriptions to reduce ambiguity between overlapping tools. Wrong parameters means the agent chose the correct tool but generated incorrect arguments for it — the fix is better argument validation or clearer parameter descriptions within that specific tool’s schema. These require different diagnostic approaches and different fixes, even though both are broadly “tool-related” failures.

Q: Why should cost and latency explosion be considered real failure modes, not just performance concerns?

Ans: Unbounded resource consumption — from unbounded looping, excessive reflection retries, or an overly broad multi-agent system making too many unnecessary calls — represents a real, consequential failure that can produce unpredictable, potentially large costs at scale, even if the agent’s eventual output is technically correct. This directly connects to the safety-limit mechanisms covered earlier in this course — treating cost and latency as failure modes worth tracking, not just implementation details, ensures they get the same monitoring attention as functional correctness failures.

Q: Design a systematic approach for analyzing a batch of failed agent tasks to determine where engineering effort should focus.

Ans: I’d classify each failed task into one of this module’s failure categories, based on its observed behavior, then aggregate the frequency of each category across the full batch. The most frequently occurring failure mode represents the highest-leverage place to focus mitigation effort — for example, if hallucination is the most common failure, prioritizing groundedness verification would address more real production issues than, say, improving tool descriptions for a comparatively rare wrong-tool-selection problem. This data-driven prioritization avoids guessing at which fix matters most.

14. What You Should Remember

Agent failures span a real, wide taxonomy — hallucination, wrong tool selection, wrong parameters, tool failure, infinite loops, stale memory, conflicting information, and cost/latency explosion — each with a specific, different mitigation.
The diagnostic pattern — problem, why it happens, example, impact, mitigation — provides a systematic way to analyze any new failure, verified directly through a working catalog and classification function correctly categorizing real scenarios.
Aggregating failures across many tasks reveals where to prioritize engineering effort — verified directly through an analyzer that correctly identified the most frequent failure mode in a batch of records.

15. Quick Practice

For an agent in your own domain of interest, describe one plausible failure scenario for at least four of this module’s failure modes, and identify the specific mitigation (from earlier modules in this course) that would address each one.

16. Next Step

Next: Module 20 — Agent Evaluation — Level 8 begins here: why evaluating an agent is harder than evaluating a single LLM response, and what metrics actually matter.

Author: TechByteByByte Editorial Team
Reviewed by: TechByteByByte Admin
Published: August 31, 2026
Last reviewed: August 31, 2026