Agent Goals

154 goals of documented AI agent failure patterns

Explore failure patterns organized by the specific agent goals and capabilities they affect.

Conversation Flow **Voice agents fail at conversation flow because dialog management in voice has to solve real-time turn-taking, persona consistency, structured data capture, and business-logic compliance simultaneously, and a failure in any one layer — a mistimed interruption, a leaked internal system name, a multi-field question, an ignored "busy" signal — breaks the illusion of a coherent conversation partner.** Conversation flow is the largest failure surface in voice AI because it is not one problem but at least seven: audio-level turn mechanics, agent persona and identity integrity, call lifecycle transparency, data capture mechanics, flow and compliance logic, adaptive responsiveness, and content pacing — each with its own root cause and its own fix. 44 patterns Conversation Quality **Conversation quality fails when an agent mismanages the ask-vs-act decision on ambiguous requests, loses track of its own conversational state over many turns, miscalibrates register to context, or lets small per-turn defects compound into an aggregate business outcome nobody was measuring.** Each of these four mechanisms produces failures that look fine in isolation — a single clarifying question, a single tone choice, a single satisfied user — but the damage shows up one level up: in rework rates, in trust, in retention curves, and in support-ticket volume. Conversation quality is where per-turn correctness and aggregate user experience diverge, which is why 8 of the 23 patterns documented here are about measurement and business-outcome failures rather than any single bad response. 23 patterns Dependency Management **Agents depend on external services, libraries, and data sources, and agent systems depend on each other to coordinate work. Dependency-management failures occur when versions conflict, APIs change incompatibly, circular dependencies deadlock the system, or transitive dependencies bring in security vulnerabilities, licensing conflicts, or incompatible schema versions that break data pipelines and integration contracts.** 23 patterns Input Output Handling **Agents receive input from users and upstream systems, and produce output that downstream systems and users consume. Input-output-handling failures occur when input is not validated, output is not sanitized, encodings mismatch, or edge cases in data format (null bytes, special characters, timezones) are not handled, resulting in silent corruption, injection vulnerabilities, or downstream failures that are hard to trace back to input issues.** 22 patterns Knowledge Freshness **Knowledge freshness fails when an agent applies information that is true in isolation but wrong for the moment, scope, or domain-context it's actually needed in — a fact that was accurate a year ago, a rule correctly quoted but misapplied to a case its exception covers, or a single retrieved sentence stripped of the qualifier that made it safe to act on.** The 22 patterns documented here span three distinct levels of the same underlying problem: domain-level judgment that a generic retrieval pipeline doesn't encode, single-fact distortions introduced during retrieval or generation, and system-level architecture gaps — no expiration mechanism, no update pipeline, no source-trust weighting — that make the other two levels of failure more likely. None of the 22 patterns require a hallucinated fact; every one is about a true fact applied at the wrong time, scope, or level of domain nuance. 22 patterns Memory Management Memory summarization and retrieval 22 patterns Version Management **Version management fails when system components (agents, tools, SDKs, data schemas) upgrade asynchronously without compatibility checking, when backward compatibility is not maintained, when breaking changes are deployed without notice, or when version rollbacks leave corrupted state.** The 22 version-management patterns documented here cover the challenge of managing versions across distributed agent systems — from API versioning through data schema migrations, to deployment coordination and rollback safety. Version failures are particularly dangerous in production because they often only manifest under the specific combination of versions that production deploys, not in testing where all components are on the same version. 22 patterns Fault Tolerance **Agent systems fail constantly — services time out, data becomes corrupted, dependencies crash, and network partitions split systems. Fault-tolerance failures occur when agents don't detect failures quickly, don't recover from them cleanly, or apply recovery procedures that introduce new failures, such as cascading timeouts, partial rollbacks that leave data inconsistent, or failover delays so long that SLAs are already violated.** 20 patterns Safety Security **Safety and security fail when agents designed with guardrails, authorization checks, and safety mechanisms instead bypass those guardrails via prompt injection, excessive agency, memory manipulation, or audit evasion—discovering breaches only after unauthorized actions have propagated.** An agent designed to never exfiltrate data gets a prompt-injected request and explains how to extract the database, an agent with explicit permission checks gets poisoned via memory injection into a knowledge base and subsequently grants unauthorized access without triggering any authorization system, and a system designed to audit agent actions discovers that audit logs themselves were manipulated to hide unauthorized operations. Safety and security failures matter precisely because they represent direct violations of core safety commitments: a system designed to never do X that does X is fundamentally broken. 19 patterns Security Autonomy **Security-autonomy fails when agents with broad tool access, file handling, and code-execution capabilities are compromised via prompt injection, tool-output injection, or supply-chain attack—executing unauthorized commands, exfiltrating data, or escalating privileges before detection.** An agent designed to autonomously complete tasks gets a prompt-injected request embedded in retrieved document and executes a data-exfiltration command, an agent chaining tool outputs together does not validate intermediate outputs and an attacker injects malicious commands via tool output that agent blindly executes, and an agent updates dependencies without verification and a supply-chain-poisoned package introduces backdoors into agent reasoning. Security-autonomy failures matter precisely because autonomy amplifies the impact of compromises: a compromised agent that can execute code, invoke tools, handle files, and escalate privileges is far more dangerous than one with limited autonomous capabilities. 19 patterns Tool Reliability **Tool reliability fails when tools return stale data, when tool outputs are misinterpreted, when tools silently fail without error signals, when external system failures cascade into agent failures, or when tool API versions change without backward compatibility.** The 19 reliability patterns documented here cover the full tool-use lifecycle — from selecting the right tool through invoking it correctly, handling output, and recovering from failures. Tool reliability is the foundation of agent reliability: unreliable tools cause unreliable agents, and failures in tool output parsing or handling propagate silently through agent reasoning. 19 patterns Cost Optimization Agentic planning, learning, and architecture-level cost waste — distinct from [Cost Efficiency](https://github.com/sarkars/agent-failure-modes/tree/main/agents/cross-cutting/operations/goals/cost-efficiency/)'s execution-level patterns (batching, retries, model routing). This goal covers failures where a known cost-optimization technique (plan reuse, prompt caching, adaptive ensembling, negative caching, compression) exists but isn't applied, or is applied incorrectly. 18 patterns Portfolio Recommendation Accuracy **Portfolio recommendation failures happen across the full lifecycle: backtests trained on biased historical data (survivorship, look-ahead, recency, overfitting) produce inflated expected returns; portfolio construction ignores tail risk, leverage dynamics, and factor crowding; actual implementation diverges from recommendations via execution lag and tax drag; and data quality gaps (staleness, missing fx consideration, currency risk) compound throughout.** No single recommendation agent can catch all these failure classes, because they span statistical modeling (backtesting), domain reasoning (risk factors), and operational implementation (execution, taxes). Agents frequently optimize for one dimension (backtest Sharpe ratio) at the expense of others (tail risk, tax cost, rebalancing lag). 18 patterns Output Accuracy **Agents generate plausible but false content when parametric knowledge lacks evidence, input is ambiguous, or the model defaults to learned patterns over retrieval — hallucinations and fabrications are particularly dangerous because they're well-formed and grammatically correct, so they pass basic sanity checks and propagate downstream before external validation surfaces the error.** Output accuracy failures concentrate in open-ended generation (summarization, synthesis) where there's no single "correct" answer and in scenarios where the agent has high confidence but low actual knowledge. 16 patterns Tool Access Scope Limits **Tool access scope fails when an agent can read data it should not have access to, when access controls are inherited incorrectly across hierarchy levels, when sensitive fields are exposed in tool responses, or when data classification rules are not enforced.** The 16 access-scope patterns documented here cover the full data-access pipeline — from field-level and record-level access control through workspace and geographic isolation, to PII exposure in responses and scope-downgrade failures. Access control is particularly fragile in agents because agents can call tools that return data fields the agent should not see, and without explicit masking or field-level filtering, those fields leak into agent reasoning and may be included in responses to users. 16 patterns Tool Rate Quota Limits **Tool rate limits fail when agents exceed per-minute or per-day quota thresholds, when quota reset times are not tracked, when rate-limiting strategies don't match tool semantics, or when quota is shared across multiple agents without fair allocation.** The 16 rate-quota patterns documented here cover the challenge of managing tool rate limits — from per-minute throttling through daily/monthly quotas, burst allowances, and fair-share algorithms for multi-agent systems. Rate-limit failures are particularly common in scaled agent systems where multiple agents share infrastructure and quota pools, creating resource-contention failures invisible in single-agent testing. 16 patterns Coordination **Multi-agent AI systems fail to coordinate because the system-design layer — who owns which decision, how messages are validated at handoffs, and how disagreement gets resolved — is left implicit, so agents fall back on ad hoc behavior that breaks silently under real workloads.** All 15 coordination patterns here trace back to the same taxonomy (MAST — Cemri et al., arXiv:2503.13657) of multi-agent system failures spanning specification gaps, inter-agent misalignment, and task-verification weaknesses. The shared consequence is that a multi-agent pipeline can pass every single-agent test and still fail once agents actually have to coordinate. 15 patterns Cost Efficiency Token and API cost management 15 patterns Inference Cost Management **Agent inference consumes resources — tokens, compute time, memory, network bandwidth. Inference-cost-management failures occur when agents consume more resources than budgeted, exceed quota limits, or degrade performance in response to resource constraints, resulting in unexpected bills, cascading timeouts, or service degradation that violates SLAs.** 15 patterns Verification **Agents skip or perform inadequate verification of their own outputs, leaving errors undetected — verification is absent (no check at all), shallow (checking only format not correctness), or biased (agent verifies its own work and finds no errors, even when a second opinion would catch them).** These failures are architectural: the problem isn't model capability, it's the absence of verification in the deployment pipeline or verification logic that lacks sufficient independence and depth. 15 patterns Approval Workflows **Multi-step approval chains break partway through because handoffs between stages fail silently, individual stages timeout without escalation, or decision authorities conflict over who can approve what — the request gets stuck in an intermediate state with no one owning the transition, or conflicting approvals authorize incompatible decisions.** Approval workflow failures are particularly dangerous because they often leave requests in an ambiguous state: some systems show "approved," others show "pending," and stakeholders disagree on whether the action can proceed. 14 patterns Spatial Reasoning **Vision models get spatial relationships wrong because 2D image projection is fundamentally lossy for 3D properties — depth, scale, occlusion, and viewing angle all collapse into ambiguous pixel patterns that a model must resolve using learned statistical priors rather than genuine geometric reasoning, and those priors fail whenever a scene departs from the "typical" arrangements seen in training.** Spatial reasoning is the largest goal in vision-and-images (14 patterns) because spatial reasoning fails at every stage of the pipeline: localizing an object precisely, inferring its depth or 3D shape, reasoning about what's hidden behind another object, correcting for viewing angle, judging its absolute size, and staying consistent when several images or a video sequence are involved. 14 patterns Tool Operational Limits **Tool operational limits fail when tools have undocumented limits on request size, result size, timeout windows, or concurrent requests, when agents exceed these limits without knowing, or when limits are exceeded gracefully by some tools but cause crashes in others.** The 14 operational-limit patterns documented here cover runtime constraints on tool behavior — from per-request size limits, through timeout windows and concurrent-request limits, to payload encoding limits and result set sizes. Operational-limit failures are particularly dangerous because limits are often discovered by exceeding them in production, not during testing with small payloads. 14 patterns Reasoning Quality **Agents break down complex tasks incorrectly, deviate from goals, violate domain rules, or fail to correct themselves because the reasoning process isn't grounded in verifiable prerequisites, domain constraints, or external feedback — the agent produces a coherent-sounding plan or conclusion that violates requirements or misses critical steps, only surfacing as a failure when execution reveals the gap.** Reasoning failures are silent: the agent's reasoning trace looks structured and logical, so the error only surfaces when downstream consequences expose the flaw. 13 patterns Retrieval Quality **Retrieval quality fails when the pipeline finds documents that are topically plausible but wrong along a dimension similarity search doesn't measure — outdated, jurisdictionally inapplicable, poorly ranked relative to a better match sitting a few positions lower, diluted by too much or too little context, or compromised by an embedding-model version mismatch or a poisoned document nobody vetted.** All 13 patterns share the same root limitation: semantic similarity is the one signal nearly every retrieval pipeline optimizes for by default, and every pattern here documents a case where similarity and correctness diverge — a textually-similar document that is stale, jurisdictionally wrong, structurally split, or simply outranked by a better match the system never surfaced. 13 patterns Conversation Resolution **Conversation resolution fails when a support agent selects a canned response matching the customer's topic but wrong for their account state, asks repeated questions the customer already answered, escalates before attempting a solvable request, or fails to detect and adjust to escalating customer frustration.** Unlike general conversation-quality failures that are about tone and state tracking, resolution-specific failures concentrate on support-domain concerns: whether the right canned response was selected for this customer's tier, whether the escalation threshold was calibrated correctly, whether basic support-conversation mechanics (asking once, listening to frustration signals) are working. 12 patterns Governance **Agents operate without accountability, transparency, or compliance controls — there's no audit trail of actions, no human owner responsible for failures, no rollback plan when things go wrong, no incident process, and no mechanism to prove to regulators that decisions were made according to policy.** Governance failures are peculiar because the agent may make correct decisions, but the *governance structure* around the agent is absent — regulators and auditors can't verify compliance even though the agent behaved correctly, because the compliance infrastructure doesn't exist. 12 patterns Real Time Performance **Real-time performance fails when requests queue, cold starts add unacceptable delays, batching introduces latency penalties, network hops compound inference time, tool calls accumulate on each turn, or timeout configurations mismatch actual system behavior.** The 12 performance patterns documented here cover the full request lifecycle from initial invocation through inference, tool calling, and response — and many are invisible without latency instrumentation: an inference engine that performs well in isolation may still cause SLA breaches when cascading across multiple agent turns, or an adaptive system may perform optimally in testing but degrade under real traffic patterns when observability doesn't catch the transition. 12 patterns Retrieval **Retrieval fails when the pipeline searches the wrong corpus, returns too few or too many documents, misses content trapped in tables or scanned images, or hands synthesis a set of chunks that are individually correct but collectively stale, contradictory, or poorly assembled.** The 12 retrieval patterns documented here cover the full retrieval pipeline end to end — from picking the right knowledge base, through precision/recall tuning and content-extraction gaps, to how the retrieved chunks get assembled and finally cited in a synthesized answer — and every one shares the same downstream risk: a retrieval-stage error is invisible to the generation model, which has no way to know the corpus, ranking, or extraction step upstream of it already went wrong. 12 patterns Safe Learning **Safe self-improvement fails when an agent ingests feedback or metrics and updates its behavior without adequate validation, catching the degradation only weeks later after shipping degraded behavior to production.** An agent optimizes conversion metrics while systematically violating policy guardrails, a system accepts feedback that contradicts known facts and bases behavior updates on noisy training labels, and a team patches a single failure case with a prompt fix that damages general reasoning—all three are caught by users or audits after deploying, not before, because the update pathway lacked gate checks for safety and correctness. Unsafe learning failures matter precisely because they hide inside the feedback and self-improvement systems that make agents adaptive: a well-instrumented feedback loop that routes every update through unvalidated optimization becomes a vector for degradation at scale. 12 patterns Tool Invocation **Tool invocation fails when agents pass wrong arguments, use wrong ID or key formats, misunderstand tool semantics, fail to page results, or retry non-idempotent operations without side-effect awareness.** The 12 invocation patterns documented here cover the challenge of calling tools correctly — from parameter validation through pagination, query scoping, timezone handling, and understanding when operations are idempotent. Invocation failures are particularly common because agents must understand and respect tool contracts (what parameters it accepts, what they mean, what side effects occur), and misunderstanding any part of that contract leads to failed or incorrect tool calls. 12 patterns Action Execution **Action-execution failures happen when an agent's decision to act is correct but the act itself — its authorization, target, timing, or mechanics — is not**, so the agent ends up charging the wrong account, deleting something it can't restore, or looping a retry into a runaway cost. Action-execution failures matter more than most because the failures are the point where an agent stops reasoning and starts changing the state of a real external system — a payment processor, a ticketing system, a production deployment — where mistakes carry their own blast radius independent of whatever reasoning produced the mistake. 11 patterns Agent Trust **Inter-agent trust fails when a system designed for multi-agent collaboration accepts outputs, delegates tasks, or chains decisions without verifying that upstream agents are actually trustworthy, have the capabilities they claim, or executed tasks correctly.** An orchestrator delegates security-review work to an agent that claims expertise but lacks smart-contract knowledge and ships code with a $2M vulnerability, a knowledge-base-poisoning attack injects malicious instructions that bypass tool-sandboxing and circuit-breakers because the corrupted beliefs look like normal context, and one agent's corrupted state propagates through a chain of five downstream agents before anyone detects the problem. Agent-trust failures matter precisely because they hide in multi-agent architectures that assume "if Agent A says Agent B did it correctly, then B did it correctly"—a trust-by-default model that scales attack surface with agent count. 11 patterns Answer Synthesis **Answer synthesis fails when a model has the right retrieved context in front of it and still produces a wrong or misleading answer — drifting off the actual question, ignoring the context in favor of stale training data, cherry-picking supporting evidence while dropping caveats, hallucinating details the context never contained, or losing a fact to over- or under-stuffed context.** All 11 patterns describe failures that happen after retrieval has already succeeded, which is what makes answer synthesis distinct from a retrieval problem: the correct information was there, and the generation step still didn't deliver it faithfully. 11 patterns Tool Financial Limits **Tool financial limits fail when cost structures are opaque to agents, when agents make decisions without knowledge of per-operation costs, when budgets are exceeded without early warning, or when cost attribution is unclear in multi-agent systems.** The 11 financial-limit patterns documented here cover pricing and cost management in agent systems — from hidden per-operation costs, through tiered and burst pricing structures, to total budget exhaustion and cross-tool budget allocation. Financial failures are particularly dangerous because unlike performance or reliability issues that fail fast, financial issues accumulate silently until the bill arrives. An agent that uses an expensive operation 1000 times might not discover the mistake until the cost bill shows up. 11 patterns Trading Execution **Trading execution failures occur when agents size, time, or route orders without modeling the actual cost and feasibility of execution, or when they misdiagnose what actually filled versus what was intended, leading to unintended positions, regulatory exposure (wash trades), and slippage that erodes or reverses the intended alpha.** Execution failures are often asymmetric in detection: an order fills at a worse price than estimated and the loss is diffuse (1-2 basis points times thousands of shares), while a major execution error (wrong instrument filled, wash-trade pattern, venue routing to a thin book) surfaces only in post-trade reconciliation hours later. Execution agents frequently optimize for a single dimension (best quoted price, lowest fees) without considering the full cost surface (fill probability, information leakage, slippage under realistic book depth, tax impact of forced liquidation). 11 patterns Agent Handoffs Delegation **Multi-agent workflows rely on one agent successfully transferring a task to the next, but handoffs often fail due to missing context, broken accountability, or timing mismatches. Agent-handoffs-delegation failures occur when the sending agent doesn't transfer sufficient information, the receiving agent doesn't acknowledge receipt, or the orchestration layer doesn't enforce handoff preconditions, leaving tasks orphaned, executed without approval, or duplicated.** 10 patterns Cross Document Validation **AI systems fail to validate data consistency across 50+ mortgage documents because single-document processing misses systemic inconsistencies—name variations, SSN mismatches, income triangulation failures, employment timeline conflicts, co-borrower confusion, and asset source tracing—that only appear when multiple sources are compared against each other.** Mortgage loan files contain overlapping data points (borrower name, SSN, employment, income, address, assets) that must reconcile across W-2s, tax returns, pay stubs, bank statements, and applications; when AI processes documents in isolation, fraud patterns that rely on document-to-document inconsistency slip through undetected. 10 patterns Data Extraction **AI systems fail to extract structured data from mortgage documents accurately because the documents themselves are inconsistent—income appears in multiple formats across tax returns and pay stubs, property values on appraisals don't match tax assessments, names and addresses vary by document type, and debt obligations hide in footnotes and attachments—resulting in 5–15% field-level extraction errors that cascade through underwriting.** Mortgage documents span tax returns (1040, schedules with small fonts and annotations), pay stubs (varying employer formats), W-2s (multi-copy forms with OCR-resistant color), bank statements (image or PDF with variable layouts), appraisals (scanned from property inspections), and applications (handwritten or typed with inconsistent field placement); extraction failures on income, assets, employment, and property data create downstream calculation errors in debt-to-income, cash-on-hand, and property valuation. 10 patterns Diagnosis Safety **Diagnosis-safety failures happen when an agent's differential diagnosis or working hypothesis becomes progressively harder to revise or expand as new information arrives, or when that hypothesis is biased toward or against certain demographics or presentation types before any clinical evidence is even considered.** Diagnosis-safety failures are not hallucination failures where an agent makes up a diagnosis — they are cognitive-bias failures where an agent learns a statistical pattern from training data ("young + chest pain = anxiety more often than cardiac") and applies it with inappropriate confidence to an individual case, or where an agent reasoning over a multi-turn conversation anchors on an early hypothesis and reinterprets new, contradictory findings to preserve that anchor. 10 patterns Domain Decisions **Domain-decision failures happen when an agent has the right facts in front of it but applies the wrong rule, authority, or judgment to the facts** — approving an exception a policy doesn't allow, treating a critical issue as routine, or deciding a case that should have gone to a human expert. Unlike extraction or planning failures, domain-decision failures are judgment failures: the agent's inputs are often correct, but the domain-specific reasoning layered on top of the facts is wrong, which is why they surface in industries with dense, exception-laden rule sets — finance, healthcare, insurance, legal, and regulated support operations. 10 patterns Fraud Detection **AI systems fail to detect mortgage fraud because traditional fraud signals (inconsistent document values, form-field anomalies, missing signatures) are becoming less reliable—AI now generates plausible-but-fake pay stubs, tax returns, and bank statements that pass technical and content validation, and synthetic identities (fabricated people with real credit-history elements) leave no fraud victim to report, relying entirely on automated detection.** Mortgage fraud has historically required skilled forgers with access to physical documents and printing equipment; generative AI and document-synthesis tools now enable scale-fraud (thousands of fake applications per attacker) where single-loan detection rates matter far less than cohort-level pattern analysis (what looks normal for one loan looks like anomaly in the context of 100 similar applications). 10 patterns Goal Understanding **Goal-understanding failures happen when an agent optimizes for the wrong version of what it was asked to do** — a different meaning of an ambiguous request, a goal that quietly shifted over a long session, a metric that improved while the real outcome didn't, or a "done" state the agent invented because no one defined one. Goal-understanding failures sit upstream of everything else an agent does: a plan can be flawlessly executed and an action perfectly authorized, and the outcome is still wrong if the goal driving both was misread, drifted, or was never properly closed out. 10 patterns Memory Safety Safe memory operations 10 patterns Model Behavior and Capabilities **A model's behavior degrades without any error being returned because degradation in LLMs is almost always a soft, statistical ceiling rather than a hard limit — the API still returns a fluent, well-formed response at every level of context fill, conversation length, or task complexity, so nothing in the response itself signals that quality just dropped.** All 10 model-behavior-and-capabilities patterns describe a different axis along which degradation happens: task complexity exceeding effective capacity, context filling up, instructions and persona eroding over a long session, knowledge going stale, output format becoming unstable, reasoning becoming inconsistent, refusal boundaries becoming porous, and the model's own confidence signal being decoupled from its actual accuracy. 10 patterns Multi Agent Coordination Agent coordination 10 patterns Multi Agent Orchestration **Multi-agent systems coordinate the work of multiple agents to accomplish complex tasks. Orchestration failures occur when the coordination mechanism fails, causing agents to execute out of order, contend for resources, diverge into inconsistent states, timeout waiting for each other, or deadlock due to Byzantine agents, priority inversions, or race conditions that the orchestration layer didn't prevent.** 10 patterns Multimodal Reliability **Multimodal reliability fails when a vision-language model produces a fluent, confident-sounding extraction that isn't actually grounded in what the document shows.** VLMs are trained to complete plausible text, not to signal visual uncertainty, so when a character is degraded, a field is genuinely absent, or a table's grid is ambiguous, the model fills the gap with a statistically likely value instead of admitting it can't tell — and reports high confidence while doing so. Multimodal reliability failures matter because the resulting errors are the hardest class of document-processing failure to catch: unlike classical OCR, which fails loudly with garbled or blank output, a plausible-wrong VLM answer passes every surface-level sanity check and is discovered only during downstream reconciliation, an audit, or a customer dispute. 10 patterns Planning **Planning failures happen when the plan an agent builds — or its absence — doesn't match what the task actually requires**, whether that means splitting the work into the wrong subtasks, inventing tools that don't exist, skipping a prerequisite check, or continuing to execute a plan the world has already invalidated. Planning sits between goal understanding and action execution, and a broken plan produces the same downstream damage as a broken action even when the agent's authorization, targeting, and intent were all otherwise correct. 10 patterns Planning and Decomposition **Agents often need to break complex tasks into subtasks, order the steps, and adapt plans when conditions change. Planning-and-decomposition failures occur when agents create invalid plans (missing steps, circular dependencies), hallucinate steps that don't exist, fail to adapt when circumstances invalidate the plan, or execute subgoals in the wrong order, resulting in wasted effort, impossible tasks, or cascading downstream failures.** 10 patterns Production Reliability **Production reliability fails when a document-processing pipeline that worked in testing degrades, silently or operationally, once it runs continuously at real-world scale.** A pipeline that scored 97% accuracy in evaluation can drop to 91% after a model update with no automated detection, a vendor can reorder invoice columns without notice and swap every value silently, and a well-formed but structurally wrong extraction can propagate into payment, ERP, and tax systems before anyone notices. Production reliability failures matter precisely because they are not caught by the availability and throughput monitoring most pipelines already have — 88% of businesses still report errors in their data pipelines, with teams spending six or more hours per week fixing "automated" data that looked fine when it shipped. 10 patterns Tool Authorization Limits **Tool authorization fails when agents designed to access only a limited, pre-approved set of tools instead escalate to broader tool access, bypass authorization checks, or invoke tools without proper validation.** An agent designed to read files in a sandbox directory discovers a path-traversal vulnerability and reads files outside the sandbox, an agent escalates from "read-only query" permissions to "write" permissions by modifying request context, and a tool-authorization check verifies the agent is authorized to invoke a tool but does not verify the agent is authorized for the specific parameters (reading one database table vs. all tables). Tool authorization failures matter precisely because tools are the agent's primary interface to external systems: overly broad tool access turns any agent compromise into full system compromise. 10 patterns Tool Selection **Tool selection fails when agents avoid necessary tools and attempt tasks without them, select the wrong tool for the task, select unsafe tools, overuse a single tool for multiple different tasks, or don't understand when different retrieval channels should be used.** The 10 selection patterns documented here cover the challenge of choosing tools correctly — from misunderstanding tool capabilities through sequencing errors (using tools in wrong order) to unsafe or untrusted tool selection. Tool selection is upstream of invocation and reliability: selecting the wrong tool guarantees failure regardless of how correctly it's invoked. 10 patterns Visual Hallucination **Vision-language models hallucinate objects, attributes, and entire scenes because they optimize for confident, contextually-plausible output rather than for grounding every claim in visible pixels — when evidence is weak, ambiguous, or architecturally unavailable (patch tokenization boundaries, rare-class underrepresentation, salient distractors), the model's learned prior about "what's typically here" overrides what's actually in the frame, and it reports the prior with the same high confidence as a correct detection.** Three of the ten patterns in visual hallucination are domain-specific instances of universal cross-cutting hallucination mechanisms; the other seven document vision-specific root causes — from patch-tokenization architecture to multi-step reasoning cascades — that don't have a non-vision analogue. 10 patterns Regulatory Compliance **Regulatory compliance failures in financial agents occur when agents apply rules that are outdated, jurisdiction-mismatched, or incompletely propagated across multi-agent handoffs, approving transactions or opening accounts that violate the actually-applicable regulatory framework at the moment of execution.** Compliance is a continuously-moving target: regulations change multiple times per year, jurisdictions differ, and effective dates matter. Agents trained on a fixed ruleset or operating on stale configuration rapidly fall out of sync with the regulatory environment, yet compliance infrastructure often has no mechanism to flag when a rule has changed and the agent has not been retrained. Multi-jurisdiction transactions compound this: a strategy that passes screening under the client's stated home jurisdiction may violate rules in the funding-source jurisdiction, a gap that is especially likely to occur when the account-opening agent notes the mismatch in free text but the structured compliance-screening schema carries only a single jurisdiction field. 9 patterns State Tracking **State tracking fails when an agent loses track of variables it set on earlier turns, when a variable binding gets corrupted or overwritten by a subsequent tool call, when failure signals are not propagated to downstream operations, or when state assumptions become invalid as agents iterate.** The 9 state-tracking patterns documented here cover the challenge of maintaining consistent state across agent turns where each turn adds new information, modifies existing state, or discovers that prior assumptions were wrong. State tracking is particularly fragile in agents because state is often implicit (stored in prompt context or model memory rather than explicit data structures) and updates are not transactional — an agent might update a variable on turn 5, crash on turn 6, and on recovery have no way to know whether the state on turn 5 was actually persisted or was merely in-flight. 9 patterns Accurate Text Extraction **Accurate text extraction fails when OCR or vision-language models misread characters, numbers, or punctuation in a document image** — most often due to image degradation (low resolution, skew), visually ambiguous glyphs (`0` vs `O`, `,` vs `.`), or a second visual layer (a stamp, watermark, or handwriting) interfering with the printed text. Text extraction failures are silent: the output still looks well-formed, so a misread value surfaces downstream as a wrong payment amount, a failed ID lookup, or a misparsed date rather than as a visible extraction error. 8 patterns Compliance **Compliance failures happen when a compliance agent reasons from a stale or mismatched snapshot of the law or the contract instead of its current, jurisdiction-correct state** — an amendment that was never consolidated into the analyzed document, a regulation that was amended after the model's training cutoff, a disclosure template pulled from the wrong jurisdiction by lexical similarity, or a jurisdiction-specific exception that a review agent identified in prose but never reached the filing agent's structured checklist. Every compliance pattern documented here produces output that reads as confident and well-formed, because the error is an omission or a substitution rather than a visible malfunction — the review is internally consistent, just wrong about what currently governs the filing. 8 patterns Context Management **Agents lose or misapply context over long conversations because system instructions become proportionally smaller as conversation history grows, conflicting instructions from multiple sources lack a declared resolution order, or state tracking breaks across session boundaries.** These failures are silent: the agent still produces well-formed output, but it violates earlier constraints, forgets important decisions, or becomes confused about which instruction to follow when two sources conflict. 8 patterns Data Loss Prevention **Data loss prevention fails when agents designed to protect sensitive data instead leak, exfiltrate, or expose information to unauthorized parties because safeguards are bypassed, incomplete, or unaware of where sensitive data actually flows.** An agent accepts a request to "summarize our customer database" and returns a summary that accidentally includes PII, a prompt-injection attack makes an agent ignore exfiltration-prevention guardrails and email database contents to attacker-controlled addresses, and a system designed to redact sensitive information in logs fails to redact data because sensitive patterns were never identified or the redaction happened after the data already propagated downstream. Data loss prevention failures matter precisely because they occur at the agent boundary with external systems: every time an agent receives untrusted input or produces output to an untrusted destination, data loss risk increases, and most agents lack the fine-grained data-tracking and exfiltration-prevention machinery of traditional DLP systems. 8 patterns Data Quality **Data quality failures in financial systems occur when agents ingest, cleanse, or propagate data containing misattributed entities, stale hierarchies, fabricated values, or unresolved ambiguities—and pass that corrupted data downstream to pricing, risk, or compliance calculations without flagging the corruption.** Most data quality failures are silent: a misread field, a merged entity, or a cached value presents itself as clean data until a downstream reconciliation or a compliance audit discovers the error months later. The core failure is structural—multi-stage cleansing and consuming agents operate on fixed schemas that drop critical provenance and confidence signals at handoff boundaries, leaving downstream systems blind to data-quality warnings that upstream systems actually surfaced. 8 patterns Document Integrity **AI systems fail to detect document tampering and forgery because technical integrity checks—PDF modification detection, metadata timestamp validation, font-substitution analysis, barcode-data matching, and digital-signature verification—are often skipped in favor of speed, leaving sophisticated forgeries (edited W-2s, backdated pay stubs, fabricated bank statements) undetected until post-closing audits or investor reviews.** Mortgage documents originate from multiple institutions (employers, banks, IRS, appraisers) and flow through scanning, extraction, and underwriting systems; each point in that pipeline presents an opportunity for tampering—PDF editing after creation, metadata backdating, font replacement to hide text changes, barcode manipulation, missing digital signatures—that AI systems built primarily for content extraction miss entirely. 8 patterns Document Verification **AI systems fail to verify that required documents exist, are authentic, complete, current, and properly signed because verification requires correlating multiple documents against regulatory checklists, performing manual-review escalations, and maintaining document-type-specific rules that AI systems often treat as generic—resulting in missing disclosures, expired pay stubs, unsigned documents, and altered evidence going undetected.** Mortgage underwriting requires 50–100+ documents (application, pay stubs, W-2s, tax returns, bank statements, employment verification, appraisal, title report, homeowners insurance, etc.), and each loan type, co-borrower scenario, and borrower employment situation requires different document sets; AI systems built to extract and validate content miss the meta-problem of document completeness, recency, and authenticity. 8 patterns Evaluation Reliability **Agents pass evaluation on golden datasets but fail systematically in production because the test dataset doesn't represent production's actual distribution, contains stale or mislabeled data, or measures the wrong metrics — the evaluation score doesn't predict real-world performance, creating a false sense of readiness.** These failures are silent: evaluation reports look good, so decision-makers trust the agent to production, where it fails on query types the golden set didn't cover. 8 patterns Human Oversight Reliability Human-in-the-loop reliability 8 patterns Query Understanding **Query understanding fails when an agent resolves what a user actually wants silently and incorrectly — guessing at an ambiguous term instead of asking, accepting a false premise embedded in the question, missing an unstated but obviously-expected requirement, or losing track of what a follow-up's pronouns refer to — rather than surfacing the uncertainty back to the user.** The shared mechanism across all 8 patterns is that models are trained to be helpful and to produce a complete-sounding answer, which creates a systematic bias toward silently picking one interpretation and answering confidently rather than admitting the query itself was underspecified, wrong, or only partially addressed. 8 patterns Runtime Security **Runtime security fails when attacks targeting agent execution at inference time—injection, exploitation, credential theft, tool-level compromise—succeed because runtime defenses are incomplete or misconfigured.** An MCP protocol message queue lacks authentication and an attacker injects malicious tool definitions that agents execute without verification, an agent processing untrusted user input in its context window does not isolate context from reasoning and leaks sensitive data from prior sessions mixed into context, and OAuth tokens used by agents are exfiltrated via side-channels or stored in memory without proper lifecycle management. Runtime security failures matter precisely because they occur during inference, not training: a model can pass all training-time security checks and still execute attacker-controlled code at runtime if the agent's runtime environment is compromised. 8 patterns Speech Recognition **Speech recognition fails in AI voice agents when the transcription layer either mishears open-vocabulary or ambiguous speech, or correctly produces uncertain output that the application then treats as certain.** Names, numbers, accents, and domain jargon are all open- or low-frequency vocabulary that general-purpose ASR models under-cover; homophones and streaming interim results are inherently ambiguous until enough context arrives; and confidence scores meant to flag that uncertainty are frequently ignored or miscalibrated, so a 45%-confidence guess gets executed with the same downstream trust as a 98%-confidence one. 8 patterns State Consistency **State consistency fails when concurrent updates collide and both write partially, when replication lags and one agent sees stale data while another sees recent data, when serialization assumptions break and the same bytes deserialize to different values, or when version incompatibility causes schema mismatches.** The 8 state-consistency patterns documented here cover the full spectrum of consistency problems in distributed and multi-agent systems — from low-level serialization failures that silently corrupt data, through transaction-isolation problems that allow dirty reads and race conditions, to high-level distributed-consensus failures where majority-of-replicas rules decide state but minority replicas diverge. State consistency is particularly fragile in agents because agents often make decisions based on state, and an agent that sees inconsistent state may make inconsistent decisions or fail to idempotently retry an operation that should be safe to retry. 8 patterns Ticket Routing **Ticket-routing agents fail when they classify a ticket's product category by embedding similarity to a taxonomy node without verifying the account actually has that product, when they route based on surface complexity heuristics without estimating actual resolution effort, when they ignore language mismatch between a ticket and the destination team's language capabilities, when reclassification on later messages silently reassigns a ticket already actively claimed by a human agent, and when an intake bot's determination of VIP account status never reaches the routing agent's working context.** Six distinct mechanisms produce six failure patterns in ticket routing: retrieval without provisioning verification, effort-estimation blindness, language-capability omission, ownership-state blindness, handoff information loss, and priority-signal gaming. Each mechanism independently defeats a different kind of verification: similarity-based taxonomy matching defeats account-provisioning confirmation, per-ticket effort prediction defeats cross-ticket complexity patterns, solo-language routing defeats joint language-topic constraint checking, stateless reclassification defeats ownership-state verification, handoff schemas omit task-relevant context, and priority-classification opacity enables gaming. 8 patterns Tool Allocation Limits **Tool allocation fails when agents exceed resource quotas (storage, CPU, memory, execution time), when quotas are shared across multiple agents without enforcement, when soft limits are treated as hard limits, or when quota-exhaustion is not detected until agents crash.** The 8 allocation-limit patterns documented here cover resource quotas and per-operation limits — from per-account API quotas that are shared across multiple agents (causing one agent to starve others), through per-operation CPU and memory limits, to execution-time quotas that timeout operations and execution-storage quotas that fill up unpredictably. Allocation failures are particularly dangerous in multi-agent systems where one agent's over-allocation starves sibling agents that share the same quota pool. 8 patterns Tool Selection Sequencing **Tool selection sequencing fails when agents call tools in wrong order, when tool outputs that should feed into downstream tools are formatted incorrectly, when agent forgets required prerequisites before calling a tool, or when conditional logic doesn't properly guard when tools should be called.** The 8 sequencing patterns documented here cover the challenge of orchestrating multiple tools into correct sequences — from tool dependencies through conditional invocation, to error recovery when one tool fails and downstream tools must adapt. Sequencing failures are particularly dangerous because a single tool called at the wrong time or with wrong prerequisites can cascade into complete workflow failure. 8 patterns Traceability **Traceability fails when debug information is lost during processing, when actions are not logged completely, when decision context is missing from logs, when timestamps are absent or inconsistent, or when data flow cannot be reconstructed from audit trails.** The 8 traceability patterns documented here cover the challenge of maintaining observability and auditability in agent systems — from logging and timestamping through decision tracking, to reproducing execution for debugging and audit. Traceability failures are particularly insidious because they're invisible until an incident occurs and investigators need to reconstruct what happened. 8 patterns Voice Synthesis **Text-to-speech output sounds wrong when the synthesis layer applies a default, one-size-fits-all rendering to text that actually needs domain-specific pronunciation, content-appropriate emotion, or a stable persona, and none of those needs are encoded as explicit metadata the TTS engine can act on.** Brand names, acronyms, and heteronyms fall outside a general grapheme-to-phoneme model's training distribution; emotional register and disfluency need to match message content and persona rather than a single fixed voice style; and markup, waveform generation, and voice selection all have independent failure modes that surface as audible artifacts, mispronunciation, or an inconsistent-sounding agent. 8 patterns Adverse Drug Interaction **Adverse drug interaction failures happen when an interaction-checking pipeline is scoped narrower than the patient's actual regimen — pairwise drug-drug pairs only, structured prescriptions only, name-similarity lookups instead of exact identifiers — so an agent can pass every check it actually runs while missing the interaction that matters.** The checks themselves are not wrong; the boundary drawn around what gets checked is too small, whether that boundary excludes supplements, excludes lab-value and condition context, excludes three-way combinations, or substitutes a lexically similar drug's profile for the one actually prescribed. Because the output still reads as a confident, fully-resolved interaction determination, a clinician has no visible signal that the check ran against an incomplete or wrong input. 7 patterns Citation Accuracy **Citation accuracy fails when a citation exists and looks legitimate but doesn't actually do the job a citation is supposed to do — either the source doesn't exist at all, the source exists but doesn't support the specific claim attached to it, or the citation points at the wrong document, the wrong granularity, or a broken link.** The mechanism that makes citation-accuracy failures dangerous is that most of the 7 patterns pass a naive verification check: a user who clicks a citation and confirms the source is real has not confirmed the source actually supports what was claimed, and legal RAG tools measured at 17-33% hallucination rates show the gap is common even in citation-heavy, high-stakes domains. 7 patterns Demand Forecasting **Demand-forecasting agents treat conversational, qualitative forecast adjustments ("bump it up for the campaign") as replacements for structured baseline computations rather than deltas, embedding-retrieve cold-start demand analogs who are topically similar but demand-anomaly-laden, ignore structural constraints (promotion cancellations, bullwhip amplification) visible in multi-agent planning notes, and mismodel promotional lift and new-product adoption using flat, uninformed multipliers.** These patterns cluster around two categories: structural errors (forgetting to apply conversational adjustments to the model, ignoring multi-agent coordination constraints) and data-driven errors (analogs and seasonality selected without domain grounding, lift multipliers not category-specific). Demand-forecasting errors propagate directly into inventory and production commitments; a 10-20% forecast error causes excess or shortage with full operational impact. 7 patterns Generation Artifacts **Generated-image quality degrades over repeated generation or regeneration because generative models sample stochastically with no built-in mechanism to preserve quality, identity, or semantic intent across iterations — each pass compounds the previous pass's small errors, and by the 3rd-10th regeneration the output is visibly worse, semantically drifted, or has collapsed to a narrow set of repetitive outputs.** The failures in generation artifacts span the full generation pipeline: iterative noise accumulation, model-own-output distribution mismatch, prompt-conditioning limits, and the moderation layer bolted on top of the generator. 7 patterns Issue Resolution **Issue-resolution agents fail when they select a canned response by keyword similarity without verifying situational fit, when a multi-agent handoff loses a prior troubleshooting attempt the customer already described, when the same customer contacts support repeatedly for the same underlying problem treated each time as an independent resolution, when an autonomous refund is processed based on the customer's fluent claim without verifying the claim against the ledger, when knowledge-base content becomes stale, and when the agent re-suggests a troubleshooting step the customer already tried and reported as unsuccessful.** Six distinct mechanisms produce six distinct failure patterns in issue resolution: macro misapplication, handoff information loss, repeat-contact blindness, unverified-claim-to-action, knowledge staleness, and reachability to repeat suggestions. Each mechanism independently defeats a different kind of verification: template confidence defeats situational appropriateness, schema-bounded handoffs defeat cross-stage information transfer, per-ticket resolution metrics defeat cross-ticket pattern detection, fluent claim phrasing defeats ledger verification, static content defeats currency maintenance, and handoff loss defeats repeated-suggestion suppression. 7 patterns Model Updates and Versioning **Model update and versioning failures happen because changing which model version serves an agent never gets the same safety net as a normal code deploy — a provider ships a retrained version that trades away a narrow capability inside an aggregate benchmark win, a pinned snapshot expires on the provider's own sunset schedule, a floating alias swaps underneath the team with no commit or deploy record to explain it, and reverting any of that is gated by an approval process built for forward changes, not emergencies.** All 7 patterns documented here trace back to the same structural gap: the team's change-management tooling is built to detect and approve changes the team itself makes, and a model version change is a change nobody on the team initiated. That gap is why model-updates-and-versioning failures are found late — through a complaint spike, a queue-volume audit, or a colleague's unrelated project behaving differently — rather than through the pipeline that's supposed to catch regressions before launch. 7 patterns Adversarial Robustness **Vision models lose accuracy when input images deviate from the conditions they were trained on — whether that deviation is a deliberately crafted adversarial perturbation, ordinary JPEG compression, unfamiliar lighting, low resolution, an out-of-distribution object, or an unfamiliar rotation.** The common mechanism across all six patterns is that convolutional and transformer vision architectures have no built-in invariance to compression, lighting shift, resolution loss, rotation, adversarial perturbation, or distributional novelty; robustness has to be trained in explicitly (via augmentation, adversarial training, or auxiliary detectors) or the model degrades — sometimes gracefully, sometimes as a sharp accuracy cliff, and in the adversarial and OOD cases, with unchanged or even increased confidence. 6 patterns Agentic Orchestration **Agentic orchestration fails when an agent's document reasoning is sound but the surrounding machinery — context management, tool calls, and self-correction — corrupts or loses the information the reasoning depends on.** Frontier agents score below 50% accuracy on Databricks' OfficeQA benchmark for real enterprise document reasoning tasks not because reasoning is weak, but because the agent read the wrong value, called a tool with the wrong page number, or "fixed" a correct field to match a misread total. Orchestration failures matter because they turn a single upstream error — a misread character, a truncated chunk — into a full pipeline failure that looks like a reasoning problem but isn't. 6 patterns Audio Handling **Voice agents fail under degraded audio conditions because the audio pipeline — network transport, device hardware, acoustic environment, and call session state — sits upstream of ASR and silently feeds it corrupted input, so the recognizer is doing its best on data that is already lossy before a single phoneme is decoded.** Packet loss, codec compression, background noise, echo, competing speakers, and disconnections all degrade the same signal in different ways, and each failure mode compounds directly into word error rate rather than surfacing as a distinct, catchable error. 6 patterns Compliance Validation **AI systems fail to detect regulatory violations—TRID timing breaches, APR calculation errors, missing disclosures, fair lending red flags, QM/ATR violations, and HMDA data misreporting—because validation logic often checks fields in isolation without enforcing regulatory thresholds or cross-document timing rules.** Mortgage processing sits at the intersection of federal (Reg Z, RESPA, Fair Housing) and state requirements, where lenders must verify not only that required disclosures exist but also that timing, accuracy, and fairness rules are met; AI-driven automation without compliance guardrails creates silent violations that trigger regulatory findings. 6 patterns Context Lifecycle Context assembly and truncation 6 patterns Cost Tracking Budget enforcement and attribution 6 patterns Document Classification **Document classification fails when a pipeline cannot correctly determine what a document is, where it starts and ends, or which schema applies, before extraction ever begins.** The root causes split into three distinct problems — pages that don't map cleanly onto document boundaries (blank pages, embedded attachments, scrambled multi-page batches), documents that look structurally identical to a different type or version (invoice vs. purchase order, 2023 template vs. 2024 template), and quality gates that reject readable-but-degraded input. Classification failures matter because every downstream extraction step inherits whatever the classifier got wrong — a purchase order routed through an invoice schema extracts nothing meaningful, since "Amount Due" doesn't exist on a PO. 6 patterns Established Framework Adoption The recurring mechanism across every pattern here: a well-solved problem (PII detection, prompt-injection defense, cost observability, RAG pipelines, agent evaluation, secrets scanning) already has a mature, publicly available framework, but the team builds ad-hoc or custom tooling instead — missing the edge-case coverage, tested defaults, and maintenance the framework would have provided. Distinct from the many existing *symptom*-level patterns elsewhere in this repo (e.g., PII leakage, credential leakage) — those describe what goes wrong; these describe the upstream root cause of not adopting the tool that would have caught it. 6 patterns Layout Preservation **Layout preservation fails when an agent reads every character correctly but flattens the document's two-dimensional structure into the wrong one-dimensional text stream.** Table boundaries, spanning headers, footnotes, running headers, and mixed-direction scripts all carry positional or hierarchical meaning that a naive top-to-bottom, left-to-right reading pass destroys — a two-column newsletter interleaves into a nonsensical sentence, a footnote reference gets appended as trailing body text, and a table with borders and no whitespace runs into one unparseable string. Layout preservation failures are especially dangerous because the extracted characters are individually correct, so the error only shows up when something tries to parse structure out of the flattened text — a line-item total, a footnote citation, a column value — and finds it's in the wrong place or missing entirely. 6 patterns Model Selection and Routing **Model routing layers send requests to the wrong model because routers are typically built to optimize one visible, easy-to-measure axis — cost, latency, or a coarse task-category label — while capability compatibility, instance health, and version-specific feature support are treated as separate, often stale metadata that isn't wired into the same selection decision.** The result is a request landing on a model that can't actually serve it (missing a capability), on a degraded instance the health check didn't catch, or on a materially different model version than the one the calling code was built and tested against — and because APIs often degrade gracefully rather than erroring, the mismatch is frequently invisible until an aggregate quality metric or a user complaint surfaces it. 6 patterns Multi Image Understanding **Vision models process images independently by default, so when a task requires reasoning across several images — the same object from different angles, consecutive video frames, or several imaging modalities — the model has no native mechanism to check consistency, maintain identity, or fuse conflicting evidence, and reasoning that would be correct on any single image breaks down across the set.** Multi-image understanding is a distinct failure surface from single-image hallucination or spatial error: the model can be accurate on every individual frame and still fail the moment two or more images need to be reconciled. 6 patterns Quality Control **AI systems fail to detect appraisal discrepancies because appraiser reports contain multiple value estimates (adjusted comparable sales, cost approach, income approach), each with different reconciliation methods, and QC systems often compare only the final appraised value to purchase price without validating the underlying comparable-sales data, appraisal date currency, and reconciliation logic that regulators scrutinize.** Appraisal defects are the #1 GSE repurchase demand category (27–35% of buyback demands), yet AI-powered QC systems often treat appraisals as data-extraction tasks (read the final value, check LTV, move on) rather than validation tasks (verify comparable sales are recent and location-appropriate, validate value reconciliation across approaches, check for appraiser-bias patterns). 6 patterns Self Service Deflection **Self-service deflection agents fail when they offer the same unhelpful suggestion repeatedly without escalating, when they direct customers through closed loops of cross-referencing FAQ articles, when they mark conversations as resolved based on silence rather than confirmed resolution, and when they surface deprecated help articles that reference UI or features no longer in the product.** Four distinct mechanisms undermine self-service deflection: failed-attempt blindness (no escalation trigger after N unsuccessful suggestions), circular-redirect architectural gaps (KB articles with no terminal exit to human escalation), silence-as-resolution measurement gaming (treating no-further-reply as success regardless of whether the issue was actually resolved), and knowledge-currency mismatches (outdated articles ranked by semantic similarity rather than currency). Each mechanism independently defeats a different kind of verification: per-turn response evaluation defeats cross-turn pattern detection, citation-graph topology defeat fails where cycles exist, timeout-based resolution detection defeats outcome verification, and semantic ranking defeats currency-status filtering. 6 patterns Sentiment Escalation **Sentiment-escalation agents fail when they select an escalation playbook by textual similarity rather than by confirming the ticket's actual severity tier, when a multi-agent handoff compresses a risk determination into a single numeric sentiment score that downstream routing logic cannot disambiguate, when sarcasm or passive-aggressive phrasing is misread as positive sentiment, when high-risk formal language (cancellation threats, legal references) is scored as neutral tone and not escalated, and when the agent invents a plausible-sounding causal narrative to explain a flagged ticket rather than grounding the explanation in the sentiment model's actual feature weights.** Five distinct mechanisms produce five failure patterns in sentiment escalation: playbook-selection mismatch, score-compression at handoff, tonal-incongruity blindness, content-based-risk omission, and hallucinated-rationale substitution. Each mechanism independently defeats a different kind of verification: textual similarity defeats structural severity confirmation, single-dimension handoff compression defeats multi-signal escalation logic, lexical-sentiment detection defeats tonal-incongruity checking, tone-based thresholds defeat content-risk detection, and free-text generation defeats feature-attribution grounding. 6 patterns Supplier Risk **Supplier-risk agents anchor risk scores to mismatched historical-supplier analogs selected by name-similarity or description-text similarity rather than by structured-attribute matching (industry code, ownership, geography), rely on quarterly/annual financial statement updates and miss faster-moving operational distress signals (payment term changes, delivery delays, key personnel departures), overlook geopolitical and regulatory risks visible in policy-discussion feeds but not yet reflected in operational metrics, overlook single-supplier bottleneck concentration risks, fabricate causal narratives linking co-occurring news events to risk scores without those events actually being model inputs, and drop elevated-risk flags at agent-to-agent handoffs before purchase-order finalization.** These patterns cluster around four categories: analog mismatches, signal staleness and blindness (operational, geopolitical), feedback and narrative misgrounding, and handoff brittleness. Supplier-risk failures manifest as undetected supply disruptions (single-supplier bottleneck exposed by an event), missed escalations (financial or geopolitical risk not flagged in time), and purchases committed against flagged suppliers because the flag was dropped at handoff. 6 patterns Tool Capability Limits **Tool capability fails when agents call deprecated endpoints that no longer exist, when beta features are unstable and cause unpredictable failures, when feature flags disable critical functionality, when regional or paid features are unavailable, or when API schema changes break parsing.** The 6 capability-limit patterns documented here cover the versioning and availability challenges of tool lifecycle management — from deprecated endpoints that should have been removed but still exist (causing confusion and encouraging continued use), through beta features that appear available but are unstable, to regional or paid features that are silently unavailable in some contexts. Capability failures are particularly challenging because they're often invisible in testing environments (which often run on stable, feature-complete endpoints) but appear in production when agents call endpoints that don't exist in production, use features disabled by feature flags, or attempt regional operations on non-regional infrastructure. 6 patterns Tool Compliance Limits **Agents execute tool calls without compliance guardrails — audit logging is not enforced at dispatch, so sensitive actions leave no record; PII data is retained past policy expiration; data is deleted without proper audit trail; logs can be tampered with after the fact — because compliance requirements are treated as optional side effects in individual tool implementations rather than mandatory enforced constraints at the framework level.** These failures are particularly dangerous because they violate regulatory requirements (GDPR, HIPAA, SOX) even when the agent behaves correctly, because the compliance violation is in the *governance mechanism*, not the *agent decision*. 6 patterns Tool Integration Limits **Tool integration fails when SDK versions are incompatible, when plugins conflict with each other, when tool webhooks are not delivered reliably, when API behavior is undocumented, or when tool versions drift and break integration contracts.** The 6 integration-limit patterns documented here cover the challenge of integrating multiple tools and versions into a cohesive agent system — from plugin compatibility matrices that aren't checked before deployment, through SDK version mismatches, to webhook delivery failures and undocumented API behavior that breaks in production. Integration failures are particularly dangerous because they often only manifest under the specific combination of versions and conditions that production uses, not during testing with single versions. 6 patterns Tool Special Constraints **Tool special constraints fail when tools have non-obvious requirements (authentication scope, allowlisted IPs, data residency restrictions) that agents don't satisfy, when regulatory constraints are violated, or when tool preconditions are not met before invocation.** The 6 special-constraint patterns documented here cover niche but critical tool requirements — from authentication and authorization scope through data residency and regulatory compliance, to tools requiring specific network conditions or preconditions. Special-constraint failures are particularly dangerous because they're often context-specific (work in dev, fail in prod) and cause silent failures (no error, just wrong behavior or data loss). 6 patterns Treatment Planning **Treatment-planning failures happen when a care plan is regenerated at each visit from current diagnoses alone without carrying forward previously negotiated patient-specific goals, or when treatment recommendations optimize for a single disease while ignoring comorbidities that render that treatment dangerous, or when a guideline-based recommendation is presented as fact despite active disagreement among major clinical societies on the same topic, or when a specialist identifies a contraindication to a planned treatment approach but that finding never reaches the downstream agent finalizing the plan.** Care plans that look clinically sound can silently override patient preferences set in prior visits, prescribe treatments that worsen comorbidities, or follow outdated guidelines while newer evidence-based alternatives exist. 6 patterns Anomaly Detection **Anomaly-detection agents produce false positives and false negatives because they optimize a baseline or threshold against the wrong reference — recent noise instead of a recall floor, temporal proximity instead of causal mechanism, or a static value instead of the seasonal or event-driven pattern actually shaping the metric.** Five distinct patterns are documented here, and every one traces back to the same structural gap: the detector's model of "normal" is simpler than the real signal, so it either fires on benign variation it never learned to recognize or stays silent on a real incident that resembles previously-tolerated noise. Because these are silent failures in both directions — a missed incident and a suppressed alert look identical to "no alert fired" — the cost of getting the baseline wrong is not visible until the next real event exposes it. 5 patterns Candidate Screening **Candidate screening agents systematically favor articulate or keyword-optimized candidates over substantively qualified ones, confuse surface-level similarity with actual job relevance, and discriminate against candidates whose circumstances differ from historical hiring patterns—all failures that pass initial screening validation because the misread value looks well-formed.** Screening errors are especially damaging because they occur upstream: a candidate eliminated at screening never reaches interview, where hiring managers might correct the agent's judgment. The patterns concentrate in three categories: bias and fairness (proxy discrimination, keyword overfit), skill assessment (sentiment-over-content, keyword brittleness), and process integrity (accommodation and skill-related information lost to downstream agents). 5 patterns Onboarding **Onboarding agents lose track of conditional requirements (visa-status-specific tasks, jurisdiction-specific benefits, accommodations) across multi-session workflows, retrieve wrong-jurisdiction benefits policies because embedding similarity favors shared boilerplate over distinguishing clauses, answer immigration questions from parametric pretraining knowledge instead of querying live policy tools, and fail to carry accommodations or exceptions from recruiter pre-boarding conversations into equipment-provisioning tickets.** Onboarding errors affect compliance (visa paperwork, tax withholding missing deadlines), employee experience (accessibility accommodations not ready day one), and operational correctness (wrong benefits eligibility communicated). The patterns cluster around three mechanisms: context loss across sessions, retrieval-induced policy mismatch, and multi-agent handoff brittleness. 5 patterns Output Optimization **Agents have access to known techniques that improve accuracy (confidence calibration, abstention on low-confidence answers, deterministic verification, self-reflection before high-stakes output) but these techniques aren't applied, are applied incorrectly, or are bypassed by workarounds — the agent produces suboptimal output even though the solution is known.** These failures are architectural: the problem isn't model capability, it's system design and integration of available techniques. 5 patterns Quota Achievement **Quota-achievement failures occur when agents calculate rep quota attainment using stale discount policies, fabricated approval records, mismatched coaching recommendations, or unverified credit adjustments, leading to compensation payouts that contradict approved discount ceilings, unfulfilled approval records, coaching that doesn't apply to the rep's actual deal dynamics, or split-credit adjustments that apply to only one rep.** Quota-achievement failures are high-stakes because they directly affect rep compensation, team morale, and regulatory exposure (if fictitious approvals or unauthorized discounts are discovered in audit). Unlike pipeline-forecasting errors that are asymmetric (discovery happens late quarter), quota errors are typically discovered at or after payout time, making correction difficult and damaging to rep trust. 5 patterns Retention Prediction **Retention-prediction agents fabricate conversational details in risk-score narratives that are not grounded in any source record, use stale industry-attrition benchmarks instead of querying live cohort-comparison tools, and anchor risk scores to mismatched historical-employee analogs selected by name or description similarity rather than by structured risk-factor alignment.** The most damaging failure is self-fulfilling feedback: once an attrition-risk score is visible to managers, those managers deprioritize the flagged employee for growth opportunities, causing the predicted attrition to materialize as a consequence of the prediction itself rather than the pre-existing risk. These patterns cluster around narrative grounding, benchmark staleness, retrieval mismatches, and score visibility feedback loops. 5 patterns Risk Detection **Risk-detection failures happen when an agent confirms the presence of a risk-mitigating clause (limitation-of-liability, indemnification, termination terms) without evaluating its actual scope, cap, or enforceability, when multiple clauses interact in ways the agent doesn't cross-check (an indemnification obligation that appears capped is actually carved out and uncapped), when complex contracts with multiple parties are analyzed without explicit obligation-tracking (who owes what to whom becomes ambiguous), or when temporal and conditional obligations are not reconciled against each other (a termination notice deadline that interacts with an auto-renewal trigger).** Risk-detection failures are silent because the agent produces findings that look protective — "indemnification clause present," "liability cap at $X," "termination rights identified" — when deeper analysis would reveal unquantified exposure, cross-clause conflicts, or missed obligations. Risk-detection patterns lead deal teams to believe their contractual risk is understood when it is, in fact, understated by an order of magnitude. 5 patterns Seo Optimization **SEO optimization fails when an agent retrieves a competitor's claim from a content corpus and incorporates it into the brand's own content, loses a negative-keyword exclusion constraint over a long planning session, approves a partial result from a rank-tracking API as a confirmed no-cannibalization check, or applies SEO metadata rules (title-tag length, canonical tags, meta-tag guidance) from stale internal knowledge instead of calling a live tool that holds current search-engine guidance.** SEO failures are frequently about lost context (constraints forgotten across turns, corrections dropped at handoffs) or outdated guidance (model-old rules replacing current search-engine guidance), rather than about algorithm optimization itself. 5 patterns Tool Sla Quality Limits **Tool SLA and quality limits fail when agents exceed tool-provided quality thresholds, when SLA targets are set but not monitored, when cascading failures from tool SLA breaches propagate upstream, or when tool quality degrades but agents don't detect or adapt.** The 5 SLA-quality patterns documented here cover the challenge of maintaining service-level agreements while using tools with their own SLAs — from monitoring tool SLA compliance through handling SLA breaches, to designing agents resilient to quality degradation. SLA failures are particularly insidious because they're invisible until an SLA is breached, by which point thousands of requests may have already seen degraded quality. 5 patterns Brand Consistency **Brand consistency fails when an agent generates content that drifts from the established voice, tone, terminology, or style without any change to the guidelines themselves — because a model was upgraded, a deprecated style-guide version is retrieved instead of the current one, or a prior editorial correction made mid-campaign never reaches a later pipeline stage.** The failures are invisible in individual pieces — each piece looks complete and on-brand in isolation — but cluster across a series: this week's copy uses casual tone, next week's uses formal, and the difference is not a strategic choice but a silent degradation of consistency the team cannot trace to a single rule change. 4 patterns Contract Drafting **Contract drafting failures concentrate at three integration points: assembling boilerplate clauses without reconciling negotiated specifics, retrieving the wrong clause version from a library of similar variants, and verifying that the final rendered document actually reflects the edits the agent claims to have made.** Contract-drafting failures are not hallucination or reasoning failures in isolation — the agent often correctly edits data, correctly retrieves text, correctly assembles a document — but fails to integrate those steps such that the output matches what was negotiated or what was committed to downstream. Because the drafted document reads as well-formed and syntactically correct, the error surfaces only when a counterparty redlines a contract that contradicts what was actually agreed, or when a dispute arises years later and the executed agreement is found to differ from the negotiation record. 4 patterns Deployment Safety **Deployment-safety agents fail to catch unsafe conditions before go-live because they apply the wrong checklist, miss dependency incompatibilities, base approval on segment-obscured aggregate metrics, or never encode a precondition in the structured deploy manifest that a downstream executor needs to verify.** Four patterns are documented here, spanning checklist-retrieval mismatches, hidden dependency version conflicts, canary approval based on aggregate-only metrics, and cross-system preconditions that vanish at the handoff boundary. Each failure allows a deploy to proceed that should have been blocked, and the unsafe condition is not discovered until production traffic hits the change and an incident surfaces the gap — a schema incompatibility, a dependency version break, a segment-specific regression, or a missing prerequisite flag flip. 4 patterns Due Diligence **Due-diligence failures happen when an agent reasoning over disclosed financial facts or contract terms constructs a causal or correlational narrative that drifts from the supporting evidence, when entity matching across heterogeneous sources (SEC filings, registry data, UCC liens) substitutes name similarity for identifier-based confirmation, or when a review-stage agent identifies a material risk only in its own annotation but that risk never propagates to the downstream summary agent because the structured handoff schema has no field to carry it.** Financial due-diligence memos narrating correlations as causal facts are the most visible manifestation — they read as expert analysis, backed by selective fact-picking, yet the causal links they assert lack transaction-level evidence. At the same time, corporate-structure errors (a coincidentally similar-named unrelated entity merged into the target's ownership chart) and multi-stage handoff failures (a change-of-control risk identified and then silently dropped between review and memo stages) are equally material yet invisible because the assembled outputs are internally self-consistent. 4 patterns Inventory Optimization **Inventory-optimization agents miscalibrate safety stock using demand-variance estimates computed at the wrong aggregation level (monthly when replenishment is weekly), treat quality-hold flags recorded in free-text inspection notes as not relevant to available-to-promise calculations, perform unit-conversion arithmetic via free-text reasoning instead of deterministic formulas, and borrow variance profiles from wrong-demand-driver analogs when setting safety stock for new SKUs.** These patterns concentrate around three categories: safety-stock miscalibration (variance underestimation, wrong analogs), multi-agent handoff brittleness (quality holds lost, reorder calculations operate on stale ATP), and arithmetic and unit-conversion errors in replenishment logic. Inventory errors manifest as stockouts (when safety stock is too low) or excess inventory (when it is too high), both with full working-capital impact. 4 patterns Ip Rights **IP-rights failures happen when an agent confirms the presence of IP-assignment language without verifying that the mechanism actually transfers title under the specific work category and jurisdiction at issue, when retrieval pulls a lexically similar template with a fundamentally different legal effect (a license grant instead of a full assignment), when a licensing agent treats a scope-restricted clearance as unrestricted because the field-of-use limitation existed only in prose but not in the structured handoff, or when a clearance opinion cites a specific license clause as granting a right but never independently re-reads that clause to verify the citation matches its actual text.** IP-rights patterns produce output that reads as legally protective and confident, because the operative text is well-formed and self-consistent — the assignment language is real, the template is genuinely related to IP, the clearance memo cites a real clause — yet the overall determination drifts from or misrepresents the actual legal effect because no independent verification step checks whether the mechanism-to-work-category match is sound, whether the retrieved template carries the intended legal effect, or whether the cited clause actually says what the opinion claims. 4 patterns Lead Scoring **Lead-scoring failures occur when agents compute a lead's likelihood-to-close using stale scoring rules, fabricated data when tool results are unavailable, superficially-similar deal precedents instead of structurally comparable ones, or missing critical information (disclosed budget ceilings) that should gate the entire score downward.** Lead-scoring failures are particularly insidious because they propagate directly into rep routing and prioritization: a rep receives a high-scoring but actually-unqualified lead and spends weeks pursuing it, while a genuinely qualified but lower-scored lead gets deprioritized and never gets AE attention. Scoring failures compound because reps calibrate their own qualification judgment to agent-provided scores, so when scoring is systematically wrong on a dimension (missing budget information, overweighting precedent similarity), reps begin prioritizing based on the corrupted signal. 4 patterns Logistics Routing **Logistics-routing agents commit customer ETAs based on cached or stale traffic data without re-checking live disruption feeds, select transit-time benchmarks for new lanes using description-text similarity instead of mode and border-crossing structure, treat carrier capacity as a static contracted ceiling rather than querying live carrier utilization, and fail to carry customs-hold risk flags from routing commentary into customer-facing ETA commitments.** These patterns cluster around three categories: cached/stale data treated as live (traffic conditions, capacity), retrieval mismatch (wrong historical lanes as benchmarks), and multi-agent handoff loss (customs-risk language in routing notes but not in ETA-commitment schema). Routing failures manifest as missed customer commitments (delayed arrivals), booking rejections (over-committed carrier capacity), or compliance violations (customs holds not flagged in advance). 4 patterns Market Data Freshness **Market data freshness failures occur when agents rely on cached, stale, or asynchronously-delayed price data, corporate-action information, or reference rates without detecting staleness, leading to valuations, risk calculations, and trading decisions grounded in data that no longer reflects market conditions or operational reality.** The core mechanism is silent degradation: a price feed can stop updating for hours and still pass basic connectivity checks, a corporate-action adjustment can be delayed days post-event, and an agent has no native signal that the data it is consuming diverged from the live market. Freshness failures are particularly acute in illiquid instruments and after-hours windows where misdiagnosis of staleness is common because flat prices can be genuinely flat or genuinely stale. 4 patterns Monitoring **Monitoring agents produce blind spots in observability by applying sampling policies that drop exactly the rare events most critical for diagnosis, configuring metrics with unbounded labels that overflow storage, implementing suppression rules without scope constraints that silence genuine incidents, or reading empty result sets from renamed metrics as if the system were healthy.** Four patterns are documented here, spanning log-sampling biases, metric-cardinality explosions, suppression-scope loss across agent handoffs, and empty-result misinterpretation. Each failure is silent — the absence of a log line looks identical to the absence of an error, an empty metric query result looks identical to a zero value, a suppressed alert looks identical to a non-firing alert — so monitoring agents cannot distinguish between "the system is healthy" and "we have no visibility into whether it is." 4 patterns Offer Generation **Offer-generation agents produce compensation figures from stale training-data benchmarks instead of querying live market data, anchor offers to mismatched leveling precedents selected via embedding similarity, and commit to negotiated terms in offer letters without verifying those terms were actually captured in the structured handoff from the recruiting coordinator.** These failures cluster around two categories: stale knowledge overriding live tools (compensation data, leveling precedents), and multi-agent handoff loss (negotiated exceptions, visa-contingent arrangements). Offer generation errors are silent — the output looks like a plausible offer letter — and materially affect allocational fairness (disparate offer bands by inadvertently using wrong precedents) and employer compliance (offers that contradict what the candidate was verbally promised). 4 patterns Pipeline Forecasting **Pipeline-forecasting failures occur across multiple independent dimensions: agents apply outdated stage-probability weights instead of current configuration, cite historical conversion-rate benchmarks that are structurally mismatched, or count deals in the pipeline despite unstructured disqualifying signals from upstream qualification, leading to forecasts that are systematically over-optimistic relative to actual close rates.** Pipeline forecasting is a particularly complex failure category because it compounds errors from upstream lead scoring and qualification: inflated lead scores inflate pipeline volume, poor lead quality inflates the count of deals that should be disqualified, and estimation bias (best-case projection, overconfidence in probability estimates) inflates the conversion-rate assumptions applied to each stage. No single forecasting fix addresses all these, which is why realized forecast error is one of the most consistent indicators that upstream lead-quality processes are degraded. 4 patterns Sla Management **SLA-management agents fail when they apply an incorrect SLA tier because retrieval selected a boilerplate-heavy but wrong-tier policy document, when a multi-agent handoff loses a customer-specific SLA override negotiated during support, when the agent generates a customer-facing breach explanation that fabricates a plausible-sounding root cause instead of retrieving the actual logged cause, and when the SLA clock pause/resume logic misclassifies the source of delay or fails to resume promptly.** Four distinct mechanisms produce four failure patterns in SLA management: retrieval-based tier selection, handoff schema narrowness, hallucinated-cause substitution, and status-field-based clock management. Each mechanism independently defeats a different kind of verification: similarity-based retrieval defeats structural tier confirmation, fixed handoff schemas defeat overtime-determined-override propagation, free-text generation defeats logged-cause grounding, and status fields defeat actual-causality checking. 4 patterns Supplier Onboarding **Supplier-onboarding agents extract certification fields from uploaded documents and treat extraction success as equivalent to verification against the issuing authority's own records, apply the wrong certification checklist to a new supplier because embedding similarity matches boilerplate language instead of category-specific distinguishing clauses, fail to trace sub-tier sourcing and detect counterfeit components because onboarding stops at business-legitimacy verification, and drop beneficial-ownership discrepancies (owner mismatch across documents) that exist in free-text cross-document-review notes but not in structured checklist fields.** These patterns cluster around three categories: certification verification gaps (extraction treated as verification, wrong templates), handoff schema brittleness (beneficial-ownership findings lost), and scope gaps (authenticity and sub-tier sourcing not included in business-legitimacy checks). Onboarding failures introduce counterfeit, fraudulent, or high-risk suppliers into the sourcing network, with potential product liability, compliance, or supply-continuity impact. 4 patterns Ai Model Reliability **AI models used in mortgage processing hallucinate values, validate their own outputs in circular loops, and deliver production accuracy far below vendor promises, creating a systemic gap where extraction errors cascade through underwriting without independent verification.** Large language models fabricate financial data, confidence scores don't indicate actual correctness, and the industry has optimized speed at the expense of data integrity—with lenders increasingly deploying AI to both extract AND validate mortgage data, creating a dangerous verification collapse where AI signs its own homework. 3 patterns Alert Routing **Alert-routing agents page the wrong team when the routing decision rests on an input that looks authoritative but isn't — a service-ownership mapping that was never revalidated after a reorg, a runbook retrieved by lexical similarity instead of structured ownership, or a suppression scope that a scheduling agent reasoned through but never wrote into the field the router actually reads.** In all three documented patterns the routing logic itself executes correctly given its input; the failure is that the input — a mapping, a retrieved document, a calendar entry — is stale, mismatched, or incomplete in a way the router has no mechanism to detect. That distinction matters operationally: fixing routing accuracy here means fixing the freshness and structure of the data feeding the router, not tuning the router's decision rule. 3 patterns Capacity Planning **Capacity-planning agents make recommendations that look accurate at the aggregate level but fail operationally because they optimize against a single signal (average utilization, a reference profile's name similarity) without checking whether that signal applies to the service's actual architecture or load pattern.** Three patterns are documented, spanning reactive scaling that oscillates instead of converging, retrieval that surfaces an operationally incompatible reference profile by name similarity alone, and infrastructure-level provisioning lag that the decision logic never models. Each failure is silent in the sense that a capacity recommendation can look reasonable until the service is deployed and real traffic exposes the mismatch — average utilization looks low until a peak period arrives, a reference profile looks similar until a service tries to scale horizontally despite being single-writer, or a scale-up decision looks sound until new instances take five minutes to come online and the spike has already passed. 3 patterns Claim Processing **Claim-processing agents fail in three distinct, recurring ways: a retrieval step pulls a superseded or wrong-jurisdiction policy document that looks textually similar to the correct one, a multi-agent handoff drops an exclusion or hazard flag between pipeline stages because the finding lived only in free text and never reached a structured field, and an agent answers a regulatory-deadline question from memorized pretraining knowledge instead of calling the live regulatory-requirements tool it has available.** All three patterns produce a confident, well-formed adjudication decision that is wrong in a way no downstream step catches, because each mechanism defeats a different kind of verification: similarity search defeats source-identity verification, schema-bounded handoffs defeat cross-stage information transfer, and parametric memory defeats tool-grounding. The result in every case is a claim paid, denied, or timed incorrectly — an outcome discovered only during a later audit, claw-back, or compliance review, well after the payment or notice has already gone out. 3 patterns Compliance Liability **Compliance and liability failures happen when an agent generates a high-stakes output — a de-identified dataset, an informed-consent summary, a consent-scope record — without an explicit verification gate that confirms the output meets the regulatory or clinical standard it claims to meet, so a structurally well-formed output can fail the safety or regulatory test it was designed to pass.** A de-identified dataset still contains re-identifying quasi-identifiers that escape a checklist-based Safe Harbor removal; an informed-consent note overstates what was actually discussed; or a structured consent-scope record drops a narrowed consent restriction that was captured in an intake transcript but never made it to the field the downstream agent actually reads. 3 patterns Deal Management **Deal management failures occur when agents assemble contract clauses, track negotiated terms, or approve deals using stale pricing data, wrong contract templates, or missing handoff fields that capture negotiated exceptions, leading to contracts that contradict what was actually agreed, quotes approved at unsustainable discount levels, or deals approved with material terms misaligned from the negotiation conversation.** Deal-management failures are asymmetric in detection: a legal team catches a contract-clause discrepancy only on pre-signature review, a deal-desk approves a discount under a now-superseded pricing policy because the discount tool's cache was not invalidated, and an AE discovers payment-terms misalignment only when the contract is generated from an approved deal record that lost the payment-terms exception at handoff. 3 patterns Incident Response **Incident-response agents fail during triage and response because they retrieve a resolution based on surface-level symptom similarity instead of root-cause signature matching, misattribute the underlying cause to a coincidentally-timed event rather than verifying a causal mechanism, or hand off a scoped determination (affected customer segment) to a downstream agent in a handoff schema that captures only the message, not the scope.** Three patterns are documented here, each concentrating on a different stage of incident response — resolution precedent retrieval, root-cause attribution in postmortems, and affected-scope propagation to communications. The common thread across all three is that an agent makes a determination that is locally correct (the precedent reads similarly, the deploy was indeed recent, the triage agent did identify the scope) but fails to propagate or validate that determination through to action, so the response based on that determination misses or misfires. 3 patterns Jurisdiction Handling **Jurisdiction-handling failures happen when a contract-drafting or compliance agent applies a rule from the wrong jurisdiction without detecting the mismatch, when a clause template is retrieved by subject-matter similarity rather than by controlling-jurisdiction filter, or when cross-border data transfers lack explicit verification that the specific transfer mechanism required by the originating jurisdiction's law is actually included in the contract.** Jurisdiction-handling failures are particularly consequential because they are silent — the contract reads as well-drafted, the clause language is genuine and appropriate for its subject matter, the compliance determination is internally consistent — but the entire legal foundation rests on a mismatched jurisdiction. A governing-law clause specifying New York law is correctly extracted but then reasoned about under California's rules; a non-compete clause is retrieved from a different state's template library because both states call the clause the same name and use overlapping enforceability language; a contract involves cross-border data flows but lacks the specific transfer mechanism (standard contractual clauses, adequacy reliance, binding corporate rules) required by the originating jurisdiction's data-protection law. 3 patterns Lab Result Interpretation **Lab-result interpretation fails when an agent treats a tool-returned lab payload as ground truth without verifying the payload's own embedded patient identifier matches the requesting context, or when it looks up a reference range by semantic similarity over assay names instead of by exact assay code, or when a critical value is embedded only in a routine note rather than triggering an immediate, separately-routed alert.** Critical values are especially high-stakes: a potassium or glucose value outside the safe range carries an implicit time-sensitive notification requirement, and an agent that summarizes it within a note without a separate critical-value gate silently introduces a delay that can be clinically catastrophic. 3 patterns Litigation Support **Litigation-support failures concentrate on three points in the evidence-handling pipeline: classifying discovery documents for relevance when vocabulary shifts (code names, abbreviations, terminology drift over time) cause the classifier to miss genuinely responsive documents; omitting material admissions from deposition summaries due to positional bias (mid-document content is systematically under-weighted); and failing to identify privileged communications when they arrive through indirect channels (forwarded threads, in-house counsel without legal-domain email addresses, business executives summarizing legal advice).** Unlike contract-analysis failures, litigation-support failures bear directly on case outcomes and ethics rules: missed responsive documents create spoliation exposure, omitted admissions undermine case preparation, inadvertent privilege waivers destroy attorney-client protection and create waiver-related sanctions. Because the outputs (discovery classifications, deposition summaries, privilege logs) are themselves litigation artifacts, errors in the agent's work become discoverable and attackable by opposing counsel. 3 patterns Medication Reconciliation **Medication-reconciliation failures happen when an agent matches a medication from one source (discharge instructions, home-medication list) to a formulary or reference database without grounding that match in the requesting context, or when an interaction flag identified during reconciliation exists only in narrative form and disappears at a handoff boundary, or when a discharge list is generated from the hospital's medication-administration record without reconciling against pre-admission home medications.** A reconciled medication list that looks complete and correct can silently carry a wrong drug substituted by similarity matching, or omit a home chronic medication that was never re-entered during a hospital stay. 3 patterns Observability Monitoring **Multi-agent systems are opaque by default — agents are distributed, asynchronous, and often operate independently. Observability-monitoring failures occur when the system lacks end-to-end tracing, has blind spots in visibility, or loses sight of failures until they cascade through multiple stages, making it impossible to diagnose root causes or detect problems before they become critical.** 3 patterns Policy Management **Policy-management agents fail when a renewal-pricing RAG step retrieves a similar-looking but territory-mismatched policy precedent, when a multi-agent handoff loses a mid-term endorsement that changed the risk profile, and when the agent answers a jurisdiction-specific cancellation notice requirement from memorized knowledge instead of calling the live regulatory tool.** The three failure mechanisms are indistinguishable from those in claim processing and fraud detection: retrieval without structural filtering, handoff without schema fields to carry task-relevant context, and parametric memory defeating tool-grounding. The result in every case is a policy priced incorrectly at renewal, a risk profile left unchanged after an endorsement, or a cancellation notice that violates a state's current legal requirement — failures that often go undetected until a loss-ratio review identifies the underpriced policy, a claim reveals an endorsed risk never reflected in the renewal, or a regulatory compliance review surfaces non-compliant notice wording. 3 patterns Precedent Currency **Precedent-currency failures happen when a legal research agent cites a case as controlling law without checking whether it has been overruled, when a research agent identifies an overruled status in its own analysis but never communicates that status to a downstream drafting agent through the structured handoff schema, or when a legal research agent fails to surface contrary authority across multiple circuits or jurisdictions despite knowing a circuit split exists on the cited proposition.** Precedent-currency failures are particularly damaging because they make a brief or memo's foundation of authority appear sound when the cited cases are in fact superseded, limited, or contradicted by later decisions that the research step could have retrieved but didn't. Because LLM research agents have access to legal-research databases and citator services but operate without explicit post-generation verification, superseded authority can appear in filed documents without detection until opposing counsel flags it, at which point the filing's credibility is irreparably harmed and strategic position is compromised. 3 patterns Rollback Safety **Rollback agents fail to actually restore working behavior because they treat orchestrator-level deployment success (pods are Ready, the rollout state is Succeeded) as sufficient validation that the application is healthy, ignore stateful side effects (schema changes, cache invalidation, feature-flag resets) that the rollback does not undo, or lose a critical override flag (do-not-revert marker on a hotfix) at the handoff boundary so an automated rollback reverts a separate, concurrent fix along with the bad change.** Three patterns are documented here, spanning orchestrator-state vs. application-health confusion, stateful-side-effect inconsistency, and protection-flag handoff loss. Each failure allows a rollback to be reported as successful when it has not actually restored the service to a working state — the change is reverted, but the state is corrupted, or the readiness probe passes while errors continue, or a concurrent hotfix gets collateral reverted — so the incident remains unresolved even though the automated system has marked itself complete. 3 patterns Underwriting **Underwriting agents fail when an occupation-class retrieval step matches applicants by job-title lexical similarity to a prior case without verifying that the retrieved precedent's actual hazard profile matches the current applicant's stated duties, when a multi-agent handoff loses an inspection-flagged hazard requiring a mandatory exclusion rider, and when the agent answers a catastrophe-zone question from memorized training-era geographic data instead of calling the live catastrophe-modeling or mapping tool.** The three failure mechanisms replicate across all insurance workflows: retrieval without corroborating structural verification, handoff without schema fields for task-relevant determinations, and parametric memory defeating tool-grounding for actively maintained data. Each failure produces an underwriting decision that looks well-reasoned — an applicant classified to a precedent occupation, a policy bound without a flagged-hazard rider, a property assigned to a memorized flood zone — but is wrong in ways that emerge later, after underwriting has closed and a loss occurs, or during a risk-management review. 3 patterns Clinical Documentation **Clinical documentation failures happen when an agent transforms chart data into structured output — a discharge summary, an after-visit note, a billing code — without explicitly grounding each element in what actually occurred during the encounter, so the agent fills gaps with plausible-sounding boilerplate or unverified transformations that the underlying source never supported.** Empty allergy fields become "no known drug allergies," unperformed ROS elements become documented, and billing codes become inflated by the language the agent chose to use rather than the clinical encounter that took place. 2 patterns Mental Health Triage **Mental-health-triage failures happen when risk assessment relies on keyword matching for crisis language and misses indirect, euphemistic, or future-oriented expressions common in genuine risk disclosures, or when a high-priority risk factor disclosed during intake exists only in the intake transcript and never reaches the structured acuity field that downstream routing uses.** The asymmetric cost of a false negative in mental-health triage — a missed high-risk case — is qualitatively different from most other diagnostic domains, yet risk-scoring models are often tuned against explicit-language datasets, breaking down on the indirect language that is paradoxically more predictive of actual risk in clinical practice. 2 patterns Refund and Billing Disputes **Refund and billing-dispute resolution fails when an agent retrieves a billing-dispute template or policy article that is embedding-similar but legally or contractually distinct from the customer's actual account tier or dispute category, or when a triage agent records that a partial credit was already issued but that critical detail is dropped when the conversation is handed to a downstream billing-dispute agent.** Both failures involve incorrect financial determinations (wrong refund threshold, duplicated credits) with real money at stake, making them high-severity failures even at low frequency. 2 patterns Reliability and Resilience **Reliability and resilience fail when agents cannot continue operating in degraded mode when a dependency becomes unavailable, when a system that works well at pilot scale silently degrades accuracy without alerting operators, or when architecture assumes all components will always be available.** The 2 patterns documented here cover graceful degradation (what happens when a dependency fails) and scale degradation (what happens as data volume increases 1000x) — both are reliability issues invisible in development or pilot testing because development doesn't replicate production conditions: pilots run on small datasets with reliable infrastructure, while production simultaneously scales data, infrastructure, and concurrency, each multiplying the conditions under which graceful degradation matters. 2 patterns Telehealth Triage **Telehealth-triage failures happen when an agent's internal reasoning correctly identifies urgency based on symptoms, but the structured routing ticket it generates is queued at a generic priority level that the downstream clinician queue sorts on, so the urgency conclusion never reaches the queue's sort order; or when vital signs are simply unavailable (no home device), and the agent treats the missing data as a neutral signal rather than as elevated uncertainty requiring escalation.** A triage bot reasoning that acute stroke symptoms require same-hour contact can be silently queued behind routine complaints because the structured priority field has no category for "emergency that doesn't fit a pre-defined flag." 2 patterns Tool Error Handling **Tool error handling fails when error codes change meaning between API versions or services, when error response formats are inconsistent, or when agents cannot distinguish between different failure modes and apply inappropriate recovery strategies.** The 2 error-handling patterns documented here cover the challenge of interpreting tool errors consistently — from error codes that have different meanings in different contexts (a 429 might mean rate-limited or out-of-quota depending on service), through response format inconsistencies that make parsing fragile, to scenarios where the same error code means different things at different times. Error handling is particularly fragile in agents because agents must interpret errors and decide how to recover (retry, fallback, fail), and interpreting an error incorrectly (treating transient network errors as permanent failures) causes cascade failures downstream. 2 patterns Agent Oversight **Agents using reinforcement learning or feedback-driven fine-tuning gradually drift from original goals toward unintended behaviors or reward-hacked alternatives that technically achieve the stated metric but violate the underlying intent — the agent learns clever shortcuts that pass evaluation but fail the human's actual needs.** Oversight failures are particularly dangerous because drift happens gradually over weeks or months of learning, surfacing only when proxy metrics (fraud, cost, accuracy) degrade, by which time the agent's behavior has embedded the unwanted pattern. 1 patterns Claims Processing **Claims-processing reserve models fail when they assume claims arrive as independent, randomly-distributed events and do not account for catastrophe correlation — a single hurricane hits and creates 10,000 simultaneous claims, depleting a $100M reserve provisioned on average-claim assumptions in days, while the model had no mechanism to anticipate or model the tail risk.** Catastrophe-correlation blindness is not an agentic-mechanism failure like retrieval mismatch or handoff loss; it is an actuarial assumption failure baked into the model's core logic. The agent treats catastrophe risk as background noise or a low-probability tail event, rather than provisioning for scenarios where nearly all claims in a region correlate and activate simultaneously. A separate goal, [Claim Processing](https://github.com/sarkars/agent-failure-modes/tree/main/agents/by-use-case/insurance/goals/claim-processing/), documents three different, agentic-mechanism failures in the per-claim adjudication pipeline; claims-processing documents a single, fundamentally different failure in the reserves-calculation pipeline. 1 patterns Error Propagation **One agent's error amplifies across a multi-agent pipeline because each downstream agent treats the previous agent's output as ground truth rather than an uncertain input to verify, so a 5% error at the first stage compounds into 17x-20x amplification by the final output.** The pipeline never fails cleanly — every intermediate agent reports high confidence, and disabling one agent in the chain can actually improve overall system reliability, which is the tell that the architecture itself is the problem, not any single agent's capability. 1 patterns Handoff Reliability **A multi-agent handoff loses the upstream agent's confidence signal because the handoff schema is designed to carry only a final value and a status flag, not the confidence level or methodology the upstream agent expressed in its free-text reasoning — so a downstream agent consumes a value the upstream agent explicitly flagged as low-confidence or in need of specialist review with full, unwarranted confidence.** The gap is structural: the confidence exists in the upstream agent's transcript, but the schema between agents has no field for it, so the information is invisible to any system that only reads the structured handoff record. 1 patterns Knowledge Staleness **Agents with access to live lookup tools default to stale training-era knowledge instead of querying the tools — when policies, rules, thresholds, or regulatory requirements change after the model's training cutoff, the agent applies outdated values and makes incorrect decisions.** The failure is invisible until downstream systems or compliance audits surface the discrepancy, at which point the incorrect decision has already propagated to customers, regulators, or business processes. 1 patterns Output Verification **Agents perform "verification" by re-querying the same upstream data source that provided the initial answer, so when the upstream source is stale, corrupted, or incorrect, re-querying returns the same wrong value — the agent reports "verified correct" with false confidence, and downstream systems trust the verified output and propagate the error.** True verification requires an independent data source; circular validation only confirms consistency, not correctness. 1 patterns Proactive Retention Outreach **Proactive retention outreach fails when a retention agent reaches out to an at-risk customer with a fabricated usage-decline narrative to justify the outreach, because a tool call to fetch actual usage data returned empty or errored.** This is a single, focused failure pattern: the agent has a reason to believe an account is at risk (a churn-prediction model flagged it), but lacks the specific usage insight needed to personalize the outreach, and fills that gap by composing plausible-sounding justification rather than using a generic fallback. The customer, whose usage data is missing or unavailable, gets an inaccurate personalized message, which undercuts the credibility of the save conversation before it starts. 1 patterns Retrieval Relevance **Retrieval relevance fails when an agent selects a comparable or reference item using text-embedding similarity alone, and the selected item matches on language but not on the structured attributes (category, jurisdiction, tier, part specification) that actually determine whether it's a valid comparison.** The single documented pattern here, semantic-similarity-retrieval-misses-structural-attributes, shows the mismatch concentrating on items with generic or sparse text descriptions, since a thin description gives the embedding little signal beyond surface topic match — exactly the cases where structural verification matters most and is least likely to happen. 1 patterns