Executive summary
Agentic systems fail at more than model accuracy. They can pursue the wrong goal, select bad evidence, create an infeasible plan, misuse a legitimate tool, corrupt memory, amplify errors through coordination, loop without progress, hide causality, fail to reconcile side effects, or overload human review. A useful taxonomy connects each category to representative cases, trace evidence, prevention, detection, and recovery. It should be adapted to the actual workflow and used to design an evaluation dataset and release gate.
Decision relevance: Define which agentic failure classes matter for the workflow and how each will be detected, contained, and reviewed.
Testable failure taxonomy
| Failure family | What fails | Evaluation direction |
|---|---|---|
| Goal and objective failure | The system pursues the wrong objective, loses constraints, or follows an injected goal. | Test conflicting instructions, indirect injection, goal restatement, policy precedence, and long-run drift. |
| Evidence and retrieval failure | The system uses unauthorized, stale, incomplete, poisoned, or irrelevant evidence. | Test source allowlists, tenant isolation, missing evidence, freshness, citation correctness, and poisoning. |
| Planning and decomposition failure | The plan is incomplete, cyclic, infeasible, or omits a consequential dependency. | Score plan coverage, ordering, feasibility, dependency recognition, and stop conditions. |
| Tool and authority failure | The system chooses an unsafe tool, widens scope, supplies harmful arguments, or acts without authority. | Test capability allowlists, structured validation, value limits, task-scoped credentials, and refusal. |
| State, memory, and provenance failure | The system loses workflow state, remembers an untrusted claim, overwrites authoritative facts, or cannot resume safely. | Test restart, supersession, provenance, retention, concurrent updates, and unknown completion. |
| Coordination and delegation failure | Participants duplicate work, conflict, amplify an error, leak information, or produce an unowned result. | Test message contracts, role distinction, delegation chains, conflict resolution, and team baseline. |
| Termination and resource failure | The system loops, retries without progress, delegates recursively, or exceeds time, token, tool, or monetary limits. | Test budgets, cycle detection, progress checks, maximum depth, and independent kill paths. |
| Observability and attribution failure | The organization cannot reconstruct what happened, which identity acted, or why an effect occurred. | Test trace completeness, correlation, version capture, redaction, evaluator evidence, and audit export. |
| Recovery and reconciliation failure | Traffic returns but backlog, duplicated work, stale state, or incorrect business data remains unresolved. | Test rollback independence, durable state, idempotency, effect verification, and correctness recovery. |
| Human-oversight failure | Review is too late, overloaded, ambiguous, rubber-stamped, or unavailable when consequential action occurs. | Test reviewer capacity, interface context, escalation, disagreement, override, expiry, and appeal. |
Why outcome-only scoring is insufficient
The same final answer can emerge from a safe path or an unsafe one. Conversely, a failure may result from timeout, environment friction, or an early recoverable step rather than lack of model capability. Research on agent logs and trajectory-oriented evaluation argues for inspecting the process, not only the leaderboard outcome. [S1] [S2]
Ten failure families
The taxonomy below is deliberately system-level. Each family should be refined into use-case-specific scenarios and severity criteria.
Map failures to controls and evidence
For each relevant failure, record prevention controls, runtime detection, alert owner, recovery path, retained evidence, and the release gate it affects. A category without an observable signal or owner is not operationally controlled.
Test combinations and cascades
Real failures combine. A poisoned retrieval result may change the goal, trigger an unsafe tool, write false memory, and propagate to another agent. Multi-agent research identifies recurring coordination failures and silent trajectory anomalies, making cascade tests essential. [S3] [S4]
Use severity based on consequence
Severity should reflect affected people, data, money, legal commitment, operational continuity, reversibility, scale, and detectability. A stylistic error and an unauthorized transfer should never share one generic quality score.
Research boundary
This taxonomy is an engineering starting point, not a complete threat model or universal risk register. Security, safety, domain, legal, privacy, and operational specialists may need additional categories and acceptance rules.
Sources
Sources support the linked statements and terminology. They do not certify a system, establish buyer intent, or convert this research into a formal assurance.
- Log Analysis Is Necessary for Credible Evaluation of AI AgentsarXiv · Accessed 2026-08-01
Research paper
- AgentAtlas: Beyond Outcome Leaderboards for LLM AgentsarXiv · Accessed 2026-08-01
Research paper
- Why Do Multi-Agent LLM Systems Fail?arXiv · Accessed 2026-08-01
Research paper
- Detecting Silent Failures in Multi-Agentic AI TrajectoriesarXiv · Accessed 2026-08-01
Research paper
- OWASP Top 10 for Agentic Applications for 2026OWASP GenAI Security Project · Accessed 2026-08-01
Open security guidance
- Towards a Science of AI Agent ReliabilityarXiv · Accessed 2026-08-01
Research paper