Why Agentic AI Fails — A Plain-Language Field Guide

01 · The core idea

An agent is a feedback loop, not a chatbot

A chatbot answers one question and stops. An agent takes a goal, breaks it into steps, calls tools, looks at the results, and keeps acting until the job is done — or until something goes wrong.

In control terms: a chatbot is an open-loop command. An agent is a closed-loop controller — it observes, reasons, acts, and observes again. And like any feedback system, it can go unstable. Small reasoning errors don't stay small; they get fed back into the next step and accumulate.

Fig. 1 — The agent loop. Reliability problems live in the dashed red path: what comes back from the world, how the agent judges progress, and when it is allowed to stop or act again.

The video's central claim^[1] is that agents usually don't fail because "the LLM hallucinated." They fail because the system around the LLM wasn't engineered: no stopping rules, no plan validation, fuzzy tool definitions, no memory of what was already tried, and too much authority over real-world actions.

02 · The three failure modes

Read these like diagnostic trouble codes

Each failure mode below is written the way you'd write a DTC entry: what you observe, why it happens, and the corrective action.

FAULT A-01 Infinite loops

Symptom

The agent searches for a document that doesn't exist — again. It retries the same failing API call. It rewords the same query a fifth time. Tokens burn, nothing changes.

Root cause

In simple words: the agent has no idea whether it's making progress. It can't tell "trying a new approach" apart from "repeating the same failed approach with different words." Nothing in the system defines what impossible looks like, so "try again" never ends.

Missing pieces: a retry budget, progress detection, a definition of "this task cannot be done with the tools I have," a fallback behavior, and a path to escalate to a human.

Corrective action

Bounded retries: same tool fails 3 times with no new information → stop.
Progress check: if state hasn't improved after N steps → escalate.
Honest failure: teach the agent to say "I couldn't find this after three attempts — the data may not exist or I may lack access." A truthful dead-end beats an expensive loop.
Step + cost budgets: hard ceilings on iterations, wall-clock time, and tokens per task.

FAULT A-02 Planning errors

Symptom

The plan reads beautifully and fails completely. Steps reference tools that don't exist, skip a required check, run in the wrong order, or declare victory without verifying anything.

Root cause

In simple words: LLMs are great at plans that sound right, not plans that are right. "Plausible" and "executable" are different properties^[4]. A plan can assume a capability the system doesn't have, misread the goal, ignore constraints, or never check intermediate results.

The video's example: "book a meeting." The bad plan is pick a time → send invite → say done. The good plan checks the calendar, checks attendee availability, proposes slots, gets confirmation, creates the event, and then verifies the event actually exists.

Corrective action

Planner–verifier split: one component proposes steps, a separate one checks them against available tools and constraints before execution.
Execute only approved steps — the executor never improvises beyond the validated plan.
Monitor outcomes: after each step, compare the result to the goal. "Sent the invite" is not "the meeting exists."
Ground plans in reality: the planner should only see tools that actually exist, with schemas that say exactly what each one can do.

FAULT A-03 Unsafe tool use

Symptom

An email goes out before anyone approved it. Records get deleted instead of archived. A payment API gets called with the wrong parameters. Production data changes because of a hallucinated assumption.

Root cause

In simple words: the dangerous part of an agent isn't the text — it's the actuator. A bad chatbot gives a wrong answer; a bad agent takes a wrong action. The moment an LLM can write to the world (files, email, databases, APIs, workflows), every reasoning error becomes a potential incident^[5].

Corrective action

Read-only by default. Write access is granted per-tool, deliberately.
Validate before writing: every write-class tool call passes a check against schema, scope, and business rules.
Human approval for high-impact actions — payments, deletions, external messages, production changes.
Tight tool schemas: each tool declares allowed inputs and side effects. Vague tools invite vague (and dangerous) calls.
Log everything. Every action, every parameter, every result. If you can't audit it, you can't trust it.

Practical note · for vehicle-systems people These three faults map cleanly onto familiar territory: A-01 is a controller with no anti-windup and no watchdog; A-02 is a trajectory planner that was never checked against actuator limits; A-03 is giving an unvalidated function full actuator authority without an ASIL-style safety case. The instincts you already have — bounded behavior, plausibility checks, degraded modes, monitoring — transfer directly.

03 · The deeper lesson

It's a systems-engineering problem, not an LLM problem

You don't make an agent reliable by picking a smarter model. You make it reliable by surrounding the model with structure.

The hype version

LLM + tools + loop
= "agent"

The production version

LLM + tools + state machine
+ verifier + policy
+ observability + bounded autonomy
= reliable agentic system

Each layer in the production version exists to catch a specific failure class:

Reliability layers and what each one prevents
Layer	What it does, in plain words
Goal definition	Makes the task precise enough that "done" is checkable.
Planner	Breaks the task into candidate steps.
Tool interface	Defines exactly what actions are possible — and nothing more.
Memory / state	Tracks what has already been tried, so the agent can detect "I'm repeating myself."
Verifier	Checks plan validity before execution and output quality after.
Guardrails	Blocks unsafe actions regardless of how confident the model sounds.
Stop conditions	Ends loops: retry budgets, progress thresholds, impossibility detection.
Observability	Logs every decision and tool call so failures can be diagnosed, not guessed at.
Human-in-the-loop	Catches uncertainty and approves high-risk actions.

04 · Reference architecture

A pipeline you can actually build

For a serious enterprise agent, the flow looks like this. The single most important block is highlighted — without it, the agent can loop forever or compound its own mistakes.

User goal what does the person want?

Intent / scope classifier is this in-scope & allowed?

Planner agent propose steps

Plan validator are the steps real & legal?

Tool router pick the right tool

Execution layer bounded authority

Result verifier did it actually work?

Stop / retry / escalate the block that prevents A-01

Final answer or human review with full logs

Practical note · for RAG / knowledge-agent builders This maps one-to-one onto a grounded knowledge-engine design: deterministic retrieval and graph facts feed the reasoning step; a verifier agent enforces an evidence policy ("every claim must trace to a source"); anything below the confidence bar escalates to a human. The principle is the same throughout: an agent earns trust not by sounding smart, but by being grounded, bounded, verified, and logged.

Practical note · where to start tomorrow If you change only three things in an existing agent, change these: (1) add a hard step/retry budget with an honest failure message, (2) split planning from execution with a validation pass between them, and (3) make every write-class tool require explicit approval. Those three moves neutralize the bulk of A-01, A-02, and A-03 respectively.

05 · References & further reading

References

IBM Technology — "Why Agentic AI Fails: Infinite Loops, Planning Errors, and More." The source video for this guide: agent failures as a systems problem (loops, planning, unsafe tool use) rather than purely a model problem. youtube.com/@IBMTechnology
Yao, S. et al. (2022) — "ReAct: Synergizing Reasoning and Acting in Language Models." The foundational pattern behind the observe → reason → act loop most agents use today. arXiv:2210.03629
Shinn, N. et al. (2023) — "Reflexion: Language Agents with Verbal Reinforcement Learning." Self-critique as a mechanism for detecting lack of progress — relevant to loop prevention. arXiv:2303.11366
Kambhampati, S. et al. (2024) — "LLMs Can't Plan, But Can Help Planning in LLM-Modulo Frameworks." The strongest academic case for the planner–verifier split: use LLMs as plan generators, external critics as validators. arXiv:2402.01817
OWASP — "Top 10 for Large Language Model Applications." Includes "Excessive Agency" — the formal name for fault A-03 — with concrete mitigations around permissions and approvals. owasp.org
Anthropic (2024) — "Building Effective Agents." Practical guidance favoring simple, composable patterns with explicit checkpoints over fully autonomous loops. anthropic.com/engineering