Failure Mode

When a Pre-Trade Risk-Check Tool Call Times Out or Returns a Transport-Level Error Instead of a Structured Response, the Agent's Next Reasoning Step Generates a Schema-Conforming Risk-Check Result From Its Own Expectations of What the Tool Usually Returns, and Proceeds as if the Call Had Succeeded

Ticket-Routing Agent Determines Which Product Line a Ticket Belongs to Based on Whatever Product Name Was Most Recently Mentioned in the Conversation, Rather Than Querying the Customer's Actual Purchase/Entitlement Record

When a Single Ticket Contains Multiple Distinct Requests, the Routing Agent Classifies and Routes on the First or Most Prominent Intent Only, Silently Failing to Route or Flag a Secondary Issue Mentioned Later in the Same Message

A Hard Constraint the Client States Early in a Long, Multi-Turn Advisory Session (e.g., "No Fossil-Fuel Holdings," "No Leveraged Products") Falls Outside the Model's Effective Context Window by the Time a Later-Turn Recommendation Is Generated, and the Agent Recommends a Security That Violates It Without Re-Checking Against the Original Constraint List

An Advisor-Facing Agent That Processes Multiple Clients Within a Single Continuous Session Carries a Computed Suitability Parameter (Risk Tolerance, Tax Bracket, Liquidity Need) From One Client Forward Into Its Reasoning for the Next Client, Without Any Literal Data From the First Client Appearing in the Second Client's Output

After a Trading Venue Renames a Field in Its Order-Routing API Response (e.g., `available_qty` to `remaining_quantity`), an Agent Consuming the Response Maps the New Field to the Old Expected Key by Semantic/Fuzzy Similarity Rather Than Failing Loudly, Silently Misreading a Different Field as the Quantity Value

When a Security's ISIN/CUSIP Is Absent or Malformed in the Reference-Data Feed, an Agent Tasked With Enriching Trade or Position Records Generates a Plausible-Looking Identifier by Pattern-Completing From the Security's Name and Exchange, Instead of Flagging the Record as Unresolved

An Agent Given an Explicit, Durable Client Constraint Infers a Broader or Conflicting Preference From the Client's Transaction History During Multi-Step Recommendation Generation and Silently Supersedes the Explicit Constraint Instead of Flagging the Conflict

When an Agent Is Used to Canonicalize Free-Text Counterparty or Issuer Names Into a Standard Form, Its Generative Rewriting Silently Drops or Alters a Legal-Entity Suffix (Ltd, LLC, GmbH, Inc, N.V.) That Materially Changes Which Legal Entity — and Therefore Which Counterparty-Risk Profile — the Record Refers To

Self-Service Deflection Agent Generates a Fluent, Assertive Answer From a Weakly-Matched Retrieved Article, Instead of Hedging or Routing to a Human When the Retrieval Similarity Score Is Low

When a Single Customer Message Contains Several Distinct Issues of Varying Severity, the Sentiment-Escalation Agent Scores Overall Message Sentiment as a Blend, Diluting a Severe Complaint That Would Have Triggered Escalation on Its Own

An Agent Computing Net Asset Value Through a Multi-Hop Sequence of Tool Calls Re-Types the Intermediate Numeric Result as Text Between Steps Instead of Passing the Exact Value Forward, Introducing Rounding and Truncation Drift That Compounds Across the Chain

An Agent Resolving a Margin Call Through a Multi-Step Tool-Calling Sequence Continues Reasoning About Remaining Liquidation Needs Using the Account Equity and Margin-Usage Figures It Read Before Its Own Preceding Sell Order Executed, Rather Than Re-Fetching Current State After Its Own Action Changed It

Agent Closes a Support Ticket as Resolved Because the Customer's Reply Contains a Polite Closing Phrase ("Thanks," "OK," "Got it"), Without Verifying the Underlying Problem Was Actually Fixed

After Autonomously Executing or Recommending a Trade, an Agent Asked to Produce the Compliance/Suitability Rationale Selectively Retrieves and Surfaces Only the Evidence That Corroborates the Trade It Already Made, Omitting Contradicting Signals It Had Equal Access To

An Agent Given Autonomy to Draft Routine, Recurring Regulatory Filings (Quarterly Amendments, Periodic Disclosures) Uses Its Own Prior-Quarter Filing Output as a Template and Implicit Ground Truth for Consistency Checking, So a Factual Error Introduced in One Quarter Is Not Caught but Actively Re-Validated and Carried Forward in Every Subsequent Quarter

A Sanctions-Screening Tool Returns a Genuine Positive Match, but a Downstream Abstractive-Summarization Step — Written to Produce a Concise Case Summary for the Compliance Analyst — Paraphrases the Hit Into Vague, Non-Actionable Language That Reads as "No Significant Findings"

Model Cannot Reason About 3D Structure from Single 2D Image

ASR Performs Significantly Worse on Non-Standard Accents

An agent's tool permissions are computed by inheriting from a parent context — the invoking user's role, the calling service's credentials, or a parent agent's session — rather than being independently assigned. When the inheritance logic doesn't map cleanly (e.g., a support agent inherits an admin's broad scope because the admin happened to trigger the workflow, or a background job inherits a service account's org-wide scope instead of the specific user's narrower one), the agent ends up with either far more access than the task requires or, less often, too little to complete legitimate work.

In a multi-tenant SaaS product, a tool call made on behalf of one customer account is scoped using the wrong tenant/account identifier, causing the agent to read or write data belonging to a different customer entirely. This typically happens when the account ID is derived from a stale cache, a URL/session parameter that wasn't re-validated, or a default value used when the true tenant context is missing from the request.

An agent relies on a tool that advertises a specific accuracy figure for an ML-based capability — an entity-extraction API claiming 95% precision, a classification model claiming 90% F1 — and treats results as trustworthy at that advertised rate. In production, real-world accuracy often falls short of the marketed number because vendor benchmarks are measured on curated test sets that don't reflect the agent's actual input distribution. The agent, having no independent accuracy monitoring, keeps trusting outputs at the assumed rate and propagates a higher error rate downstream than anyone accounted for.

Agent Narrates a Tool-Initiated Action as Complete Based on Having Issued the Call, Not on the Call's Actual Returned Status

Some tool vendors don't publish a fixed rate limit at all — instead they throttle dynamically based on backend load, shedding traffic more aggressively during peak hours or incident windows. An agent that learned "this API allows ~50 requests/minute" from yesterday's behavior has no way to know that the vendor has silently tightened the effective limit to 10 requests/minute right now, so it keeps firing at its old cadence and racks up a string of 429s it can't explain.

AI System Fails to Trace Address Consistency Across Document Timeline

OCR System Fails to Standardize or Match Addresses Across Documents

An agent exposes admin-tier tool operations (e.g. `delete_user`, `override_billing`, `reset_org_settings`) through the same tool-calling interface as ordinary operations, and the dispatch layer invokes them without first checking whether the requesting user actually holds an admin role. Any user who can phrase a prompt that maps to the admin tool schema gets the admin code path executed with the agent's (often elevated) service credentials.

Model Misclassifies Images Modified by Small Adversarial Perturbations (Imperceptible to Human)

Model Misinterprets Symptoms Differently Based on Patient Age; Younger Patients Undertreated, Older Patients Overtreated

The agent's own error-recovery step corrects a value that wasn't actually wrong, corrupting good data to satisfy a validation check

A Pipeline-Forecasting Agent Computes Weighted-Pipeline Totals Using a Stage-to-Probability Weighting Scheme It Recalls From Earlier in Its Training or From an Older Cached Session, Rather Than Calling the Live Forecasting-Configuration Tool That Returns the Currently Active Weighting Scheme After RevOps Updated It, Producing a Forecast That Reflects a Retired Methodology

A Lead-Scoring Agent, When Asked to Explain or Compute a Lead's Score, Falls Back on a Generic Firmographic-Weighting Heuristic Resembling Common Industry Lead-Scoring Conventions It Absorbed During Pretraining (e.g., "Company Size and Title Seniority Are Typically Weighted Most Heavily") Rather Than Calling the Company's Live Scoring-Rules Tool, Which Reflects a Recently Updated Weighting Scheme That Down-Weights Company Size in Favor of a Recent Intent-Signal Category the Marketing Team Just Promoted, Producing a Score and Explanation That No Longer Match What the Company's Actual Current Rules Would Produce

Agent Extracts Fields Using a Schema That Doesn't Match the Document's Template Version

Agent Misclassifies Documents That Share Near-Identical Layouts

Agent has access to live lookup tool that returns current reference data (policy, rules, calendar, threshold), but defaults to stale training-time knowledge instead of calling/trusting the tool; downstream decisions use outdated values

A Quota-Achievement Agent Asked Whether a Rep's Quota-Relief Exception (Such as a Territory Disruption Credit or a Ramp-Period Adjustment) Was Approved Calls the Approvals-Tracking Tool, Receives an Empty Result Because the Exception Was Never Actually Submitted Through the Formal Approval Workflow, and Instead of Reporting That No Approval Record Exists, States That the Exception Was Approved by the Rep's Manager on a Specific Date, Causing the Rep's Quota Attainment to Be Calculated as if Relief Had Been Granted When It Had Not

A Lead-Scoring Agent Asked to Factor In a Prospect's Most Recent Discovery-Call Sentiment Calls the Call-Transcript Retrieval Tool, Receives an Empty or Null Result Because the Call Was Never Transcribed or the Transcript Has Not Yet Synced, and Instead of Reporting That No Transcript Data Is Available, Fills the Gap With a Plausible-Sounding but Entirely Fabricated Summary of Objections and Sentiment That Lowers the Lead's Score

When one agent hands off a task to another (e.g. a triage agent passing a ticket to a specialist agent), both agents briefly believe they may be responsible for the same unit of work. If the handoff isn't atomic — the sender marks the task "handed off" in one write and the receiver marks it "claimed" in a separate write — a narrow window opens where either both agents act on the task simultaneously, or neither does because each assumes the other has it. The failure is timing-dependent and often invisible in single-agent testing, only surfacing under concurrent load.

Malicious Entity Poses as Trusted Agent in Multi-Agent System

Malicious Agent Introduction

Agents Pursue Conflicting Objectives

Agent Swallows Attachments and Embedded Documents Into the Parent Document's Classification

The same field appears in multiple document locations with conflicting values, and the agent grabs the first or an arbitrary occurrence instead of the authoritative one

A low-priority agent acquires a shared resource (a database lock, a rate-limited API slot, a write lease on a document) and then stalls or runs slowly, while a high-priority agent that needs the same resource is forced to wait behind it. The high-priority agent's own urgency provides no mechanism to preempt the lower-priority holder, so the system's effective priority order is inverted: the task that matters least is dictating the pace of the task that matters most.

Quality Filter Rejects Readable Documents as "Unreadable"

Multiple agents operating concurrently compete for the same limited resource — a shared LLM inference quota, a database connection pool, a third-party API's rate limit, or a GPU worker pool — and none of them individually has enough context to know how much of the resource other agents are currently consuming. As contention rises, every agent's individual performance degrades (higher latency, more throttling, more retries), and the degradation compounds because retries themselves consume more of the scarce resource, pushing the system further from recovery.

Agent Claims It Will Perform Actions Beyond Its Capabilities

Attacker Takes Control of Active AI Agent Session

Two or more agents that are supposed to maintain a shared view of the world — the current status of a task, a customer's conversation context, an inventory count — drift out of sync because their state-synchronization mechanism silently fails or falls behind. Each agent keeps acting confidently on its own local copy, and because no single agent has a global view, the divergence goes undetected until the agents' outputs visibly contradict each other or a downstream system receives conflicting updates.

One agent in a multi-agent pipeline runs slow or hangs, and its caller times out and gives up waiting on it. Because that caller is itself being awaited by another agent upstream, its own timeout consumes most of the upstream agent's remaining budget, and the pattern repeats up the chain — each layer's timeout firing shortly before the one above it, so a single slow agent deep in the pipeline produces a wave of timeouts that appears to hit the entire system simultaneously.

The agent resolves an ambiguous or partial identifier to the wrong record and acts on the wrong account, order, file, or user.

Agents disagree on who has final say, and the system silently picks a winner instead of resolving the conflict. This is common in flat multi-agent orchestration (e.g., LangGraph or CrewAI-style peer topologies) where no agent is declared authoritative for a given decision domain.

The agent mistranslates its own document understanding into tool call parameters, silently extracting from the wrong page or region

An early agent's mistake gets treated as ground truth by every downstream agent, so a small error compounds into a badly wrong final answer as it propagates through the pipeline.

Agents appear to agree, but only because they were all seeded from the same flawed context or bias -- not because they independently verified the answer.

The manager/orchestrator agent (the coordinator role in LangGraph supervisor graphs or CrewAI's manager pattern) assigns subtasks to the wrong worker agents, or fails to correctly synthesize their outputs into a coherent final answer.

The agent retries a write-type tool call after a timeout or ambiguous error and ends up creating duplicate tickets, emails, orders, or charges.

The agent decides a case that should have gone to a human or domain expert, with no abstention or escalation trigger firing.

The agent executes a delete, send, payment, or deployment without approval, because the action carries no reversibility classification requiring a confirmation gate.

The agent extracts a wrong amount, date, name, address, account number, or ID and nothing catches it before use.

The agent struggles on free-form correspondence and narrative documents where key information isn't in a labeled field

Long documents exceed the agent's context window, so naive chunking breaks cross-references and the agent loses track of earlier content

The agent enforces policy to the letter and gets a technically correct answer that is commercially wrong.

An upstream agent flags low confidence or ambiguity in its free-text reasoning, but the structured handoff schema passed to the downstream agent -- a common MCP/tool-call handoff pattern -- carries only the final value and status. The confidence/provenance signal is invisible to the downstream agent, which uses the value with full confidence.

The agent promises a refund, waiver, legal/commercial term, or SLA it has no authority to honor.

A receiving agent misreads or misparses another agent's output, so its downstream action contradicts what the upstream agent actually produced.

The agent misclassifies a paystub, W-2, bank statement, invoice, policy, or similar document, so the wrong extraction schema gets applied.

The agent treats a critical issue as minor, or a minor issue as critical, because its severity rubric relies on loose judgment instead of hard triggers.

The agent mishandles empathy in debt collection, healthcare, support, or complaints and gives a procedurally correct but tone-deaf reply.

The agent misses a regulatory limit, filing deadline, eligibility rule, or other compliance trigger because it wasn't checked in real time.

The agent applies the general-case policy and misses an industry-specific rule or exception, producing a wrong decision.

The agent performs an action no one actually authorized, because its service credentials are over-scoped and no runtime check confirms the action matches the session's authorization.

The agent's reasoning chain is logically sound, but it operates on a misread input value, so the final answer is wrong despite correct reasoning

Agents don't have a clear, non-overlapping definition of who owns which responsibility, so work gets duplicated in some areas and dropped entirely in others.

The agent gets stuck retrying the same failing action with no retry cap, backoff, or action budget, until quota, cost, or damage accumulates.

An agent hands off incomplete or incorrect state to the next agent in the pipeline -- a common failure in LangGraph/CrewAI-style handoffs -- so the downstream agent works from a gap it doesn't know exists.

The agent answers from OCR- or RAG-retrieved text when the live database or source document should have won.

A specialized worker agent optimizes its own subtask metric so hard that it ignores or overrides the global plan, so the overall task fails even though each agent's local output looks fine.

Multiple agents independently solve the same subtask -- often calling the same expensive tool or API -- because there's no shared task ledger to prevent redundant work.

Two or more agents disagree and nothing in the pipeline resolves the conflict, so contradictory answers reach the end user or downstream system.

Multiple independent agents reach the same wrong conclusion, and the system mistakes that agreement for a confidence signal -- escalating the decision to production because all agents making the identical mistake looks like verification, not error.

Agents converge on an answer and stop before gathering enough evidence, so the group agrees quickly but on a weakly supported conclusion.

Critic and reviser agents -- a common pattern in LangGraph reflection loops -- keep critiquing and revising each other's work endlessly, with no termination condition to stop once the debate stops making progress.

Agent Mishandles Questions About Being AI/Bot

Input Quality Gap — Real Documents Are Messier Than Benchmark Documents

Attribute Hallucination — Model Reads the Right Field but the Wrong Value

Fabricated Content Not Grounded in Input

Performance Collapse Under Visual Noise

Extraction Guesses Wrong Without Sender, Locale, or Historical Context

Overconfident Wrong Answers — Model Confidence Doesn't Track Accuracy

Plausible but Wrong Outputs — Errors That Never Trip an Alarm

Batch Processing Timing Failures — Arrival Order Isn't Logical Order

Cell Omission and Merging — Empty Cells Cause Column Drift

Extracted Data Lands in the Wrong ERP Fields

Merged Cell and Nested Header Failures

Object Hallucination — Model Populates Fields the Document Never Contained

Relational Hallucination — Values Attached to the Wrong Header

Accuracy Regression Undetected — A Bad Deploy Ships Silently

A judge/verifier agent -- a pattern common to LLM-as-judge and OpenAI Agents SDK guardrail setups -- approves worker-agent output that is actually wrong, because it's checking surface plausibility rather than verifying against ground truth.

Content-Generation Agent Publishes AI-Drafted Marketing Content Without the Disclosure Labeling Required Under Applicable Advertising Regulations or Platform Policies, Exposing the Business to Regulatory and Platform-Enforcement Risk

AI Fraud Detection Fails to Identify Documents Created with Generative AI Tools

Agent Auto-Tunes Anomaly Detection Thresholds to Minimize False Positives on Historical Data, Inadvertently Suppressing Sensitivity to Genuinely Novel Incident Patterns

AI System Systematically Discriminates Against Protected Groups

Agent Guesses Instead of Clarifying Ambiguous Queries

Agent optimizes for a different meaning of the user's/business goal.

Agent Fixates on the First Plausible Diagnosis Suggested Early in the Conversation and Discounts Later Contradictory Evidence

Correct information is retrieved but summarized incorrectly.

Answer Doesn't Address the Actual Question

An agent authenticates to a tool using a shared account-level API key, and that key's quota (requests/minute, tokens/day, credits/month) is pooled across every consumer that happens to use it — other agents, human users, cron jobs, and staging environments. The agent has no visibility into who else is drawing down the same quota, so it plans its own call volume as if it owned the full allocation, then gets throttled or rejected by calls it never made.

An agent was built and tested against a specific version of a tool's API schema — field names, types, nesting structure, enum values. When the tool vendor ships a new API version with a changed schema (a renamed field, a restructured nested object, a stricter enum), and the agent's requests still get routed there (via a default-version endpoint, an auto-upgraded SDK, or an account migration), the agent's parsing logic silently misreads or drops fields instead of failing loudly, producing corrupted downstream state rather than a clear error.

AI QC System Fails to Detect Appraisal Inconsistencies That Trigger GSE Findings

An agent submits an approval request that exceeds the current approver's authority limit (e.g., a spend amount, a data-access scope, or a risk tier above what that role can sign off on). The workflow is supposed to automatically route the request to a higher-authority approver, but the escalation path fails silently — the request sits in the original approver's queue indefinitely, gets auto-approved because the "requires escalation" flag was never checked, or gets auto-rejected because the escalation target couldn't be resolved.

A multi-step approval chain (for example, manager approves, then finance reviews, then compliance signs off) breaks partway through because one link in the chain fails to forward the request to the next stage. The agent or workflow engine has already recorded the completed steps as "approved," creating the appearance of forward progress, but the request never actually reaches the remaining approvers and simply goes cold in an intermediate state.

An action requires sign-off from two or more independent approvers, and they issue conflicting decisions — one approves, another rejects. The approval system has no defined resolution rule for this case, so the agent falls back to undefined behavior: proceeding because "at least one approval" was recorded, blocking because "any rejection" wins, or simply acting on whichever decision was recorded last (last-write-wins), none of which reflects an actual governance policy.

An approver who is unavailable delegates their approval authority to another approver, who in turn delegates back to the original approver (or to a third party who delegates further, forming a longer cycle). The delegation graph has no cycle detection, so the request bounces indefinitely between the delegated parties, or the workflow engine detects the loop only after it has already re-notified the same approvers dozens of times.

Too Many Pending Approvals Cause Delays or Dropped Requests

An approver grants approval for a specific, narrowly-scoped action, but the agent executes something broader or materially different from what was approved, then cites the original approval as its authorization. The gap between what was approved and what was executed goes undetected because the system checks only "does an approval exist" rather than "does this specific action match the approved scope."

A high-risk action (fund transfer, policy override, data export) is gated behind a requirement that a human approver's cryptographic signature or signed token accompany the execution request. The agent's verification of that signature is incomplete — it checks presence of a token rather than validity, uses a weak or non-constant-time comparison, doesn't bind the signature to the specific action payload, or doesn't check expiry/single-use — so a forged, replayed, or mismatched approval is accepted as genuine.

An approval request times out because no approver responds within the configured window, and the agent's downstream behavior on timeout is either undefined or set to fail-open: the action proceeds automatically as if approved, or the requester and approvers are never clearly told that the timeout occurred and what happened as a result. Either way, a control that was supposed to require an affirmative human decision ends up producing an outcome no human actually made.

Agent Behaves Incorrectly When Human Approval Times Out

An emergency waiver mechanism, designed to let an agent bypass the normal approval process under genuinely urgent conditions (an active outage, a security incident), gets invoked repeatedly for routine, non-urgent actions because it is faster and has less friction than the real approval path. Over time this erodes the approval control entirely: the "emergency" path becomes the default path, and the actions it was meant to gate no longer receive meaningful human review.

OCR System Incorrectly Extracts or Validates APR Calculations

Many tool APIs cap the number of elements allowed in a specific array field of a single request — for example a maximum of 500 line items per invoice-creation call, or 1,000 IDs per bulk-lookup request. When an agent assembles this array dynamically (aggregating results from a prior tool call, paginated upstream source, or a loop that accumulates records), it frequently has no visibility into the cap until the call fails or, worse, the API silently truncates the array and returns success. The agent then proceeds as if all elements were processed, producing incomplete work that looks complete.

Repeated Generation/Regeneration of Same Content Introduces Synthetic Artifacts

AI System Fails to Trace Assets to Legitimate Sources

OCR System Incorrectly Extracts or Validates Borrower Assets

The agent infers an unstated detail about what the user wants — a default value, a scope boundary, an intended recipient, a file format — and proceeds to act on that inference as if it were confirmed, instead of surfacing it as a guess. The user only discovers the assumption was wrong after seeing the output, at which point work has to be redone. This differs from under-clarification in that the agent isn't skipping an ambiguous request wholesale; it silently resolves one specific unstated variable inside an otherwise clear request and never tells the user it made a choice.

Vision Model Detects Incorrect Attributes of Existing Objects

Employees Flagged as High Attrition-Risk by the Retention-Prediction Model Are Systematically Deprioritized for Growth Opportunities, Stretch Assignments, and Promotion Consideration by Managers Aware of the Score, Causing the Flagged Employees to Actually Leave at Higher Rates as a Consequence of the Flag Itself

Model Trained Predominantly on "Textbook" Symptom Presentations Misses Atypical Presentations Common in Women, Elderly, and Diverse Populations

TTS Produces Clicks, Pops, Distortion, or Other Audio Artifacts

Poor Audio Quality from Network or Device Issues

Agent Actions Not Properly Logged or Traceable

An agent's tool calls and decisions are written to an audit log intended to provide an immutable record for compliance and incident review, but the log store itself is a regular, mutable database table or file that the agent's own service credentials (or a compromised/buggy code path) can write to, update, or delete. A misbehaving agent, a bug in a "cleanup" routine, or an attacker who compromises the agent's environment can alter or erase the very record meant to catch that misbehavior.

Policy requires that certain tool calls — anything that reads sensitive data, anything that mutates state, anything crossing a compliance boundary — be recorded in an audit log. In practice, the logging call is implemented as a best-effort side effect inside each tool handler (or worse, left to individual developers to remember to add), rather than as a mandatory step enforced at the tool-dispatch boundary. When the logging call fails, times out, is skipped by an exception path, or is simply never added to a new tool, the action still executes and no record is created.

Regulatory or internal policy requires audit logs of agent tool activity to be retained for a defined period (e.g. seven years for financial records, a shorter window for other categories), but the actual log storage system rotates, compresses-and-discards, or hard-deletes entries on a default retention schedule that's shorter than policy requires — often because the logging infrastructure's default retention setting was never explicitly reconfigured to match the compliance requirement.

Wrong Person Approves Action

AI-Controlled Physical Systems Cause Harm

Agent-Driven Autoscaler Repeatedly Scales Up and Down in Short Cycles Because Scaling Decisions React to Instantaneous Metrics Without Accounting for Provisioning Lag

Agent's Acknowledgment Cues ("uh-huh", "right") Occur at Wrong Moments

ASR Accuracy Degrades Significantly in Noisy Environments

Many APIs specify an expected retry envelope for failed requests — a minimum delay before retrying (to avoid hammering a recovering service) and a maximum delay (beyond which the server considers the client "gone" and drops queued state, such as an idempotency reservation or a rate-limit grace window). An agent's retry logic, especially generic exponential-backoff code reused across many tools, frequently ignores tool-specific envelope hints (a `Retry-After` header, a documented min/max, or a jittered range) and either retries too fast — getting throttled harder or banned — or waits too long — missing a narrow retry window and losing queued work or an idempotency token.

Agent asks unnecessary questions or misses critical clarifications.

Agent refuses safe requests or gives unsafe help.

Agent splits the task into wrong subtasks, causing missed work.

OCR System Incorrectly Extracts Data from Bank Statements

AI System Fails to Detect When Visible Text Doesn't Match Encoded Barcode Data

User Cannot Interrupt Agent's Speech

An inference serving layer batches requests to amortize fixed per-request overhead (kernel launch, KV-cache setup, attention computation) across GPU-seconds, but the batching strategy itself wastes money — fixed-size batches get padded with empty slots when traffic doesn't fill them, a batch window that's too short forces many small batches instead of one efficient large one, or a window that's too long holds cheap requests hostage waiting for a batch to fill while GPUs idle. The result is that the same workload costs meaningfully more per token than a well-tuned batching policy would produce.

Processing Items Individually When Batching Would Be More Efficient

Bulk-operation tools commonly enforce a maximum number of operations (rows, records, actions) per batch request, distinct from any single-field array cap — for instance a max of 200 records per bulk-import call or 100 messages per batch-send. Agents that build a batch from dynamic upstream data (a database query, a paginated feed, a fan-out from a previous step) often assemble the request first and only discover the limit when the call is rejected outright, because nothing in the agent's planning path checks the batch's total size against the tool's documented ceiling before dispatch.

Beyond the size limit on any single batch, many tools also enforce an aggregate cap on total operations across a rolling window — for example, no more than 10,000 record writes per hour regardless of how they're split across individual batch calls. An agent that correctly chunks each batch to stay under the per-call limit can still violate this rolling aggregate cap if it fires many compliant batches in quick succession, because per-call compliance says nothing about cumulative volume over time. The agent's batching strategy solves the wrong constraint and the job fails partway through with no signal that the two limits are independent.

Request Batching Adds Unacceptable Wait Time

AI System Fails to Detect Fraud Signals in Application Behavior Patterns

Model Optimizes Against a Generic Benchmark That Does Not Match the Client's Actual Risk Profile, Goals, or Constraints

Sales forecasting model uses deal probability from salesperson input, which is inherently optimistic; projects deals that salesperson hopes will close rather than actual likelihood

An agent depends on a tool capability explicitly marked beta, preview, or experimental. Because beta features carry no stability guarantee, the vendor can change their behavior, response format, or accuracy characteristics between releases — or pull the feature entirely — without the deprecation notice period given to generally-available (GA) functionality. The agent, having no built-in concept of "this dependency is inherently unstable," treats the beta feature the same as any GA capability and has no fallback when it changes shape or disappears.

Agent Amplifies and Reinforces User Biases

Internal Cost Tracking Doesn't Match Vendor Invoices

Agent Classifies Blank or Near-Blank Pages as Real Documents

Agents Delegate Tasks Without Verifying Delegate Capabilities or Trustworthiness

Critical Failures Occur in Unmonitored Agent Code Paths

Slow Tool Calls Block All Other Operations

An agent orchestration platform deploys a new agent version (updated system prompt, tool schema, or model pointer) to a fully provisioned "green" environment alongside the running "blue" environment, but the load balancer or service mesh routing rule that should cut traffic over to green never actually flips. The green fleet passes its smoke tests, health checks report healthy, and the deployment pipeline marks the release as "complete," yet 100% of live agent sessions continue to be served by the stale blue version. The team believes the new version is live — including any urgent fix it was supposed to carry — while users keep hitting the old behavior.

Agent Drafts a New Contract by Inserting a Standard Boilerplate Clause Library Entry That Is Inconsistent With Deal-Specific Terms Negotiated Elsewhere in the Same Document

Inaccurate Object Localization; Bounding Boxes Don't Match Actual Object Boundaries

TTS Mispronounces Brand Names, Domain Terms, or Key Phrases

Citations Link to Unavailable or Moved Content

Agent Exceeds Budget Limits Without Being Stopped

An agent operating under a fixed tool-spend cap (e.g. $50/day across a web-search API, an enrichment API, and a document-generation API) has no concept of which calls matter most. It burns the budget on early, low-value exploratory calls — re-querying the same search API with slight prompt variations, or calling an enrichment tool on leads that were already disqualified — and then has nothing left when a high-value call (verifying a contract term before it's sent to a customer) is needed later in the same session.

Small Demand Variation at Retail Cascades to Large Forecast Errors Upstream; Overproduction/Underproduction at Manufacturing

Agent completes a technical action that violates company policy.

One agent in a multi-agent system starts producing output that is not simply wrong or absent but actively inconsistent, contradictory, or adversarial-looking — different answers to different peers about the same fact, plausible-sounding but fabricated tool results, or outputs crafted (whether by a prompt-injection attack, a corrupted model checkpoint, or a bug) to pass superficial validation while being substantively false. Because the failure doesn't look like a crash or a timeout, the other agents in the system have no clean signal to detect it, and they can be individually convinced by output that appears locally reasonable.

Redundant LLM Calls for Identical or Similar Requests

Agent Fails to Handle Mid-Call Disconnections Gracefully

Agent Approves a Canary Deployment as Healthy Based on Aggregate Metrics That Mask a Regression Affecting a Specific Traffic Segment

An agent platform starts a canary rollout of a new agent version — routing a small percentage of live sessions (e.g., 5%) to the new build while the rest continue on the stable version — but the automated or manual promotion process that should ramp the canary from 5% to 100% never completes. The rollout stalls at some intermediate weight indefinitely, sometimes for days or weeks, because the metrics that gate promotion never clearly pass or fail, or because the person/process responsible for the next promotion step loses track of the release. Production ends up permanently running two agent versions side by side, with users nondeterministically getting different behavior depending on which version their session lands on.

Agent Selects a Templated/Canned Response That Matches Surface Keywords but Misses the Customer's Actual Situation

Agents Claim Capabilities They Don't Actually Have

Agent Regenerates the Care Plan at Each Visit From the Current Problem List Alone, Losing Continuity With Previously Agreed Patient Goals

Agent Optimizes Shipping Routes for Cost and Transit Time Using Carrier Capacity Assumptions That Are Stale Relative to Real-Time Constraints

An agentic system experiences a small, low-severity failure in one component — a single slow dependency, a handful of dropped requests, a brief queue backup — and instead of staying proportionate, the failure grows in magnitude as it propagates through downstream components. Each hop adds retries, duplicate work, or overcorrection, so a fault that started as a 2% error rate in one service arrives at the edge of the system as a full outage. The agent-specific twist is that autonomous retry loops and multi-step planning amplify faster than in traditional systems, because an agent facing a transient tool failure often retries the entire multi-step plan rather than the single failed call.

A single triggering failure fans out into multiple independent cascades across unrelated subsystems, rather than propagating along one dependency chain. This happens when the failing component is a shared dependency consumed by several otherwise-independent subsystems (a shared auth service, a shared vector store, a shared message bus), so the initial fault triggers parallel, uncoordinated cascades that each unfold on their own timeline and are handled by different on-call teams who have no visibility into each other's incident. Unlike a single deepening cascade, branching multiplies the number of simultaneous incidents an organization has to manage at once.

A cascading failure that originates from a single root cause and propagates through several dependent components is not recognized as one incident. Instead, monitoring and on-call responders see a series of alerts from different services and open separate tickets, each investigated independently as if unrelated. Because no one is looking at the whole picture, responders spend time fixing symptoms in each affected service without ever addressing the shared trigger, and the incident often "resolves" temporarily in one place only to resurface in another minutes later.

After a cascading failure hits several components, each component recovers independently — resuming from its own local checkpoint, cache, or retry queue — without coordinating with the others on what the "true" post-incident state should be. The result is that components which were consistent before the cascade come back online in mutually inconsistent or conflicting states: one service thinks an order is confirmed, another thinks it was cancelled, and a third has no record of it at all. This is distinct from a single component failing to recover correctly; the problem is specifically that multiple components recover to different, incompatible versions of the truth.

A system has bulkheads in place — separate connection pools, separate thread pools, separate tenant shards, separate rate limits — intended to contain a failure to the subsystem where it originates. During an actual cascade, the isolation boundary turns out to be leaky: a shared resource that was assumed to be partitioned (a shared thread pool, a shared database instance, a shared upstream dependency, a shared control plane) is in fact common to both the failing subsystem and the ones meant to be protected, so the failure crosses the boundary anyway. The bulkhead exists on paper and in the architecture diagram, but not in the actual runtime resource graph.

The very mechanisms deployed to make a system resilient — retries, circuit breakers, health-check-triggered auto-restarts, failover — become active contributors to a cascading failure instead of containing it. A retry policy that seemed reasonable in isolation adds load to an already-struggling dependency; a circuit breaker's half-open probe traffic re-triggers the failure it just tripped on; an auto-restart policy cycles a struggling instance in a tight loop that never lets it recover. This pattern is specifically about resilience infrastructure making things worse, distinct from cascade-amplification (which is about magnitude growth generally) and cascade-timeout-interaction (which is about timeout settings specifically).

Different layers in a call chain are configured with timeout values that were each set reasonably in isolation but interact badly when combined, actively amplifying a cascade instead of bounding it. The classic bad pattern is an upstream timeout that is shorter than or too close to a downstream timeout, so the caller gives up and retries while the original call is still in flight and still consuming resources on the downstream system — doubling load without reducing it. This is a distinct, specific mechanism from general cascade-amplification: the trigger here is specifically the numeric relationship between timeout values at different layers, not retry policy or resilience-mechanism design broadly.

An agent's tool chain includes multiple tools that, unknown to the agent's error-handling logic, share a common downstream external dependency. When that shared dependency has an outage, every tool built on top of it fails simultaneously, and the agent — which was designed to handle each tool's failure independently, perhaps with per-tool fallbacks — finds that its fallback options are also unavailable because they depend on the same failed upstream service, leaving it with no working path forward.

Sequential Agent Calls Create Unacceptable End-to-End Latency

Catastrophe risk model assumes independent claims; hurricane hits coast, model hadn't provisioned for 10k simultaneous claims; reserve exhausted within days

An Onboarding Agent Successfully Extracts a Certification Number, Issuing Body, and Expiry Date From a Supplier's Uploaded Document and Approves the Supplier as Certified, Without Calling the Available Issuing-Authority Lookup Tool to Confirm the Certificate Is Real, Unrevoked, and Current

Agent Reviewing a Target Company's Contract Portfolio for M&A Due Diligence Fails to Flag Change-of-Control Provisions That Trigger on the Transaction Itself

Self-Service Deflection Agent Keeps Offering the Same or Similar Automated Suggestions Without Recognizing the Customer Needs Human Escalation

Users Trick Chatbots Into Harmful Actions or Statements

Model Selectively Uses Supporting Evidence, Ignores Contradicting

Model Fails to Properly Interpret Choice-of-Law Clauses; Applies Wrong Jurisdiction's Laws to Obligations

Needed fact is split across chunks and lost.

Relevant Information Split Across Chunks

A circuit breaker sitting in front of an agent's backend (the LLM inference endpoint, a tool API, or an internal microservice the agent calls) trips open in response to a short burst of transient errors — a brief upstream GC pause, a single overloaded pod, a momentary network blip — rather than a genuine sustained outage. Once open, the breaker rejects all subsequent calls for its full cooldown period regardless of whether the underlying service has already recovered, so a two-second blip turns into a 30-60 second window where every agent session fails over to a degraded fallback or errors outright, even though the dependency was healthy again within a couple of retries.

Legal Research Agent Cites a Precedent as Settled Law Without Flagging That a Circuit Split (or Equivalent Jurisdictional Disagreement) Exists, Leading to a Brief That Misrepresents the Strength of the Authority

Self-Service Deflection Agent Routes a Customer Through a Closed Loop of FAQ Articles That Each Point Back to One Another, Never Reaching a Resolution or a Human Handoff

Cited Source Doesn't Actually Support the Claim Made

Agent cites a source that does not support the claim.

The agent correctly recognizes that a request is ambiguous and asks a clarifying question, but the question it asks targets the wrong axis of ambiguity — it doesn't actually narrow down the interpretation that matters. The user answers the question, the agent proceeds, and the output is still wrong because the real ambiguity was never resolved. This is distinct from over-clarification (asking when nothing needed clarifying) and under-clarification (not asking at all): here the agent's instinct to ask was correct, but its question-selection logic picked a low-information question over the high-information one.

The agent keeps asking clarifying questions turn after turn without ever committing to an interpretation and proceeding, even after the user has provided enough information to act, or has explicitly said to just make a decision. Each answer the user gives triggers a further question rather than progress, and the conversation never converges on output. This differs from clarification-irrelevant (a wrong single question) in that the loop never terminates at all — the failure is in the stopping condition, not the question content.

Cost-Optimization Agent Reports an Autonomous Resize or Termination as Successful Based on the Cloud API's Synchronous "Request Accepted" Response, Without Polling the Resource's Actual Post-Action State

AI System Incorrectly Attributes Data Between Borrower and Co-Borrower

First Request After Idle Has Unacceptable Delay

Agent passes unsafe user/tool input into shell/API commands.

Information Lost or Corrupted Between Agents

Model Recommends Treatment Optimal for Primary Condition But Dangerous for Comorbidities Patient Has

Memory Compaction Removes Critical Information

Agent Outputs Violate Regulatory Data Handling Requirements

Model Fails When Images Compressed (JPEG Artifacts); Accuracy Sensitive to Compression Quality

Context Summarization Loses Critical Information

A tool exposes a "computed" or derived field — one assembled on the fly by joining, aggregating, or inferring across multiple underlying sources (e.g., a `customer_risk_score`, `estimated_lifetime_value`, or `inferred_household_income` field) — but the field's metadata doesn't flag it as either sensitive or expensive to compute. Because the access-scoping layer typically makes decisions based on static field metadata (classification tags, cost annotations), an unflagged computed field slips through with no gate at all, and the agent queries it as freely as any plain stored column.

A sudden spike in concurrent inference requests — from a traffic burst, a retry storm, or an agent fan-out pattern that issues many parallel sub-calls — exhausts GPU memory, CPU, or connection-pool capacity faster than autoscaling or admission control can react. Instead of degrading gracefully, the serving layer either crashes (taking down in-flight requests and forcing expensive retries) or silently over-admits requests into an already-saturated batch, driving per-request latency and cost up simultaneously as the system thrashes rather than serves.

A tool's license agreement caps the number of simultaneous active sessions (e.g., a data-provider API allows 3 concurrent connections per account, a desktop-automation tool allows 1 active session per seat), but the agent architecture spins up multiple parallel task instances — sub-agents, worker threads, or concurrent user requests — that each open their own session against the same licensed tool without any shared awareness of how many sessions are already open. The N+1th session either gets rejected outright or, worse, silently kicks an existing session offline mid-task.

Multiple agents/users modify same object without coordination.

Two or more agent instances (or an agent and a background job) read the same piece of shared state — a task queue entry, a customer record, a conversation memory slot — modify their own in-memory copy, and write it back without any locking or optimistic-concurrency check. Whichever write lands last silently overwrites the other, so one agent's update disappears without either agent, or the user, ever being told a conflict occurred.

Many SaaS tools license access by concurrent "seats" or "sessions" rather than by request volume. When an agent authenticates as if it were a human user — holding a persistent session or logging in under a shared service account — it consumes one of those concurrent slots. This either locks the agent out when human users have filled the pool, or worse, silently evicts a human user's active session when the agent logs in and the license enforces a hard cap.

Some permissions are conditional on runtime state rather than static role membership — "allow withdrawal only if account balance exceeds the requested amount," "allow this API call only during business hours," "allow escalation only if the ticket is marked P1." The agent evaluates these conditions against stale, cached, or incorrectly fetched data, or implements the comparison logic incorrectly (off-by-one, wrong field, wrong currency/unit), and grants access that the live condition would have denied.

Agent's verbalized or scored confidence does not correlate with its actual answer correctness, so confidence cannot be used to gate downstream decisions.

Model Confidence Doesn't Match Answer Reliability

Model Confidence Doesn't Match Hallucination Probability

Agent States False Information with High Confidence

Agent Anchors on a Prior Visit's Diagnosis and Discounts New Evidence Contradicting It

Different reviewers prefer different behaviors.

Agent Receives Contradictory Instructions

Agent cannot resolve tradeoffs like speed vs accuracy, helpfulness vs compliance.

Agent fails to reconcile contradictions between sources.

When an old agent-serving instance is terminated during a deployment, the platform sends a shutdown signal without waiting for in-flight agent sessions — especially long-running, multi-turn, or streaming tool-use conversations — to finish. Because agent interactions routinely run far longer than a typical stateless HTTP request (a single tool-calling loop can span tens of seconds to several minutes across multiple LLM round-trips), the default drain timeout tuned for short-lived requests expires while sessions are still mid-conversation, and those sessions are hard-killed. Users see a session abruptly disconnect, a streaming response cut off mid-token, or a tool call left in an indeterminate state with no completion or error ever recorded.

An agent's HTTP client (or the SDK wrapping a tool) maintains a fixed-size connection pool, typically sized for a single-threaded request/response app rather than an agent fanning out dozens of parallel tool calls. When the agent spawns concurrent sub-tasks that all hit the same tool, requests queue up waiting for a free connection from the pool and start timing out or erroring — even though the remote API itself has plenty of headroom and would happily serve the traffic.

A tool call's underlying TCP/TLS connection times out — a transient blip caused by network jitter, a brief DNS hiccup, or a momentary vendor load spike — and the agent has no retry logic wrapping the call. Instead of treating the timeout as a one-off, recoverable event, the agent surfaces it as a hard tool failure: it aborts the current task, marks the tool "unavailable," or hands the user a generic error, even though a second attempt a moment later would very likely have succeeded.

Multi-Agent Voting or Agreement Fails to Resolve

Generated Images Lack Consistency Across Multiple Generations (Same Subject, Different Outputs)

AI Generates False Content Presented as Fact

Model Fails to Properly Aggregate Context from Multiple Images; Makes Decisions Based on Incomplete Context

Race Conditions During Context Assembly Cause Inconsistent State

Over a long-running session, an agent's live working context (the conversation buffer, scratchpad, and accumulated tool outputs for the current run) comes to contain multiple, mutually contradictory statements about the same fact — an earlier tool result, a superseded plan, or a value that later changed — with no mechanism marking any of them as authoritative. Unlike long-term memory-store conflicts, which surface across sessions, this happens entirely within one continuous run: partial compaction, tool retries, and branching sub-tasks leave old and new versions of the same fact co-resident in context, and the model attends to whichever is more salient rather than resolving the conflict.

Model Ignores Retrieved Context

Sensitive Data in RAG Context Exposed Through Agent Responses

Low-Priority Content Displaces High-Priority Content

Many agent architectures periodically "refresh" a block of context — re-fetching current system state (order status, ticket state, account balance, feature flags) and re-injecting it into the prompt so the agent reasons over up-to-date information rather than what it read at session start. When the refresh mechanism itself reads from a stale source — a lagging read replica, a cache with a long TTL, a materialized view that hasn't recomputed — the agent receives a context block that looks fresh (it was "just refreshed") but actually contains old data, and the agent has no way to distinguish this from a genuine refresh.

Large Context Windows Cause Quadratic Latency Growth

Overloading Context with Irrelevant Information

Too many chunks dilute relevant evidence.

An agent has no internal tracking of how much of its context window is currently consumed, so as the session grows — tool outputs, retrieved documents, prior turns — early content gets silently truncated or evicted by the underlying context-management layer without the agent ever registering that it happened. The agent continues to reason as if everything it was told earlier is still available, producing answers that ignore or misremember instructions, constraints, or facts that were established at the start of the session and have since fallen out of the window.

Task Exceeds Context Window Limits

Agent Silently Drops Input Context When Message Exceeds Context Window

Malicious Content Injected into Agent's Context Persists Across Interactions

Too Much Context Overwhelms Synthesis

An agent generates a plan as a single linear sequence of steps with no fallback for what to do if a given step fails, returns an unexpected result, or becomes unavailable. When the primary path breaks partway through execution, the agent has no pre-defined alternative to fall back to and either halts entirely, retries the same failing step indefinitely, or improvises an ungrounded workaround on the spot with no guardrails.

Model Misses Ambiguous or Conflicting Clauses in Contracts; Leads to Dispute When Parties Interpret Differently

Contract Modified Multiple Times; Model Analyzes Original, Ignoring Amendments; Outdated Analysis Given

Agent Recommends or Approves a Medication Without Checking Patient-Specific Contraindications Beyond Drug-Drug Interactions

Over an extended multi-turn conversation, the agent's responses stop tracking the accumulated state of the discussion — it loses track of decisions already made, entities already introduced, or the current sub-task within a larger goal, and later replies read as disconnected from what came before. Unlike relevance drift, where the topic itself gradually shifts, coherence loss can occur on the same topic: the agent simply can't hold the thread together, producing responses that are locally sensible but don't fit the conversation's actual state.

The agent states something in one turn and then states something incompatible with it later in the same conversation, without acknowledging the change or reconciling the two claims. This erodes trust independent of whether either individual statement was correct, because the user cannot tell which one to believe. Unlike coherence loss, which is about losing track of state generally, contradiction is a specific, checkable failure: two concrete claims made by the same agent in the same session are logically incompatible.

The agent calibrates the wrong amount of detail for the question at hand — giving a two-line answer to something that needed a careful multi-step explanation (e.g. a nuanced tradeoff or a risk-bearing decision), or producing an exhaustive multi-section breakdown for something the user just wanted a quick yes/no on. Both directions cause friction: too shallow leaves the user under-informed and forces follow-up questions, too deep buries the actual answer and wastes the user's time.

The agent's register — word choice, sentence structure, use of humor or emoji, level of hedging — doesn't match what the context calls for: overly casual language in a request about a legal or medical matter, or stiff corporate boilerplate in a casual back-and-forth where the user has been informal throughout. The mismatch itself becomes a distraction from the content, signaling the agent isn't reading the room even when the substance of the answer is correct.

A conversation that should resolve in a handful of turns instead grows to dozens or hundreds of turns without reaching a conclusion, driven by the agent's own behavior — asking follow-ups instead of finalizing, re-explaining instead of confirming, or generating verbose responses that themselves prompt more back-and-forth. Cost (both token spend and user time) grows roughly linearly or worse with turn count while the probability of resolution per additional turn keeps falling, meaning the conversation is on a bad trendline that nothing forces it off.

The agent's emotional tone swings sharply and without cause between adjacent turns — upbeat and enthusiastic in one response, curt or apologetic-and-somber in the next, then breezy again — even though nothing in the conversation's content justifies the shift. Unlike formality mismatch, which is a single response miscalibrated to context, mood whiplash is specifically about the jarring delta between consecutive turns; the tone itself might be individually defensible each time, but the swing feels erratic and makes the agent seem unstable or inattentive to the user.

Across a multi-turn conversation, the subject matter gradually shifts away from the user's original goal, one small step at a time, until the conversation is addressing something meaningfully different from what the user came in for — without either party explicitly deciding to change topics. Each individual step feels like a natural continuation, but the cumulative drift means the original goal quietly falls out of scope and is never actually completed.

The agent restates information, asks a question, or repeats an instruction that it (or the user) already covered earlier in the same conversation, as if encountering it for the first time. This differs from coherence loss in scope: repetition is the narrow, directly observable symptom — the same content appearing twice — whereas coherence loss is the broader state-tracking failure that often, but not always, produces it (a single instance of repetition can also come from a template default firing regardless of history).

The agent enthusiastically follows every side topic the user (or its own reasoning) introduces mid-conversation, opening multiple simultaneous side-threads instead of resolving the primary task, so the conversation branches outward rather than converging. This differs from relevance drift, which is a single-direction gradual walk away from the original topic; tangent proliferation is specifically about accumulating multiple open side-threads in parallel, none of which get closed, while the main task also stalls.

When a Planner Asks the Agent to Adjust a Forecast Conversationally ("Bump Up SKU X for the New Campaign"), the Agent Regenerates an Entirely New Forecast Number Through Free-Text Reasoning Instead of Applying a Bounded Delta to the Existing Statistical Model's Output, Silently Discarding the Baseline's Seasonality and Trend Components

Agent Attributes Risk, Exposure, or Performance Data to the Wrong Entity Within a Corporate Family Due to Incomplete Parent-Subsidiary Mapping

Agent Fails to Adjust Prices, Positions, or Historical Series for Splits, Dividends, Mergers, or Spin-Offs

Assumed Diversification Fails When Correlations Spike (Tail Dependence Not Captured)

Agent Synthesizing a Due-Diligence Risk Memo From Disclosed Financial Facts Constructs a Confident Causal Narrative Linking Two Temporally Adjacent Facts, Without Any Underlying Transaction-Level Evidence That One Actually Caused the Other

Multiple Correlated Metrics All Spike Together; Model Flags as Coordinated Attack But Actually Cascading Failure

Agent's Internal State Compromised, Affecting All Its Interactions

Unusual Cost Patterns Go Undetected

Costs Cannot Be Accurately Attributed to Users, Agents, or Use Cases

Cost Optimization Degrades Agent Quality

Agent Onboarding a New Supplier Verifies Business Registration and Pricing Competitiveness but Does Not Verify Component Authenticity or Sub-Tier Sourcing Chain

A tool executes agent-submitted work as a job (e.g., a serverless function, a batch data-processing task, a sandboxed code-execution call) under a fixed CPU quota — a cgroup limit, a vCPU-second cap, or a throttling policy. When the agent's request involves more computation than expected (a larger dataset, an unexpectedly expensive query plan, a recursive operation), the job gets throttled mid-execution or killed outright by the orchestrator, and the agent receives a generic failure with no indication that CPU exhaustion was the cause.

Inference serving is usually thought of as GPU-bound, but the CPU-side work around it — request tokenization, sampling/logits post-processing, tensor-parallel coordination, response serialization, and health-check handling — runs on a shared CPU pool that can saturate independently of GPU load. When one node's CPU saturates, the GPU sits partially idle waiting on CPU-bound preprocessing/postprocessing, so the fleet's effective throughput drops; the resulting backlog shifts load onto neighboring nodes, whose CPUs then saturate in turn, cascading a single node's bottleneck into a fleet-wide throughput collapse that shows up as a spike in cost-per-token because GPUs keep billing while doing less useful work.

Agent Leaks API Keys, Passwords, or Tokens

Agent Exposes API Keys, Passwords, or Secrets in Output

API Keys, Passwords, Tokens Exposed in Logs or Error Messages

Agent Summarizes a Critical Lab Result Within a Routine Note Instead of Triggering Immediate Notification

Agent Reviews a Contract Involving Cross-Border Data Flows Without Checking for Required Transfer Mechanism Clauses

Model Fails to Match or Reference Objects Across Different Images

Agent Confuses Information Across Sessions

Data from One User's Session Appears in Another's

Agent mixes data across customers/accounts.

AI Agent Exposes Data Between Isolated Customer Environments

An agent has separate, independently-tracked budget caps for each tool it uses — say $10/day for a search API, $15/day for an enrichment API, and $25/day for an LLM-based summarization tool — and each individual cap is respected. But no component tracks the sum across tools, so the agent can legitimately spend up to $50/day per user session while whoever set the budgets believed they were capping total spend at, say, $20/day. The org discovers the real number only when the consolidated vendor invoice arrives.

Current task is polluted by unrelated previous context.

Records or fields are tagged with a sensitivity classification (e.g., `public`, `internal`, `confidential`, `restricted`) in the data catalog, but the tool-serving layer the agent calls through doesn't actually check that classification before returning results. The classification exists as documentation and governance metadata, not as a runtime enforcement rule, so an agent with generic tool access retrieves `restricted`-tagged data exactly as easily as `public`-tagged data.

A user or data-subject deletion request (e.g. a GDPR/CCPA erasure request) is supposed to propagate through every tool, cache, vector store, and downstream system the agent has ever written that person's data to. In practice, the agent's deletion logic only reaches the primary data store it knows about, missing copies written to secondary systems — search indexes, embedding/vector stores, analytics warehouses, third-party tool integrations, or logs — that the agent wrote to during normal operation but that the deletion workflow was never extended to cover.

Agent leaks private or sensitive data.

Agent Exposes Sensitive Information

As data moves through a multi-stage pipeline (ingestion, normalization, enrichment, aggregation, and into an agent's context), each stage typically emits only its output, not a record of which input rows or upstream events produced it. When the agent later needs to explain a decision, trace an anomaly back to its source, or honor a downstream correction (a customer disputes a charge derived from a specific transaction), there is no reliable path from the final artifact back to the originating record.

An agent's downstream consumer (a database writer, an LLM enrichment call, a rate-limited third-party sync) slows down, but the upstream producer stages of the pipeline keep emitting data at the original rate because no signal travels backward to tell them to slow down. The gap between production and consumption rate is absorbed by an in-memory or disk queue that has no bound, until it either fills and starts dropping messages or exhausts host memory and crashes the whole pipeline.

An agent that reads from a multi-stage pipeline treats the data it receives as current, but each stage (ingestion, normalization, enrichment, batching, indexing) adds its own processing delay, and those delays compound. By the time the agent acts — approving a trade, flagging inventory as low, answering "what is the current status" — the data reflects the world as it was minutes or hours earlier, not as it is now, and nothing in the agent's context signals how stale the value actually is.

An intermediate stage in a data pipeline — a normalization step, a schema-mapping step, a "clean up the data" step written before the agent's needs were fully known — silently drops or truncates fields, coerces types in ways that lose precision, or collapses distinct source values into the same output value. The pipeline continues to run without errors because the transformation is syntactically valid; it is only semantically incomplete, and the agent downstream never learns that information it needed was discarded before it ever saw the data.

An agent's processing logic implicitly assumes events arrive in the order they occurred (a "created" event before an "updated" event, a payment "authorized" before a "captured"), but a pipeline change — adding parallel processing, repartitioning a queue by a different key, introducing retries, or migrating to a different message broker — reorders events in transit. The agent applies updates in the new arrival order, producing state that reflects an event sequence that never actually happened.

When a pipeline stage fails partway through, gets redeployed, or a consumer's offset is reset for recovery, the standard remedy is to replay events from a checkpoint. If the agent's downstream processing logic performs side effects (sending a notification, charging a payment, incrementing a counter, calling an external API) without checking whether that specific event was already processed, replaying the event log causes those side effects to happen again, producing duplicate charges, duplicate notifications, or double-counted metrics.

An upstream system or team changes the shape of the data it emits — renaming a field, changing a type, adding a required field, deprecating an enum value — without coordinating with every downstream consumer. Because the pipeline has no contract enforcement between producer and consumer, the change ships silently, and the agent's parsing logic either throws on the first unexpected value, silently coerces it to null/default, or misinterprets a renamed field as absent, breaking downstream behavior with no upstream-visible signal that anything happened.

Data subject to a jurisdictional residency requirement (e.g. EU customer data must stay within the EU, certain government data must stay within national borders) passes through a tool call — an LLM inference API, a third-party enrichment service, a logging pipeline, a backup destination — that processes or stores it in a different region than required, because the tool's regional routing wasn't configured or verified against the residency requirement at integration time.

An agent scoped to operate within a specific business boundary — a department, project, or team — issues a tool query that crosses into a sibling boundary it was never intended to see, because the boundary is a soft, business-logic construct rather than a hard constraint enforced at the tool layer. Unlike multi-tenant or workspace isolation, these boundaries usually live inside a single shared database and account, distinguished only by a filter (e.g., `department = 'Engineering'`) that the application is expected to apply consistently but doesn't always.

Two or more agents each hold a resource that another agent in the group needs, and each is waiting for the resource held by the next, forming a closed cycle of dependencies where no agent can proceed. Unlike a simple timeout or a single stuck agent, deadlock is a stable state — none of the agents involved will ever make progress on their own, because each is correctly waiting for something that will never be released, since the releaser is itself waiting.

OCR System Fails to Detect All Borrower Debt Obligations

Information Needed for Debugging Lost Before Investigation

AI System Fails to Detect Video/Voice Deepfakes in Remote Closings

Self-Service Agent Marks a Conversation as "Deflected" (Resolved Without Human Agent) Based on the Customer Not Replying, Rather Than the Issue Actually Being Resolved

A tool vendor experiences an internal incident — an overloaded backend, a partial regional outage, a resource-constrained fallback mode — and quietly degrades service quality (higher latency, lower accuracy, reduced feature availability) to keep the system technically "up," without posting to a status page or notifying API consumers. The agent has no explicit signal that anything has changed; it just observes worse results and, absent any error or status indicator, has no basis to distinguish a genuine data or logic problem from a vendor-side degradation it should be working around.

Business outcome arrives later and cannot be attributed to agent action.

Agents Delegate to Sub-Agents Creating Unbounded Depth

A user grants an agent limited authority to act on their behalf — e.g. "book travel under $2,000" or "respond to routine emails but don't send anything financial." The agent (or a sub-agent it spawns to handle part of the task) continues acting under the user's identity or impersonation token beyond that delegated scope, because the scope was expressed as a natural-language instruction rather than an enforced, machine-checkable boundary on the credential itself.

Model Biased Toward/Against Certain Demographics (Race, Gender, Age); Different Accuracy for Different Groups

An agent's toolchain depends on a third-party service, model endpoint, or package registry that is not available in every region the agent is deployed to — due to data residency law, provider infrastructure gaps, or export restrictions. The dependency works fine in development and in the primary deployment region, so the regional gap goes unnoticed until the agent is deployed or scaled into a new region and a specific tool call starts failing for every user in that geography.

A library, SDK, or API the agent's toolchain depends on ships a breaking change — a removed function, an altered response format, a changed default behavior — and the agent's own team has no process that surfaces the change before it reaches production. Automated dependency updates, transitive upgrades pulled in by an unrelated package bump, or a provider's server-side API change (which requires no client-side upgrade at all) all ship the break silently from the agent team's point of view, and it is discovered only when the agent's behavior degrades or a build fails.

Two or more services, modules, or agents depend on each other, directly or through an intermediate chain, in a cycle: Service A calls Service B during initialization or request handling, and Service B (directly, or via Service C) calls back into Service A before A has finished. Under normal, low-latency conditions the cycle can complete without anyone noticing, but under load, during startup ordering, or when one leg of the cycle is slow, the mutual wait never resolves and the system deadlocks or spins in an infinite resolution loop.

Deployment Agent Doesn't Detect Breaking Changes in Dependencies; Deploys Incompatible Versions

An agent's development workflow — often an agent itself, tasked with "add a library that does X" — pulls in a new dependency without checking its license against the project's own licensing terms or the terms of the dependencies already in the tree. A permissively-licensed project unknowingly incorporates a copyleft-licensed package (or one with a restrictive commercial-use clause), creating a legal obligation (source disclosure, attribution, non-commercial restriction) the project's license terms don't account for, and the conflict surfaces only during a legal review, an acquisition due-diligence process, or a customer's compliance audit.

A library the agent's system depends on — directly or transitively — has a publicly disclosed CVE, but the vulnerable version remains in production because no process reliably surfaces the disclosure, prioritizes it against other work, and ships a patch. The gap between disclosure and patching leaves an exploitable window, and for agents specifically, a vulnerable dependency in a tool-execution or code-execution path can be a direct route to prompt injection, arbitrary code execution, or data exfiltration triggered by attacker-controlled input the agent processes.

Two direct dependencies the agent's system relies on each require different, incompatible versions of the same shared transitive dependency (Package X needs library Z at version 1.x, Package Y needs library Z at version 2.x, and 1.x/2.x are not compatible). The package manager either fails to resolve the tree, silently picks one version and breaks the other package at runtime, or (in ecosystems that allow multiple versions to coexist) installs both, producing subtle bugs when an object created by one version's code is passed into code expecting the other version's shape.

A team pins a dependency to an exact version — often deliberately, to avoid an earlier breaking-change incident or to satisfy a compliance requirement for reproducible builds — and later, a different part of the system introduces a new requirement (a new package, a new feature, a security patch) that needs a minimum version higher than the pin. The pin, which was added specifically to provide stability, now actively blocks a change the system needs, and resolving the conflict requires either revisiting the original reason for the pin or accepting the very risk the pin was meant to prevent.

Anomaly-Detection Agent Attributes a Metric Anomaly to the Most Recent Deployment by Default, Missing the Actual Independent Cause

Two services in an agent pipeline — for example, the orchestrator that calls tools and the tool-schema registry it depends on — each have a deployment that is written to wait for the other to update first, so neither team is willing to deploy. The orchestrator team wants the registry to publish the new tool schema before they roll out code that assumes it exists; the registry team wants the orchestrator's new validation logic live before they push a schema change that would otherwise break the old validator. Both releases sit staged and ready, and the system stays on outdated, incompatible-in-the-making versions indefinitely because each side is correctly avoiding breaking the other, but nobody has sequenced who actually moves first.

A release requires a specific sequence — for example, a database migration adding a new column that the updated agent orchestrator code depends on must land before the orchestrator itself is deployed — but the deployment pipeline applies the two changes out of order, or applies them concurrently without an enforced dependency. The new orchestrator code starts up and immediately queries or writes the column that doesn't exist yet, crashing on startup or, worse, silently defaulting to null/empty values that corrupt downstream agent state (e.g., losing a conversation's tool-permission scope because the column that stored it isn't there yet).

A required pre-production gate — a regression eval suite against known agent conversation transcripts, a tool-schema compatibility check, a canary soak period — is bypassed for a given release, either through an explicit manual override ("hotfix, skip the eval run, we need this live now") or because a pipeline misconfiguration silently short-circuits the gate. The release ships straight to production without the validation that was specifically designed to catch the class of regression it turns out to contain, and the failure surfaces in front of real users instead of in the gate that existed to prevent exactly that.

A tool endpoint the agent depends on is formally deprecated by the vendor and, after a notice window, retired outright — returning 404s or 410s instead of the expected response. The agent has no fallback path coded because the endpoint "always worked" during development, so once the retirement date passes, every call fails outright with no graceful degradation, and the failure often isn't noticed until the retirement is already in effect.

Monocular Depth Estimation Wrong; 3D Positioning Fails

Vision models fail to accurately estimate depth from single images; hallucinate depth cues when monographic features (shadows, perspective, texture) are ambiguous or misleading

Agent relies solely on an LLM-judge to assess its own output when a deterministic, executable check (schema validation, test suite, linter, tool-call format check) was available and would have caught the error at near-zero cost.

Performance Varies Significantly Across Devices

AI System Fails to Properly Validate Digital Signatures on Documents

User prompt manipulates agent to ignore instructions.

When a request is genuinely ambiguous, the agent has some strategy for resolving it — asking a question, picking the most likely interpretation, presenting options — but the strategy itself is a poor fit for the type of ambiguity present, so the ambiguity survives the resolution attempt. This is a broader, strategy-level pattern than clarification-irrelevant (a single wrong question): it covers any mismatched approach, including choosing to guess when asking was needed, presenting an unusable list of options, or asking when a simple default would have sufficed.

Agent Generates Discharge Medication List Without Reconciling Against Pre-Admission Home Medications

OCR System Fails to Detect Missing or Incomplete Required Disclosures

Litigation-Support Agent Marks Materially Relevant Documents as Non-Responsive (or Vice Versa) During Discovery Review, Creating Spoliation or Over-Production Risk

Agent's Filler Words and Speech Disfluencies Don't Match Persona or Context

Inference nodes accumulate disk usage from request/response logs, prompt-cache and KV-cache spill files, downloaded model checkpoints (including duplicate versions kept for rollback), and container image layers. When disk fills up, the failure isn't graceful — model loading fails for new deployments, log writes start silently failing or blocking, and in some serving stacks the engine crashes outright — taking healthy GPU capacity offline and forcing traffic onto fewer nodes, which raises effective cost-per-token even though the root cause has nothing to do with compute pricing.

Production Queries Differ Significantly from Golden Dataset

OCR System Fails to Validate Document Authenticity Markers

OCR System Fails to Detect Missing Pages, Sections, or Required Information

AI System Fails to Verify Document Dates Align with Stated Timeline

OCR System Fails to Validate Document Dates and Date Relationships

Extraction Completes Successfully but the Data Relationships Are Wrong

Preprocessing Strips Layout Structure Before Extraction Ever Runs

AI System Fails to Verify Documents Match Expected Institution Templates

A Billing-Dispute Agent That Retrieves a Dispute-Handling Template or Policy Article From a Knowledge Base Via Embedding Similarity to the Customer's Complaint Wording Pulls an Entire Document That Is Topically and Lexically Close -- Covering a Structurally Similar but Different Dispute Type, Product Tier, or Region -- Rather Than the Document That Actually Governs the Customer's Account, and Applies That Wrong Document's Resolution Steps and Dollar Thresholds Confidently

Agent-Generated Clinical Note Language Inflates or Deflates Billing Code Level Relative to Actual Care Delivered

An agent retrieves and applies information that was once the accepted best practice in a domain but has since been superseded by an evolved standard, even though the underlying fact is still technically true. The agent's knowledge source (a fine-tuned model, a static knowledge base, or a cached document set) captured the practice at a point in time and was never re-indexed against the field's current consensus, so the agent confidently recommends an approach that a current practitioner would flag as outdated. The advice isn't factually wrong in isolation — it's wrong relative to what the domain now considers correct.

An agent produces output or takes an action that violates a hard, non-negotiable constraint of the domain it's operating in — a regulatory requirement, a safety interlock, a licensing restriction — because the constraint was never surfaced by its retrieval layer. Unlike a best-practice miss, this isn't a matter of degree: the agent crosses a bright line (e.g. recommending a drug dosage that exceeds a labeled maximum, or drafting a contract clause that's unenforceable in a given jurisdiction) because its knowledge base treated the constraint as optional context rather than a gating rule.

An agent correctly establishes domain-specific context early in a session — the specialty, jurisdiction, or technical stack it should reason within — but loses track of it as the conversation grows, silently reverting to generic, domain-agnostic behavior. The regression isn't triggered by the user changing topics; it happens because the domain-framing information falls out of the effective context window or gets diluted by intervening turns, and nothing in the agent's architecture re-asserts it.

An agent correctly retrieves and applies a general domain rule, but fails to recognize that the specific case at hand falls under a documented exception that overrides or modifies the general rule. The exception exists in the knowledge base — often in a separate section, footnote, or appendix — but the agent's retrieval or reasoning never connects the specific case to it, so the general rule is applied as if it were universal.

Agent Fails on Out-of-Distribution or Specialized Inputs

An agent operating in a specialized domain fails to flag a risk factor that any competent domain practitioner would immediately recognize as significant, not because the underlying fact is missing from its knowledge base, but because that fact was never tagged or weighted as risk-relevant. The agent retrieves and states the fact correctly when directly asked, yet doesn't proactively surface it as a concern in a context where a domain expert would treat it as a red flag requiring attention.

An agent retrieves a correctly-stated domain rule but misapplies it because it misreads the precise conditions under which the rule holds — extending it to cases just outside its actual scope, or narrowing it to exclude cases it actually covers. The rule text itself is never altered or hallucinated; the failure is in the agent's interpretation of qualifying language like "only if," "except when," or "applies to X but not Y" that defines the rule's true boundary.

Agent Violates Domain-Specific Constraints

An agent interprets a domain-specific term using its common, general-language meaning instead of the narrower or entirely different meaning the term carries within the specialized domain, producing a response that's coherent but answers the wrong question. This happens most with terms that are ordinary English words repurposed with precise technical meaning (e.g. "significant" in statistics, "material" in accounting, "positive" in a lab result), where the domain meaning can even be the near-opposite of the everyday connotation.

ASR Fails to Recognize Industry-Specific Terms

Agent Recommends Standard Adult Dosing Without Adjusting for Impaired Renal or Hepatic Clearance

Model Recommends Drug Combination Without Flagging Known Dangerous Interactions

During an Extended Single-Session SEO Content-Planning Conversation Covering Dozens of Target Pages, an Editor's Early Instruction That a Specific Keyword Cluster Must Be Excluded (Because It Cannibalizes an Existing High-Ranking Page or Conflicts With a Paid-Search Exclusion List) Falls Out of the Agent's Effective Context as the Session Grows, and the Agent Later Recommends or Drafts Content Targeting the Excluded Cluster as if the Constraint Had Never Been Stated

Agent's Own Audio Interferes with User Speech Detection

AI System Fails to Detect Hidden or Suspicious Objects Embedded in PDFs

Embedding Model Changes Break Retrieval

A Drafting Agent Asked to Insert a Jurisdiction-Specific Clause (a Non-Compete, a Consumer-Arbitration Provision, a Statutory Notice) for a Contract Governed by One State or Country's Law Retrieves the Clause From a Multi-Jurisdiction Template Library Using Semantic Similarity Over the Clause's General Subject Matter, Rather Than Matching Strictly on Governing Jurisdiction, and Pulls a Differently-Jurisdictioned Template That Is Lexically Almost Identical but Legally Ineffective or Unenforceable Under the Contract's Actual Governing Law

A Compliance Agent Assembling a Required Regulatory Disclosure for a Filing Retrieves the Applicable Disclosure Template From a Multi-Jurisdiction Template Library Using Semantic Similarity Over the Regulation's Name and Subject Matter, Rather Than Matching on the Controlling Jurisdiction Itself, and Pulls a Template Built for a Differently Named but Substantively Different Regulatory Regime in Another Jurisdiction That Happens to Share Closely Overlapping Terminology

A Capacity-Planning Agent That Selects a Reference Capacity Profile for a New or Under-Profiled Service by Semantic Similarity Over the Service's Name and Description Pulls a Lexically Similar but Operationally Different Profile -- One Built for a Stateless, Horizontally-Scalable API Service -- When Planning Capacity for a Stateful, Single-Writer Cache Service, Recommending an Autoscaling Strategy That Does Not Apply

A Deployment-Safety Agent That Retrieves the Applicable Pre-Deploy Safety Checklist by Semantic Similarity Over the Service's Name and Description Pulls a Lexically Similar but Substantively Different Checklist -- One Written for a Stateless Service -- When Deploying a Stateful Service, Omitting a Required Migration-Compatibility Gate

A Cost-Optimization Agent That Selects a Cost-Reduction Playbook for a Flagged Resource by Semantic Similarity Over Its Tags, Name, and Description Pulls a Playbook Written for a Fault-Tolerant Batch Workload -- Recommending Migration to Spot/Preemptible Instances -- and Applies It to a Latency-Sensitive, Interruption-Intolerant Workload That Shares Overlapping Tag Vocabulary but Cannot Tolerate the Same Risk

A Fraud-Detection Agent's Link-Analysis Retrieval Step, Which Searches for Claimants Embedding-Similar to Known Fraud-Ring Members Based on Free-Text Claim-Narrative and Address Fields, Surfaces a Coincidental Lexical Match (a Common Surname, a High-Density Apartment Complex Address) and Treats It as a Fraud-Ring Association, Escalating a Legitimate Claimant for SIU Investigation Based on a Retrieval False Positive

A Compliance Agent Classifying a Newly Launched Financial Product Against the Applicable Regulatory Rule Set Selects the Rule Whose Description Is Most Lexically or Embedding-Similar to the Product's Marketing Description, Rather Than Matching on the Product's Structured Regulatory Classification Code, Applying the Wrong Rule Set to a Structurally Different Product

A Medication-Reconciliation Agent Matching a Free-Text or Handwritten Medication Entry Against a Structured Formulary Database Uses Similarity-Based Lookup That Resolves the Entry to a Lexically Similar but Pharmacologically Different Look-Alike/Sound-Alike (LASA) Drug, and the Reconciled Medication List Carries the Wrong Drug Forward Into the Patient's Active List

An Agent Interpreting a Lab Result That Looks Up the Applicable Reference Range Via Semantic Search Over a Reference-Range Knowledge Base, Rather Than an Exact Assay-Code Match, Retrieves the Range for a Differently Named but Textually Similar Test -- Such as Confusing "Vitamin D, 25-Hydroxy" With "Vitamin D, 1,25-Dihydroxy" -- and Flags or Clears the Result Against the Wrong Range

An Agent Checking a Medication List for Drug-Drug Interactions, Using Semantic Similarity Search Over an Interaction Knowledge Base to Find the Relevant Interaction Profile for a Given Drug, Retrieves the Profile for a Structurally or Name-Similar but Pharmacologically Distinct Drug, and Clears or Flags the Combination Based on the Wrong Drug's Interaction Data

A Data-Quality Agent Deduplicating Issuer Records Across Multiple Source Feeds Using Embedding Similarity Over Issuer Names, Rather Than Matching on a Unique Identifier Such as LEI or CUSIP Issuer Code, Merges Two Distinct Issuer Entities With Coincidentally Similar Names Into a Single Record, Corrupting Downstream Holdings and Exposure Calculations

An Alert-Routing Agent That Decides Which Team to Page by Retrieving the Most Semantically Similar Past Incident Runbook for the Incoming Alert Text Pulls a Lexically Similar but Substantively Different Runbook -- Written for a Different Service With Overlapping Error-Message Vocabulary -- and Pages the Wrong Team

A Ticket-Routing Agent That Classifies an Incoming Ticket's Product Category by Embedding Similarity Against a Product-Taxonomy Description Index, Rather Than Against the Account's Actual Provisioned Product List, Matches the Ticket to a Superficially Similar but Incorrect Product Line, Routing It to a Specialist Queue That Cannot Resolve the Customer's Actual Issue

A Content-Generation Agent's Retrieval Step over a Vector Store Containing Both the Current and a Superseded Style-Guide Version Ranks the Deprecated Version's Chunk Higher Due to Denser, More Frequently Indexed Older Content, and the Agent Applies Retired Terminology and Tone Rules as if They Were Current

A Demand-Forecasting Agent Generating a Cold-Start Forecast for a New Product by Retrieving the Most Similar Historical SKU via Embedding Similarity Over Product Descriptions Selects a Past SKU That Reads as Similar in Category and Description but Was Discontinued for Demand Reasons Specific to That Product, Producing a Forecast That Inherits a Demand Pattern Unrelated to the New Product's Actual Market

A Contract-Drafting Agent's RAG Step, Asked to Retrieve the Company's Standard Work-for-Hire IP-Assignment Template for a New Contractor Agreement, Retrieves a Lexically and Semantically Similar but Substantively Different Document -- An Open-Source Contributor License Agreement or Inbound-IP Template -- Because Both Documents Share Dense "Intellectual Property," "Assignment," and "License Grant" Vocabulary

A Retention-Prediction Agent's Embedding Search over Past Departed-Employee Records Surfaces a Lexically Similar but Substantively Different Attrition Case as the Nearest-Neighbor Comparable, and the Agent Anchors a Current Employee's Risk Score to That Mismatched Precedent

A Pipeline-Forecasting Agent Justifying Its Stage-Conversion-Rate Assumption for a Set of Open Opportunities Retrieves "Comparable Historical Deals" via Embedding Search over Closed-Deal History, and the Search Surfaces a Cohort of Past Deals That Share Lexical Similarity in Industry Tags or Deal-Name Keywords but Differ Substantially in Buying-Committee Structure or Deal Size, Producing a Stage-Conversion Benchmark That Systematically Overstates or Understates the Forecast for the Current Cohort

An Offer-Generation Agent's Embedding Search over Past Leveling Decisions Surfaces a Role with Lexically Similar Title and Description but a Different Career Track or Leveling Framework, and the Agent Anchors the New Offer's Band to That Mismatched Precedent

A Policy-Renewal Agent's Retrieval Step Surfaces a "Similar Policy" Precedent via Embedding Similarity to Determine an Appropriate Rate Adjustment for an Unusual Risk Profile, but the Matched Policy Is in a Different Rating Territory With Different Loss Experience, Leading to a Mispriced Renewal

A Quota-Coaching Agent's Retrieval Step Surfaces a "Similar Rep" Coaching Playbook Based on Embedding Similarity to a Rep Profile in a Different Territory or Segment, and the Coaching Recommendation It Generates Is Mismatched to the Actual Rep's Deal Dynamics

An Incident-Response Agent That Retrieves a Past Incident's Resolution Steps via Semantic Similarity Search Over Incident Descriptions, Rather Than Matching on Root-Cause Signature or Affected-Component Identity, Surfaces a Past Incident That Reads Similarly but Had a Different Underlying Cause, and Applies That Incident's Resolution Steps to the Current One

A Supplier-Risk Agent, Lacking Sufficient Direct History on a New or Thinly-Documented Supplier, Retrieves a Semantically or Lexically Similar Supplier's Risk Profile as an Analog to Inform Its Risk Score, but the Retrieved Analog Is Selected by Name or Description Similarity Rather Than the Structured Attributes (Industry Code, Ownership Structure, Geography, Tier) That Actually Determine Comparable Risk

A Deal-Management Agent Assembling a Custom Order Form or Amendment Retrieves a Liability-Cap or Termination-for-Convenience Clause via Embedding Search over the Company's Contract Repository, and Because Most Enterprise Agreements Share Highly Standardized, Boilerplate Language, the Retrieval Step Surfaces a Clause From a Different Customer's Contract With a Different (and More Favorable to That Other Customer) Negotiated Term, Which the Agent Inserts Into the Current Deal's Document as if It Were the Company's Standard Clause

To Calculate Safety Stock for a New SKU Lacking Sufficient Sales History, an Inventory-Optimization Agent Retrieves the Most Similar Existing SKU via Embedding Similarity Over Product Descriptions to Borrow Its Demand-Variance Profile, but Selects a SKU That Is Textually Similar Yet Has a Fundamentally Different Volatility Pattern, Producing a Safety-Stock Level Calibrated to the Wrong Risk Profile

An Onboarding Agent's Retrieval Step Surfaces a Benefits-Eligibility Policy Document for a Similarly Named but Different Work Jurisdiction or Employment Classification, and the New Hire Is Told Incorrect Eligibility Terms Because the Embedding Match Favored Lexical Similarity Over an Exact Jurisdiction/Classification Match

A Support Agent That Selects a Canned Response or Macro From a Library Via Semantic/Embedding Similarity to the Customer's Message, Rather Than by Matching the Customer's Actual Account State or Issue Category, Retrieves a Response That Is Lexically and Topically Close to What the Customer Wrote but Answers a Different Underlying Situation -- Sending Confident, On-Topic-Sounding Guidance That Does Not Actually Apply to the Customer's Case

A Sentiment-Escalation Agent That Selects an Escalation Playbook by Embedding Similarity Against a Playbook-Description Index, Rather Than Against the Structured Severity Tier the Conversation Actually Belongs To, Matches the Conversation to a Superficially Similar but Wrong Playbook, Routing It Through an Escalation Path That Does Not Match the Actual Risk Level

A Transaction-Cost-Analysis Agent Benchmarking a Trade's Execution Quality Against Historical Comparable Orders Selects the "Most Similar" Past Order Using Embedding Similarity Over Free-Text Order Notes, Rather Than Matching on Instrument, Order Size, and Time-of-Day Liquidity Regime, Producing a Benchmark That Was Never Executed Under Comparable Conditions

A Logistics-Routing Agent Estimating Transit Time for a New Origin-Destination Lane Retrieves the Most Similar Historical Lane via Embedding Similarity Over Route Descriptions, Selecting a Lane That Shares a Similar Region-Pair Label but Has a Materially Different Mode or Border-Crossing Profile, Producing a Transit-Time Estimate the Agent Then Commits to a Customer as an ETA

A Market-Data Freshness-Monitoring Agent Checking Whether an Illiquid Instrument's Price Is Plausibly Current Selects a "Comparable" Reference Instrument Using Embedding Similarity Over Free-Text Descriptions Rather Than Matching on Sector, Duration, and Credit-Quality Attributes, Producing a Freshness Benchmark That Moves Differently From the Instrument Being Checked

A Self-Service Deflection Agent's RAG Step, Used to Suggest a Help Article to Resolve a Customer's Question Without Human Involvement, Retrieves a Lexically and Semantically Similar but Deprecated or Product-Version-Mismatched Article Instead of the Current Correct One, Deflecting the Customer With Stale Instructions Framed as the Solution

A Due-Diligence Agent Building a Target Company's Corporate-Structure Chart From Filings and Registry Data, Using Semantic Similarity Search to Match Entity Names Across Documents, Merges or Links a Subsidiary Into the Target's Structure Based on Name Similarity Alone, When the Matched Entity Is in Fact an Unrelated Company With a Coincidentally Similar Name

A Quality-Control Agent's Self-Check Retrieves a Previously Approved Statistical Claim via Embedding Similarity to "Confirm" That a New Claim Is Accurate, but the Retrieved Precedent Is for a Different Year, Population, or Methodology, So the Confirmation Is Not Actually Evidence the New Claim Is Correct

An Underwriting Agent's Retrieval Step, Used to Find a "Similar Prior Case" Precedent for Classifying an Applicant's Occupation Into the Correct Risk Class for Pricing, Surfaces a Prior Underwriting Case That Is Embedding-Similar by Job-Title Wording but Belongs to a Materially Different Risk Class, Causing the Agent to Apply the Wrong Class's Rate Factor to the Current Applicant

A Compliance-Review Agent's Retrieval Step Over a Vector Store of Approved Substantiation Documents Returns a Source That Is Embedding-Similar to the Marketing Claim Under Review Because It Discusses the Same Product Category and Uses Closely Related Phrasing, but the Retrieved Source Actually Supports a Narrower, Differently Conditioned, or Already-Expired Claim Than the One the Copy Makes, and the Agent Approves the Claim as Substantiated on the Strength of the Similarity Match Alone

A Supplier-Onboarding Agent's RAG Step, Used to Retrieve the Correct Compliance/Certification Checklist Template for a New Supplier Based on Its Stated Industry and Product Category, Pulls a Lexically Similar but Substantively Different Template Because the New Supplier's Self-Description Text Is Embedding-Similar to a Different Product Category's Template

An SLA-Management Agent's RAG Step, Used to Retrieve the Applicable Response-Time and Resolution-Time Commitments for an Incoming Ticket Based on the Customer Account's Description, Pulls a Lexically Similar but Wrong-Tier SLA Policy Document, Causing the Agent to Apply Incorrect Commitment Clocks to the Ticket

A Content-Generation Agent's RAG Step, Used to Ground Marketing Copy in "Similar High-Performing Content" Retrieved from a Crawled Corpus, Pulls in a Factual or Comparative Claim from a Competitor's Published Content Because It Is Embedding-Similar to the Target Topic, and the Agent Incorporates That Claim into the Brand's Own Copy as If It Were a Verified, Brand-Owned Fact

A Contract-Drafting Agent's RAG Step, Used to Pull the Firm's or Company's Approved Boilerplate Clause for a Given Section (Limitation of Liability, Indemnification, Governing Law) from the Template Library, Retrieves a Lexically Similar but Superseded or Jurisdiction-Wrong Version of the Clause, and the Drafted Contract Is Issued with the Wrong Terms

A Claims-Adjudication Agent's RAG Retrieval Step Pulls a Lexically Similar but Superseded or Wrong-State Policy Endorsement from the Document Store Instead of the Endorsement Actually Attached to the Policy in Force, Causing the Agent to Apply Incorrect Coverage Terms to the Claim

A Lead-Scoring Agent That Justifies Its Score by Retrieving "Similar Past Deals" via Embedding Search over the Closed-Deal History Pulls a Lexically Similar but Substantively Different Deal (Same Industry Keywords, Different Buying Stage or Company Size) and Cites It as Supporting Evidence for an Inflated Score

Agent Overuses Laughter, Exclamation Marks, and Emotional Cues

Voice Emotion Doesn't Match Message Content or Context

AI System Fails to Detect Fake Employers or Fabricated Employment

OCR System Fails to Detect or Flag Gaps in Employment History

AI System Fails to Detect Inconsistent Employment Dates Across Documents

A Clinical-Summary or After-Visit-Note Agent Queries a Structured EHR Field for the Patient's Allergy History, the Query Returns Zero Records (Because the Field Was Never Populated, Not Because a Clinician Affirmatively Confirmed the Patient Has No Allergies), and the Agent's Note-Generation Step Renders This as "No Known Drug Allergies" -- an Affirmative Clinical Statement the Underlying Data Never Supported

Agent Can't Reliably Detect When User Has Finished Speaking

Agent Confuses Similar Entities

A tool vendor changes what an existing error code means — repurposing a generic `400 Bad Request` to also signal a new condition like "rate limited by a downstream partner" or reusing `409 Conflict` for a newly introduced idempotency-key collision case — without incrementing the API version or announcing a breaking change. The agent's error-handling logic, written against the old, narrower meaning of that code, applies the wrong recovery strategy (e.g. retrying a request that will never succeed, or treating a transient condition as permanent), and because the HTTP status and error code string are unchanged, nothing about the failure looks abnormal at the transport level.

Raw Errors Expose Internal Details and Waste Context

The same tool returns errors in inconsistent shapes depending on which layer of its stack produces the failure — a structured JSON body with an `error.code` field for application-level validation errors, a bare plain-text string for a load balancer timeout, and a full HTML error page for a gateway-level 502 or a WAF block. An agent's error parser, built to expect one shape (usually the documented JSON structure), successfully handles the cases that match it and silently mishandles or crashes on the rest, because the alternate formats don't fail loudly — they just don't match, and the fallback behavior for a non-match is often to treat the response as a generic unknown failure or, worse, to attempt to parse it as JSON and swallow the resulting exception.

Agent Fails to Escalate to Human When Required

Agent gives up despite solvable request.

Agent Incorporates Self-Reported Corporate ESG Disclosures Into Portfolio Scoring at Face Value, Without Adjusting for Known Greenwashing or Disclosure-Quality Variance

Tests do not represent production inputs.

Golden Data Contaminated Training or Model Has Seen Eval Cases

Metrics Don't Measure What Actually Matters for Success

Agent Takes Actions Beyond Expected Scope

A tool enforces a hard maximum execution time per call (a Lambda-style 15-minute cap, a synchronous API's 30-second gateway timeout, a query engine's statement timeout). When the agent issues a request whose natural completion time exceeds that ceiling — a large data export, a bulk transform, a long-running search — the call is killed at the boundary with no partial results returned and often no clear indication that a timeout, rather than a crash, was the cause.

Agent Escalates to More Expensive Models for Tasks That Don't Require Them

Agent misses that action triggers notifications, billing, shipment, or deployment.

External APIs and Tools Fail, Causing Agent Errors

LLMs Fabricating or Misreading Values from Mortgage Documents

Agent Makes Unsupported Inferences

Model Cites Sources That Don't Exist

An Agent Generating a Client-Facing Fund Comparison or Recommendation Document Retrieves Most Required Disclosure Fields (Expense Ratio, Standardized Performance, Minimum Investment) From the Firm's Actual Fund Documents, but When Retrieval Misses One Specific Field for One Fund, Fills the Gap With a Plausible-Sounding Fabricated Number Rather Than Marking the Field as Unavailable

A Proactive Retention Agent That Calls a Usage-Analytics Tool to Determine Why a Customer Has Been Flagged as At-Risk of Churning Receives an Empty or Partial Result -- Because the Customer's Product Tier Is Not Instrumented for That Metric, or the Analytics Service Timed Out -- and Composes a Specific, Plausible-Sounding Usage-Decline Narrative ("You Haven't Logged In Since Early Last Month and Your Team's Usage Dropped 60%") to Justify the Outreach, Rather Than Stating the Actual Usage Data Was Unavailable

A retrieval system pulls a fact that is accurate on its own terms, but the qualifying context that makes it correctly applicable — the condition, population, or scope it was originally stated under — is dropped somewhere between the source document and the agent's final answer. The fact survives; the sentence or clause that scoped it does not, usually because chunking, summarization, or context-window truncation separated the fact from its qualifier.

An agent takes a fact that is true only under narrow, specific conditions — a particular study population, a specific product configuration, a specific regulatory jurisdiction — and presents it as a general truth applicable broadly. The source fact isn't misquoted; the error is in stripping away the scope that made it narrowly true and applying it as if it held universally.

An agent retrieves a fact correctly in terms of subject matter but reverses its direction or polarity — reporting "increases" when the source says "decreases," "improves" when the source says "worsens," or swapping which of two entities has the higher value. The topic and the entities involved are right; the relationship between them is flipped, which is often more damaging than an unrelated error because it's confidently stated and directionally opposite to the truth.

An agent drops, adds, or misplaces a negation while processing retrieved text, asserting the opposite of what the source actually states. Unlike a full directional inversion, this failure is specifically about negation words and constructions ("not," "no longer," "except," "unless," double negatives) being mishandled during retrieval, summarization, or paraphrase, producing a claim that reads fluently but contradicts the source on the single most important word in the sentence.

An agent presents a fact that is technically accurate as stated but omits a critical qualifier that would materially change how a user should act on it — not because the qualifier is missing from the source, but because it was dropped somewhere in retrieval or generation and the resulting statement, while not false, is misleadingly incomplete. This differs from a fabrication: every word the agent says checks out against the source, but the selective omission changes the practical meaning.

An agent retrieves a fact that was expressed by its source with explicit probabilistic or statistical framing — a likelihood, a confidence interval, a rate observed in a sample — and restates it as a flat, deterministic certainty, dropping the uncertainty that was integral to the original claim's meaning. The number or direction carried over is often correct; what's lost is the epistemic status of the claim, turning "this happens in about 30% of cases" into "this happens" or "this is what will happen."

An agent retrieves facts about two distinct entities — companies, people, products, or regulations — that share a similar name, and conflates attributes from one with the other in its response. The resulting statement is internally coherent and often partially correct, but attributes a fact that belongs to Entity A to Entity B, because retrieval matched on name similarity rather than correctly disambiguating which entity the query actually concerns.

An agent retrieves a fact that was true during a specific window of time and applies it outside that window, because the fact's temporal validity period was mishandled — the agent misattributes when the fact was true, or fails to notice that the fact is now outside its valid period. Unlike a stale cache issue, this is specifically about misreading or mismanaging the time-scoping of the fact itself: applying a 2019 regulatory limit as though it were still current in 2026, or applying a "current" fact to a past scenario the user is actually asking about.

Content-Generation Agent Includes Specific Statistics, Percentages, or Research Citations in Marketing Copy Without a Verification Step Confirming the Figures Are Accurate or the Cited Source Actually Says What the Copy Claims It Says

Model Recommends Factor Exposures Without Awareness of Market-Wide Crowding, Causing Correlated Unwind Risk

A failover mechanism does exactly what it's supposed to on the surface — it detects the primary's failure, promotes a standby, and traffic resumes flowing within the expected time — but the standby produces incorrect results once it's live. This is distinct from failover being slow (failover-delay-too-long) or losing data in flight (failover-data-loss): here the mechanics of the switch itself work, but the standby was running different code, stale configuration, an outdated model version, or an incomplete replica of reference data, so it silently serves wrong answers with full apparent availability.

When failover to a standby is triggered, writes that were in flight to the primary at the moment of failure — accepted by the client as successful, or in the process of being processed — never make it to the standby and are permanently lost. This is distinct from replication lag causing the standby to be generally behind (recovery-point-objective-miss is the measurement of that gap); this pattern is about the specific in-flight requests that were being processed at the exact instant of the failure, which fall into a gap between "already acknowledged to the client" and "durably replicated to the standby."

The failover mechanism eventually works — the standby is correct, no data is lost, no state is corrupted — but it takes materially longer to complete than the service's defined SLA or failover-time objective, extending customer-visible downtime well beyond what was promised or designed for. This is purely a timing failure: every other part of the failover (detection, promotion, correctness) can be functioning as designed, but the accumulated latency across detection, decision, and cutover steps blows through the target window.

During the process of transferring state to a failover instance — replicating in-memory session data, migrating an in-progress agent execution context, transferring a partially-written data structure — the state itself becomes corrupted in transit, so the standby comes up with internally inconsistent or malformed data rather than a clean (if slightly stale) copy. This differs from failover-data-loss (specific writes missing entirely) and failover-correctness-failure (standby running stale-but-internally-consistent code/config): here the transferred state is actively broken — partial objects, torn records, mismatched cross-references — because the transfer mechanism itself was not atomic or crash-safe.

Agent Proceeds Despite Ambiguity

OCR System Fails to Detect Fair Lending Compliance Concerns

Agent says done when action was not completed.

System Accepts User's Incorrect Assumptions

Agent Breaks Down Task Incorrectly

An agent calls a tool feature or API endpoint that exists and is documented, but the calling account's subscription tier doesn't actually include entitlement to it — the feature is gated behind a higher plan. The agent's tool-selection logic was built (or tested) against a fuller-featured tier and has no awareness that entitlements vary by account, so it attempts the call as a matter of course and only discovers the gap when the tool rejects the request, often deep into a multi-step task where a cheaper, entitled alternative was available but never considered.

A tool capability the agent's logic depends on is gated behind an account- or environment-level feature flag that the vendor has not enabled for this particular customer, tier, or region. The agent has no API-level way to check whether the flag is on before calling the feature, so it discovers the gap only when the call fails or silently no-ops, and the failure looks identical to a bug in the agent's own code rather than an environment configuration gap.

An operator flips a feature flag controlling agent behavior — for example, disabling a newly-launched tool that's producing bad outputs, or switching the active system-prompt variant — expecting the change to take effect immediately across the fleet. In reality, flag state propagates to running agent instances on a delay: some instances poll the flag service on an interval, some cache the value in memory for a TTL, some read it only once at process startup. For anywhere from tens of seconds to several minutes, different agent instances (and sometimes different requests within the same instance) are operating on inconsistent flag state, so some users get the old behavior and some get the new one simultaneously, and an emergency kill-switch doesn't actually stop the behavior it was meant to stop right away.

Feedback says 'bad' but not why.

Human Corrections Ignored in Subsequent Agent Decisions

Not enough signal to learn safely.

Text fields in most APIs have a maximum length — a ticket description capped at 4,000 characters, a product title capped at 200, a commit message capped at 72 characters for the summary line. When an agent generates the content for such a field with an LLM (a summary, a composed message, a generated description), the output length is not guaranteed to respect the target field's limit, since the generation step and the submission step are typically decoupled. The tool either rejects the write outright or, more insidiously, silently truncates the string mid-word or mid-sentence, producing corrupted or nonsensical stored content that the agent has no way of detecting from a success response alone.

A table or record type has some fields an agent should be permitted to see (e.g., order status, ticket subject) and others it shouldn't (e.g., internal margin, a customer's raw payment token), but the access-control system was built to grant or deny access at the record level only. Once an agent is authorized to read a record at all, every field on it — including the ones that were never meant to be exposed to that agent or context — comes along for free, because there's no enforcement point that operates below record granularity.

An Execution Agent Receives a "Filled" or "Success" Status From an Order-Management/Broker Tool and Narrates the Trade as Correctly Executed Based on That Status Alone, Without Comparing the Confirmation Payload's Own Symbol, Quantity, Side, and Price Fields Against the Order It Actually Submitted

ASR Misinterprets or Fails to Filter Conversational Fillers

Agent's Supplier Risk Monitoring Relies on Quarterly or Annual Financial Statements, Missing Faster-Moving Distress Signals That Precede a Supplier Failure by Months

Poisoned Training Data Causes Agent to Behave Maliciously or Unreliably After Fine-Tuning

Agent Doesn't Maintain Context Across Conversation Turns

AI System Fails to Detect Font Inconsistencies Indicating Document Tampering

Agent Appends Footnotes as Inline Text Instead of Linking Them to Their Reference

OCR System Fails to Detect Altered, Forged, or Fabricated Mortgage Documents

A Small Edit to a Source Document Triggers Full Re-Embedding/Re-Analysis of the Entire Document Instead of an Incremental Update to Just the Changed Portion

Data subject to geographic access or residency restrictions — most commonly EU personal data under GDPR, but also sector-specific rules like data-localization laws — is returned to an agent whose processing, storage, or invoking context sits outside the permitted region. This happens when the tool layer checks whether the requester is authorized in a general sense but doesn't verify that the specific data-residency or cross-border-transfer condition is also satisfied for that particular request.

Agent's Supplier Risk Score Is Based on Financial and Delivery-Performance History Alone, Missing Geopolitical Exposure That Has Not Yet Materialized as a Performance Problem

Agent Loses Focus on Original Objective

Agent's objective changes over long conversations or workflows.

Agent Gradually Modifies Its Own Goals or Learns Unintended Behaviors Over Time

Agent performs additional actions that were not requested.

Golden Dataset Missing Critical Scenarios or Edge Cases

Golden Dataset Contains Outdated Information or Expectations

Call Ends Awkwardly Without Natural Closure

A role is defined with fine-grained access — e.g. "read-only" or "can create tickets but not delete them" — but the tool wrapper the agent calls exposes the underlying API's full create/read/update/delete surface regardless of which operations the role is actually meant to permit. The agent, having no operation-level gate in the tool itself, can invoke update or delete through a tool nominally scoped to a narrower capability.

Citation Points to Wrong Level of Specificity

Agent Cannot Reconcile Conflicting Recommendations From Different Clinical Guideline Bodies and Defaults to an Arbitrary or Most-Recently-Retrieved Source

When an agent's external API call (validation, lookup, confirmation) times out or fails, the agent completes a plausible result claiming success instead of treating failure as a blocking condition; downstream systems trust the fabricated success status

Model Confidence Doesn't Match Answer Reliability (Hallucination Sub-Pattern)

Model Generates Information Not in Retrieved Documents

Model Hallucinates Object Attributes Not Present in Input

Large Language and Vision Models Generate Plausible but False Content

Model Hallucinates Objects or Fields Not Present in Input

An agent completes its portion of a multi-agent workflow and hands the remaining work to another agent, but no entity is ever explicitly marked as the owner of the outstanding task after the transfer. Both the sending agent and the receiving agent treat the handoff itself as the completion event, rather than the downstream task being resolved. The task sits in the receiving agent's queue, an inbox, or a shared work-item store with no active owner tracking it to completion, and it silently stalls.

A workflow is designed so that one agent must obtain sign-off from a human or a designated approval agent before handing a task to the next agent in the chain, but the handoff occurs without the gate being satisfied. This happens most often when the approval step is implemented as a soft convention rather than a hard dependency — the sending agent's code path can reach the handoff call whether or not the approval response was received, correct, or even requested. The receiving agent, having no way to know an approval was expected, proceeds to execute.

Two (or more) agents are each configured to hand off a task to the other under specific conditions, and those conditions form a cycle: Agent A decides the task needs Agent B's capability and hands it off, Agent B decides the task actually needs Agent A's capability and hands it back, and neither agent's handoff logic contains a way to recognize that the task has already been through this loop. The task bounces indefinitely (or until an unrelated resource limit like a timeout or step cap kills it) without either agent making progress on the underlying work.

When one agent hands a task to another, it passes along a summary or subset of the context it accumulated, rather than the full working state. The receiving agent then either proceeds on incomplete information (producing a subtly wrong result) or has to spend additional tool calls and turns re-deriving context the sending agent already had — re-reading source documents, re-querying an API, or asking the user to repeat information already provided upstream.

A handed-off task gets executed more than once because the handoff mechanism retries on a suspected failure (timeout, dropped acknowledgment, transient network error) without any way to detect that the receiving agent already processed the original attempt. The receiving agent has no concept of "I've seen this task ID before" and treats each retry as a fresh, independent instruction, resulting in duplicate side effects — a second email sent, a second charge issued, a second record created.

The sending agent hands off a task assuming the receiving agent has sufficient permissions to complete it, but the receiving agent actually operates under a narrower permission set — a different service account, a scoped API token, or a role with fewer grants. Rather than failing loudly, the task often degrades silently: the receiving agent's tool calls are denied or return partial results, and it either produces an incomplete output without flagging the gap or falls back to a lower-quality path that masks the permission problem entirely.

The sending agent packages a handoff using one version of the task schema (field names, required/optional fields, encoding conventions) while the receiving agent was built against a different version. The two versions overlap enough that the handoff doesn't fail outright — the receiving agent parses the payload without an error — but fields have been renamed, restructured, or reinterpreted between versions, so the receiving agent either misreads a field's meaning or silently drops fields it doesn't recognize.

After a task is handed off, the receiving agent fails partway through execution, and the workflow attempts to roll back to the pre-handoff state — but the rollback cannot be cleanly performed. This happens because the receiving agent has already taken irreversible or partially-irreversible actions (sent a message, committed a write, called an external API with a side effect), and no compensating action exists, or the sending agent no longer has the context or authority to undo what the receiver did.

Task state accumulated by the sending agent — intermediate results, partial progress, resolved variables, in-progress computation — fails to fully transfer to the receiving agent during a handoff. Unlike context incompleteness, where a summary deliberately omits detail, state loss is typically accidental: a serialization step drops fields, a transport mechanism truncates a payload, or the receiving agent initializes its own fresh state instead of loading the transferred one, and the task effectively restarts from a blank slate without anyone intending it to.

A task is handed off before the receiving agent is actually ready to accept it (it's still initializing, mid-way through another task, or hasn't started polling its queue yet), or after the receiving agent's window to act on it has already closed (a deadline passed, a session expired, an external resource is no longer available). In both directions, the handoff is transmitted successfully at the protocol level but arrives at the wrong moment for the receiver to do anything useful with it.

Edge cases are missing from tests.

Agent Interleaves Repeating Headers/Footers Into Body Content

An agent instance's health check oscillates rapidly between healthy and unhealthy — not because the instance is genuinely alternating between working and broken, but because the check itself is measuring something noisy near a hard threshold (e.g., LLM inference latency hovering right around a 2-second cutoff, or memory usage from a request-scoped context cache sawtoothing above and below a limit). Each flip triggers the orchestrator to pull the instance from rotation and then add it back, repeatedly, which causes constant partial-capacity loss, connection churn for any in-flight sessions on that instance, and load balancer/service-mesh reconfiguration overhead — all without the instance ever being reliably unhealthy or reliably healthy.

Agent Checks Prescription-Drug Interactions but Ignores Patient-Reported Supplements and Herbal Products

Agent Pressures Hesitant Callers Instead of Providing Low-Friction Options

Agent misses unstated but critical constraints such as policy, geography, role, or SLA.

An agent calls a tool whose advertised, per-call price is small or fixed, but the tool internally fans out to other billable services to fulfill the request — a "web search" call that triggers a paid image-recognition pass on every result thumbnail, or a "document lookup" that silently invokes an OCR sub-API for scanned PDFs. The agent's cost tracker only sees the price of the outer call, so its running budget total is systematically wrong, and the discrepancy is invisible until the vendor's actual invoice includes line items the agent never logged.

Support Ticket Routing Model Routes Complex Issues to Tier-1 (Auto-Response); Requires Escalation After Wasted Time

Agent Produces a "De-Identified" Summary, Research Extract, or Support Ticket That Still Contains Re-Identifiable Information

OCR System Incorrectly Extracts Data Required for HMDA Reporting

ASR Selects Wrong Word Among Sound-Alike Options

Poorly Calibrated Confidence Thresholds Flood the Review Queue

No Fallback When Required Approver Is Unavailable

Circumventing Human Approval Controls

Auto-Scaling Agent Doesn't Account for Cloud Provider Cold-Start Latency; Instances Take 2-5 Min to Start; Traffic Lost During Gap

Agent repeats a write action and creates duplicates.

Agent Can Be Manipulated Into Adopting Different Personas or Revealing Prompt

Model Fails to Detect Logical Contradictions Across Multiple Images

AI System Fails to Detect Manipulated Images in Documents

Agent Summarizes the Radiology Impression Line Without Reconciling It Against the Ordering Clinician's Stated Question or Prior Comparison Imaging

Agent Misses Unstated but Expected Aspects of Query

OCR Incorrectly Extracts or Calculates Borrower Income from Documents

AI System Fails to Reconcile Income Across Multiple Document Sources

Only Some Agent Actions Are Logged, Creating Blind Spots

Agent gives different answers across turns.

Agent recalls wrong past preference or fact.

Agent Waits Until All Fields Collected Before Saving Data

Agent Flags an Indemnification Clause as Present Without Evaluating Whether It Is Capped, Uncapped, or Mutual

Retrieved Documents Are Outdated

Malicious webpage/email/PDF/doc controls agent through retrieved content.

A response-cache or prompt-cache layer sits in front of (or inside) an inference service to avoid re-running expensive generation for repeated or overlapping requests, but the cache key strategy is too narrow — keying on the full raw prompt string including volatile elements like timestamps, session IDs, or reordered context chunks — so semantically identical or highly overlapping requests are treated as cache misses. The service pays full inference cost repeatedly for work it has effectively already done, and the cache exists in name only, contributing overhead without delivering the cost savings it was built for.

Unpredictable Model Inference Times

Agent Gets Stuck in Infinite Retry Loops

Agent Drafts or Summarizes Clinical Documentation Implying Informed Consent Was Obtained and Discussed in Detail That Was Not Actually Covered in the Encounter

Agent Propagates Errors from Sources or Tools

An agent receives an input payload with a missing or null field and silently substitutes what it assumes is a "safe" default (zero, empty string, current date, `false`, the first enum value) instead of treating the absence as an error or asking for clarification. The assumed default is often wrong for the specific business context — a missing `discount_percent` treated as `0` when it should have blocked the order, or a missing `region` treated as `"US"` when the request originated elsewhere — and the agent proceeds to act on that fabricated value as if it were provided.

An agent reads input bytes assuming one character encoding (typically UTF-8) while the actual source encoded the text differently (Latin-1/ISO-8859-1, Windows-1252, UTF-16, or a legacy code page), producing mojibake — visually garbled or silently wrong characters — in names, addresses, and free text. Because most bytes in Latin-1 and Windows-1252 are also valid (but differently-meaning) UTF-8 continuation sequences for a wide range of inputs, the decode frequently "succeeds" without throwing an error, so the corruption passes silently into storage and downstream processing.

An agent interprets a date, number, or currency value using the wrong locale convention — reading "03/04/2026" as March 4th when the source used day-month-year, or parsing "1.234,56" as one-point-two-three-four instead of one thousand two hundred thirty-four point five six. The value parses without error under the wrong locale's rules, so the agent proceeds confidently with a value that is silently different from what the source intended.

An agent accepts input containing embedded null bytes (`�`) — whether from malicious crafting, corrupted upstream data, or binary content misrouted into a text field — and passes it to a downstream layer (a C-based library, a filesystem call, a database driver, or a validation regex) whose string handling treats the null byte as a terminator. The agent's own validation logic sees the full string and approves it, but the consuming layer only sees the truncated prefix, creating a gap between what was validated and what was actually acted on.

An agent's parser (JSON, XML, YAML, or a custom nested-structure format) receives an input with excessive nesting depth — either from a legitimately complex source, a buggy upstream serializer that loops, or a deliberately crafted payload — and the recursive-descent parsing logic exceeds the language runtime's call-stack limit or the parser's own recursion guard, crashing the process rather than rejecting the input gracefully. Because the crash happens inside the parsing library itself, it often takes down the whole request-handling worker rather than failing just the one bad input.

An upstream system that feeds an agent changes its data schema — renaming a field, changing a type, adding a required field, deprecating an enum value — without a coordinated update to the agent's input parser, so the agent either silently misreads the new shape (treating a renamed field as missing and falling back to a default) or crashes on fields it no longer recognizes. Because the agent's own code didn't change, the failure looks like a regression with no corresponding commit, making it unusually hard to diagnose.

An agent accepts an input payload (a document, a file upload, a JSON body, an attachment) without checking its size against any reasonable bound before processing it, so an unusually large input — whether legitimate, accidental, or adversarial — is loaded fully into memory, tokenized in full, or passed whole into a downstream call, causing memory pressure, request-latency spikes, or costly API usage that a small size check would have caught in microseconds.

An agent's input parsing or downstream rendering logic breaks when the input contains characters with structural meaning in some layer of the pipeline — quotes, backslashes, delimiters (commas, pipes, tabs), markup characters (`<`, `>`, `&`), or control characters — and that layer wasn't written to treat them as literal data. A customer name containing an apostrophe, a product description containing a comma inside a CSV field, or free text containing an unescaped `<` breaks parsing, corrupts a field boundary, or renders incorrectly, independent of any encoding issue.

An agent receives a timestamp or time-of-day value with no explicit timezone, or with a timezone abbreviation that is genuinely ambiguous (e.g. "CST" meaning Central Standard Time or China Standard Time), and interprets it using an assumed timezone — usually the server's local time, UTC, or the timezone of whichever user the agent most recently interacted with — that doesn't match what the source actually meant. The resulting timestamp is a valid, well-formed datetime that is simply wrong by however many hours separate the assumed and actual timezones.

An agent's input validation rule checks the input's surface form (a regex, a length check, an allowlist match) but the check can be satisfied by an encoding, formatting, or representation variant that is semantically equivalent to a blocked value while syntactically different enough to slip past the check. Unicode homoglyphs, alternate encodings, case variations, whitespace insertion, or double-encoding let disallowed content — a blocked word, a malicious path, an injection payload — pass a validator that was written to catch only the literal, canonical form.

Downstream system executes unsanitized LLM output.

Agent Gradually Deviates from Original Instructions

Agent Actions Escape Intended Boundaries

Agent cannot undo a bad action.

An agent integrates with a third-party or internal service whose documented API contract specifies a particular response shape, status code semantics, or guaranteed behavior, but the service itself violates that contract in practice — returning a documented-as-required field as null, using a success status code for a partial failure, or exceeding its documented rate limits without the promised 429 response. The agent's integration code, written to trust the documented contract, mishandles the actual response because it never anticipated the provider's own inconsistency.

Multiple, ostensibly unrelated integrations share underlying infrastructure — a connection pool, a shared API gateway, a common authentication service, a rate-limited egress proxy — and a failure or degradation in that shared layer, triggered by problems with just one integration, propagates outward and takes down the others. An agent that assumes its integrations fail independently (and builds isolated fallback logic per integration) is caught off guard when a single root cause degrades several integrations at once, exhausting fallback capacity faster than expected or triggering compounding retries that make the shared resource contention worse.

Two integrated systems each maintain their own copy of what should be shared state — a CRM's "customer status" and a billing system's "account status," or an inventory system's stock count and an order system's reserved-stock count — and updates to one side don't reliably propagate to the other, whether due to a failed sync, a race condition between concurrent writes, or a missing update hook on one integration path. The agent, reading from whichever system it happens to query, acts on a view of "the" state that the other system would flatly contradict.

Different systems an agent integrates with signal failure through incompatible conventions — one returns HTTP error status codes, another embeds an error object inside a 200 OK response body, a third throws a language-level exception that a client SDK translates inconsistently, and a fourth simply omits expected fields on failure with no explicit error marker at all. Integration code written to detect failure one way (checking status codes) silently misses failures signaled another way (a 200 with an error payload), treating a failed operation as successful and proceeding as if it worked.

Two integrated systems model the same real-world concept using fundamentally different structures or semantics — one represents an address as a single free-text field, the other as five typed sub-fields; one treats a missing value as "unknown," the other as "explicitly empty"; one uses a flat list, the other a nested tree — and every call across the integration boundary requires a lossy or ambiguous translation between the two models. Unlike a one-time schema mismatch that a migration can fix, this is a standing structural incompatibility baked into how each system fundamentally represents the domain, so every single request/response pair pays a translation tax, and some translations are not fully recoverable in either direction.

An agent's workflow calls multiple external integrations where one system's call must complete and be acknowledged before another system's call is valid — a payment must be authorized before an inventory hold is placed, a user record must be created before a permissions grant references it — but nothing in the agent's orchestration logic encodes that ordering requirement as a hard constraint. When the agent parallelizes calls for latency, retries them independently after a partial failure, or is composed by an LLM planner that doesn't know the hidden sequencing rule, calls fire out of order and the downstream system either rejects the request against a resource that doesn't exist yet or, worse, silently accepts it and creates a dangling or orphaned record.

A single logical operation an agent performs fans out into calls against several independent downstream integrations, each with its own separately-published rate limit, and the agent's throughput planning accounts for at most one of them (usually the loudest or most recently hit limit) rather than the effective ceiling set by whichever integration is most constrained. Because none of the integrated systems know about each other's limits, and the agent's own rate-limiting logic is typically tuned per-integration rather than per-workflow, a request pattern that looks safe against every individual system's published limit can still produce compounding overload: a retry triggered by one system's 429 fans back out and re-hits every other system in the same operation, multiplying load precisely on the systems that weren't the original bottleneck.

An agent calls an external integration with a timeout shorter than the operation actually needs to complete on the far side, gives up and treats the call as failed, and then acts on that failure assumption — retrying, falling back, or notifying a user that the action didn't happen — while the original call is, in fact, still running to completion on the downstream system. When the downstream operation succeeds after the agent has already moved on, the agent's decision was made on stale information: it may issue a duplicate request (double-charging a payment, double-booking a resource), or it may leave the user with an incorrect "this failed" outcome for an action that actually succeeded. This is a correctness/state-consistency failure specific to one integration point, distinct from the broader dynamic where mismatched timeouts across a call chain amplify load system-wide.

Similar Intents Misclassified Due to Overlapping Definitions

Agent Misunderstands What User Wants to Accomplish

When two or more agents collaborate on a shared task but have persistently different response latencies — one calls a fast local model, another calls a slower remote API, or one has a heavier context to process — the faster agent either sits idle waiting on the slower one, or worse, proceeds to act on the slower agent's most recently available (and now stale) output rather than waiting for its current, in-flight result. Both outcomes degrade the collaboration: idle waiting wastes throughput, and acting on stale data produces decisions based on outdated information.

Agent misreads/transforms tool output incorrectly.

Agent Reveals Backend Operations, Routing Logic, or Internal Details

Agent Doesn't Properly Handle User Corrections and Interruptions

AI-Assisted Interview-Screening Agent Weights a Candidate's Vocal Confidence, Fluency, and Positive Sentiment in the Interview Transcript More Heavily Than the Substantive Correctness or Depth of Their Answers, Systematically Favoring Articulate-but-Shallow Candidates Over Substantively Strong but Less Polished Ones

Document Format Diversity Overwhelms Rule-Based Extraction

Agent Reviewing a Contractor or Consultant Agreement Confirms "IP Assignment Clause Present" Without Verifying It Actually Covers the Work Product Category at Issue

Query tools built on relational or graph data — GraphQL APIs, ORM-backed REST query endpoints, relational-API query builders — commonly cap how many joins or nested relations can be traversed in a single query, for example a maximum of 5 levels of nested relations. An agent that dynamically constructs a query to satisfy a broad information-gathering goal (e.g., "get the order, its customer, their company, the company's account manager, and that manager's team") can easily exceed this depth without realizing it, especially when the query is assembled programmatically by chaining relation names rather than authored by a person who would naturally notice the query getting unwieldy.

Retrieved Content From Wrong Jurisdiction or Context

Malicious Content Injected into RAG Data Sources

Support Agent Uses Outdated Knowledge Base; Gives Customers Incorrect or Outdated Information

An agent's retrieval step pulls two or more facts from different sources that directly contradict each other on the same question, and the agent proceeds to answer using one of them (often whichever appears first, scores marginally higher in relevance, or was retrieved last) without noticing, reconciling, or flagging the contradiction to the user. The user receives a confident single answer with no indication that the knowledge base itself disagrees on the point.

A knowledge base or cache stores facts indefinitely with no time-to-live (TTL) or expiration mechanism, so content that was accurate at ingestion time but has a known or implicit shelf life (prices, policies, personnel, regulatory limits) remains fully retrievable and presented with the same confidence as current content, indefinitely, unless someone manually removes or updates it. This is a systems-level gap rather than a per-fact error: the architecture itself has no concept of "this should stop being trusted after time T."

An agent applies a fact using an incorrectly assumed scope — the wrong jurisdiction, the wrong product version, the wrong organizational unit — because it never explicitly confirmed the scope the fact actually applies to versus the scope the user's situation is actually in. The fact is retrieved correctly and stated correctly for its true scope; the error is the silent assumption that the true scope matches the user's, when it may not.

A retrieval system treats every indexed source as equally trustworthy, with no mechanism to weight or rank content by the reliability of where it came from — an official, reviewed policy document is retrieved and used with exactly the same confidence as an unreviewed wiki page, a stale forum post, or a low-quality scraped page, simply because both matched the query with similar semantic relevance. When sources disagree or vary in quality, the system has no basis for preferring the more trustworthy one.

A source document explicitly scopes a fact with "as of" framing — "as of Q3 2025," "current as of the last policy revision," "prices shown are for the current promotional period" — but that framing is stripped during retrieval, summarization, or generation, leaving the agent's stated fact presented as timeless and universally current rather than tied to the specific moment the source actually anchored it to. The number or claim itself is preserved correctly; only the temporal anchor that made it interpretable is lost.

The system of record that an agent's knowledge base is supposed to reflect has been updated — a policy changed, a price changed, a product was discontinued — but the agent's indexed or cached copy has not caught up, because the ingestion/re-indexing pipeline runs on a cadence (scheduled batch job, manual trigger, event-driven pipeline with a backlog) that lags behind the actual rate of change at the source. The agent isn't wrong about what its knowledge base says; its knowledge base itself is behind reality.

An agent answers using knowledge tied to one version of a product, policy, or API — often the version most represented in its training data or knowledge base — while the user is actually working with a different version, and the two versions differ in ways that make the agent's answer wrong or actively harmful for the user's actual situation. The agent isn't confused about the fact itself; it's applying a fact that is correctly true for version N to a user who is on version N+1 or N-1, without checking or asking which version applies.

Agent Relies on a Customer's Initial KYC Risk Rating Without Triggering a Refresh When Materially Risk-Relevant Account Activity Changes

Agent Applies Generic Adult Reference Ranges to Lab Values Without Adjusting for Age, Sex, Pregnancy, or Assay-Specific Ranges

Golden Dataset Contains Incorrect Expected Responses

Agent Cannot Communicate Due to Unsupported or Incomprehensible Language

Agent Routes a Support Ticket Based on Detected Content Language Without Verifying Agent Team Language Coverage, Sending Non-English Tickets to English-Only Queues

A team facing a latency SLA responds by throwing more resources at the problem — larger batch sizes tuned down, more replicas kept warm, over-provisioned reserved capacity, or speculative/parallel decoding enabled everywhere — without measuring the cost curve those choices sit on. Latency and cost-per-token trade off against each other in inference serving (bigger batches lower cost but raise latency; more replicas lower latency but raise idle-capacity cost), and optimizing hard for one dimension without a stated budget for the other routinely produces a service that hits its latency target at 3-5x the cost a slightly relaxed target would have required, or conversely a service that's cheap but silently fails its latency SLA under real traffic.

A tool's documented latency SLA (e.g., "p99 under 500ms") is regularly exceeded in actual production traffic, and the agent's own timeout and retry logic — tuned to trust that documented figure — fires prematurely relative to the tool's real behavior, or conversely the agent's own downstream SLA commitment to its users gets breached because it inherited an unrealistic latency assumption from the upstream tool. Either way, the mismatch between advertised and actual latency propagates as a reliability problem that looks like the agent's own bug.

A multi-agent system that relies on one agent being designated "leader" or "coordinator" (to assign work, break ties, or serialize decisions) fails to establish or maintain a single clear leader. Either no agent successfully claims leadership, multiple agents each believe themselves to be leader simultaneously (split-brain), or leadership flaps rapidly between candidates, leaving the system without the coordination guarantee the architecture depends on.

Agent updates behavior based on incorrect/noisy feedback.

Model Underestimates Risk from Leverage; Recommends Leveraged Strategies Without Adequate Risk Buffer

Model Fails to Flag Dangerous Liability/Indemnification Clauses; Exposes Organization to Unquantified Risk

An agent keeps calling a tool whose license, API key, or subscription has expired, because nothing in the agent's control flow proactively tracks the license's validity period — it only finds out when a call fails. Between expiration and detection, the agent may continue attempting calls (wasting retries on a failure that cannot succeed), silently fall back to degraded behavior, or, in the worst case, keep reporting task success by misinterpreting a licensing rejection as some other recoverable condition.

Model Highly Sensitive to Lighting Conditions and Color Changes; Fails Under Different Illumination

Model Recommends Illiquid Assets; Prices Assumed Frictionless but Actual Bid-Ask Spreads Destroy Returns

Two or more agents, each trying to politely avoid conflicting with the other, keep changing their behavior in response to each other's changes without ever converging on a state where actual work gets done. Unlike deadlock, none of the agents are blocked or waiting — they are all actively "working," consuming compute and making API calls — but the net forward progress on the task stays at zero because each agent's reaction to the other keeps resetting the situation back to an equivalent unresolved state.

Agent Performs Root Cause Analysis Over Sampled Logs and Misses the Specific Log Lines That Explain a Rare but Critical Failure

In a long conversation, agent establishes constraints, decisions, or flags early (banned phrase, disqualified candidate, SLA exception, allergy, privilege determination), but as session grows, that information falls out of effective context window; agent later violates the constraint or re-makes the excluded decision

Model Uses Future Information in Backtest That Wouldn't Be Available in Real-Time Trading

Data Origin and Classification Lost During Processing

Agent Loses Track of Conversation State

Cannot Understand Why Agent Made Specific Decisions

Agent ignores tool warning/error and continues.

ASR Confidence Scores Not Used Effectively

Agent retrieves irrelevant chunks and synthesizes wrong answer.

Agent misses relevant documents.

Model Performance Collapses on Low-Resolution Images; Cannot Recognize Objects When Downsampled

Agent Selects a Pre-Written Macro/Canned Response Based on Surface Keyword Match Without Verifying It Actually Addresses the Customer's Specific Situation

Agent processes adversarial/weaponized documents or files.

Attacker Adds Malicious Tools to Agent's Available Toolset

Agent Sizes and Times Orders Without Accounting for Its Own Price Impact, Especially Across Correlated Positions or Repeated Trades

A field is designed to be masked or redacted before it reaches an agent — for example, a credit card number shown as `

Model Context Protocol Vulnerabilities Enable Remote Code Execution

Retrieved Memories Contradict Each Other

Two memories contradict; agent fails to resolve.

Agent's Long-Term Memory Becomes Corrupted

Individual entries in a persistent memory store can become corrupted — truncated writes from a crashed process, malformed JSON from a partial serialization, encoding mangling, or a bad migration that silently drops or garbles fields — and the retrieval path has no validation step that would catch this before the corrupted entry is handed to the agent. Instead of failing loudly, the agent receives a mangled fact, a broken embedding, or a record with fields swapped and treats it as valid input, often producing a confidently wrong answer that is harder to diagnose than an outright retrieval failure would have been.

Agent fails to forget information when requested.

As a memory store accumulates entries over months of operation — many small, partial, or redundant writes rather than clean consolidated records — the store fragments: the same underlying fact ends up spread across dozens of small entries, indexes grow disproportionately to the useful information they contain, and retrieval has to search, rank, and merge far more candidate records than the actual amount of distinct information warrants. Retrieval latency climbs and result quality drops, not because any single record is wrong, but because the signal is scattered across so many fragments that ranking and top-k selection can no longer reliably surface the most complete or relevant one.

An inference server's GPU has enough total free memory to serve a new request's KV-cache, but that free memory is scattered across many small, non-contiguous blocks left behind by requests of varying sequence lengths finishing and freeing memory at different times. The allocator can't satisfy the new request's contiguous-block requirement and either rejects it (a false-capacity-exhaustion error on a GPU that's nominally 40% free) or triggers an expensive defragmentation/compaction pass that stalls the whole batch — either way, the fleet needs more replicas than total memory usage alone would suggest, directly inflating cost-per-token.

When multiple agent instances or agent types share a common memory store — a customer-service agent and a billing agent both reading/writing facts about the same account, or multiple parallel worker agents in a fleet — they can each see a different view of "current" memory state at the same moment, because of replica lag, per-connection caching, or eventual-consistency propagation delays in the shared store. There is no single moment-in-time snapshot all agents agree on, so two agents acting concurrently on the same entity can make decisions based on genuinely different, both-locally-valid-but-mutually-inconsistent memory states.

When two writes to the same memory record happen concurrently and the storage layer performs a non-atomic read-modify-write cycle (read current value, apply an update in application code, write the result back), the two writes can interleave: both read the same starting state, both compute an update based on that stale starting state, and the second write to complete overwrites the first — or worse, a field-level race produces a record that mixes fragments of both updates, a state that neither writer ever intended and that doesn't correspond to either update applied cleanly. Unlike a full corrupted record from a crashed write, this is a "successfully" completed write that is nonetheless wrong because of the race.

An agent accumulates state — working memory, in-progress task tracking, session-scoped facts — purely in the host process's memory (a Python dict, an in-memory cache, an unpersisted object graph) without writing it to durable storage. When the process restarts — a deploy, a crash, an autoscaler recycling the instance, an out-of-memory kill — all of that state disappears instantly and irrecoverably, and the agent resumes (or a fresh instance picks up the workload) with no record that the state, or the work in progress, ever existed.

A memory write completes and is acknowledged as successful, but the read path the agent actually queries — a separate search index, a cache layer, a denormalized read table — has not yet been updated to reflect it, so the agent's next retrieval for that same fact returns the pre-update value even though the write, from the writer's point of view, already happened. This is a read-after-write consistency gap: the record of the update exists somewhere in the system, but not yet on the path the agent reads from, and neither the write nor the read reports any error.

Standard agent defenses (tool contracts, circuit breakers, I/O moderation, sandboxing) detect malicious actions but miss malicious beliefs; poisoned knowledge base instructions bypass all existing defenses because they appear to be normal context, not suspicious tool calls

Malicious or wrong content gets stored and later trusted.

Attackers inject malicious instructions into agent memory/knowledge base; 95%+ of attacks succeed in modifying agent behavior; existing defenses (tool contracts, circuit breakers, I/O moderation) fail to detect corrupted beliefs

A shared memory store's write path — a queue, a lock, a single-threaded writer — has no concept of write priority, so a burst of low-priority writes (verbose interaction logging, background enrichment, routine housekeeping updates) can occupy the write pipeline or hold a lock long enough that a high-priority write (a safety-relevant correction, a critical status update) queues behind them and is delayed well past when it was needed. The delay isn't caused by the high-priority write being slow itself — it's blocked waiting for unrelated, lower-value writes to clear ahead of it in a shared, priority-blind pipeline.

Memory intended to be scoped to a single user, tenant, or session leaks into a different user's, tenant's, or session's context — a shared vector index queried without a tenant filter, a session-ID collision, a caching layer that keys on the wrong scope, or a retrieval query broad enough to pull in another user's records because embeddings happen to be similar. The agent then surfaces one person's private facts, preferences, or history to someone else, without any error or access-denied signal, because from the retrieval system's point of view the query simply "worked" and returned relevant-looking results.

Agent uses private memory in inappropriate context.

A tool caps the memory available to a single operation (a container memory limit, a serverless function's configured RAM, an in-process buffer ceiling). When the agent sends a request whose payload or intermediate working set exceeds that ceiling — a large file upload, a wide JSON response being deserialized in full, a big in-memory join — the operation is killed by an out-of-memory (OOM) reaper and the failure surfaces to the agent as an opaque, non-specific error rather than a clear "payload too large for allocated memory" message.

Relevant Memories Not Retrieved When Needed

When long-term memory is compacted to fit a fixed storage or retrieval-token budget — a periodic "condense this user's history into a compact profile" job, rather than the cascading multi-pass summarization that produces summary drift — the single compaction pass must decide what to keep and what to discard under that budget, and it systematically drops details that appear low-value at compaction time but turn out to be exactly what a later query needs. Unlike summary drift, where quality degrades across repeated re-summarization cycles, this is a one-time, budget-driven compression choice: the loss happens once, at the moment of compaction, because the summarizer has no way to know in advance which details a future query will actually require.

Agent Flattens Spanning Headers and Merged Cells Into a Grid, Destroying Parent-Child Structure

Wrong date, version, region, product, role, or policy filter.

Filters Exclude Relevant Documents

AI System Fails to Detect Document Dates Inconsistent with File Metadata

Monitoring System Creates High-Cardinality Metrics (Unbounded Labels); Storage & Performance Collapse

Agent learns to satisfy eval wording instead of real behavior.

Agent optimizes CSAT/conversion while violating policy or quality.

A Routing Agent That Re-Runs Full-Context Intent Classification on Every New Customer Message Silently Reassigns a Ticket Already Claimed and Being Worked by a Human Agent, Because Growing Conversation Context Shifts the Classification Output Without Any Check on the Ticket's Current Ownership State

Citation Exists But Doesn't Support the Claim

Agent's output space has no low-friction "insufficient information, cannot answer" option, so it produces a best-guess answer even when grounding is inadequate.

Team builds a custom eval harness (a handful of manually-written test prompts checked by eyeballing the output) instead of adopting an established agent/RAG evaluation framework, missing standardized metrics and automatic test-case generation.

Workflow Lacks Required Approval Step for High-Risk Action

Agent Actions Not Recorded for Later Review or Compliance

Claims Made Without Attribution

Team tracks LLM spend via manual log scraping or spreadsheet exports instead of adopting an established gateway/observability framework, losing real-time budget enforcement and per-call cost attribution.

Model Handles Missing Data Incorrectly (Mean Imputation, Deletion); Introduces Bias or Information Loss

Request Flows Through Multiple Components Without Unified Trace Context

Agent Fails Completely When Dependency Unavailable Instead of Degrading Gracefully

Agent fails to use relevant durable information.

Team relies on ad-hoc regex or manual review for PII detection/redaction instead of adopting an established, maintained framework, missing entity types and edge cases the framework would catch by default.

Agent skips required validation, lookup, permission, or confirmation.

System prompt instructions are the only defense against prompt injection and unsafe output, with no established guardrails/scanning framework wired in front of or behind the model call.

Team builds a bespoke retrieval pipeline (custom chunking, custom vector store glue, custom prompt assembly) from scratch instead of adopting an established RAG framework, missing built-in chunking strategies, retrieval orchestration, and evaluation tooling that ship by default.

Agent omits ID, date range, filter, auth scope, or tenant.

Agent Omits Required Tool Parameters

Agent outputs, logs, and tool-call payloads are never scanned by an automated secrets/credential-detection framework, relying on manual review (or nothing) to catch API keys and tokens before they're persisted or displayed.

Agent skips a beneficial critique/revise pass on a high-stakes output, going straight to a single-shot answer where a reflection round would demonstrably have caught an error.

Compliance Agent Approves Marketing Copy Containing a Comparative or Superiority Claim Without Verifying That Adequate Substantiation Exists or Is Cited

Agent stays on generic frontier-model prompting for a high-volume, narrow, repetitive task long after fine-tuning or distillation would outperform it on both cost and quality.

Events Logged Without Accurate Timing Information

Two or more concurrent A/B tests, each rolling out a different model version or configuration to a cohort of users, overlap in ways their designers didn't account for — a user gets assigned to conflicting cohorts across tests, or a shared downstream system (a cache, a session, a fine-tuned classifier) is implicitly tuned for one test's model and breaks for the other's. The result is inconsistent user-facing behavior that isn't explained by either experiment's own design, and that neither experiment's metrics dashboard is set up to detect since each only tracks its own cohort in isolation.

A provider ships a new model version, the team's existing evaluation suite passes it (or the update is adopted without a full re-run), and a real behavior regression on a specific task type ships to production undetected — because the eval suite doesn't cover that task type, uses stale test cases the new model has effectively memorized, or measures aggregate pass rate in a way that dilutes a regression concentrated in one narrow slice of traffic. The team only learns about the regression from user complaints or downstream error spikes, well after the update is already serving all production traffic.

A routing layer selects a model for a task without verifying that the model actually supports a capability the task requires — vision input, function/tool calling, a long enough context window, structured output mode — and the mismatch is discovered only when the call fails or, worse, silently ignores the unsupported input. Routers optimized for cost or latency often select on those axes alone, treating capability support as a given rather than a routing constraint to check.

An agent hands a task to the underlying model whose combined complexity — number of constraints, depth of multi-step reasoning, size of working set held "in mind" across a long tool-calling loop — exceeds what that model can reliably handle in a single pass. Unlike a hard error, the failure is silent: the model still produces a fluent, well-formatted answer, but it drops constraints, skips reasoning steps, or produces a plausible-looking but wrong result. Nothing in the response signals that the task was too much for the model.

Generator Produces Repetitive, Low-Diversity Outputs (Mode Collapse)

A team quantizes or distills a model specifically to cut inference cost (smaller weights, faster kernels, cheaper hardware) and validates the change against an aggregate quality benchmark that looks acceptable, but the compression technique degrades a specific capability disproportionately — long-context recall, numerical precision, rare-token/tail-vocabulary generation, or multi-step tool-calling reliability — that the aggregate benchmark doesn't isolate. The compressed model ships, the cost savings materialize as planned, but a narrow slice of production traffic silently gets worse outputs, and the hidden quality cost (rework, escalations, lost trust) offsets or exceeds the infrastructure savings.

As an agent's conversation or retrieved context grows toward the model's context window limit, the model's behavior shifts in ways that are never announced: recall of early-turn facts degrades, instruction-following becomes less reliable, and the model increasingly favors recently-seen tokens over earlier ones ("recency bias"). Because the API returns a normal, well-formed response at every context length, the agent has no signal that it just crossed into a degraded-quality regime.

Input causes excessive cost/latency or service exhaustion.

A cost-optimizing router automatically shifts traffic from a higher-quality (and higher-cost) model to a cheaper one — based on budget pressure, rate limits, or a tuning change — without any mechanism to measure or surface the resulting quality impact. The downgrade is deliberate and often reasonable as a cost decision, but it is invisible: no dashboard, alert, or user-facing signal distinguishes "answered by the model we validated for this task" from "answered by a cheaper substitute picked to save money."