AI agent tool misuse and tool-calling failures — wrong tool, bad parameters, invocation errors
257 patterns
AI agent tool misuse and tool-calling failures — wrong tool, bad parameters, invocation errors. We've tracked 257 distinct Tool Misuse patterns across production AI agent deployments — most commonly in Operations, Security, Governance systems. One recurring example: Agent Fabricates Plausible Tool Output When Risk-Engine Tool Call Times Out — 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 R…
Each pattern below documents the specific failure mode, why it happens, and how teams have mitigated it in practice — use this page as a reference when building guardrails, writing evals, or debugging an agent that's already misbehaving in this way.
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
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
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"
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.
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.
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
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
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
AI Fraud Detection Fails to Identify Documents Created with Generative AI Tools
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 passes unsafe user/tool input into shell/API commands.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
The agent retries a write-type tool call after a timeout or ambiguous error and ends up creating duplicate tickets, emails, orders, or charges.
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.
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.
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.
External APIs and Tools Fail, Causing Agent Errors
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
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.
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
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.
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.
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.
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.
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.
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.
Agent repeats a write action and creates duplicates.
Agent Propagates Errors from Sources or Tools
Agent misreads/transforms tool output incorrectly.
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.
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.
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.
Agent ignores tool warning/error and continues.
Attacker Adds Malicious Tools to Agent's Available Toolset
A field is designed to be masked or redacted before it reaches an agent — for example, a credit card number shown as `
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
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 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.
Agent Omits Required Tool Parameters
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 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.
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.
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.
A router selects a model version that doesn't support a specific feature the calling code assumes is available — a particular tool-calling schema format, a structured-output mode, a system-message convention, or a token/parameter that a newer or older version handles differently — causing the call to fail, silently ignore part of the request, or behave unexpectedly. The mismatch arises because routing logic treats models within a family as interchangeable by name/cost/latency, without tracking per-version feature support as a routing constraint.
Many tools reject JSON or other structured payloads once object/array nesting exceeds a fixed depth — commonly somewhere between 10 and 32 levels — to protect their parsers from stack-exhaustion and pathological-input attacks. Agents that build payloads through recursive composition (e.g., chaining tool outputs into a nested config object, recursively expanding a tree-shaped data structure, or composing several sub-tool results into a wrapper object) can produce structures that grow deeper than intended without any single step looking unusual, because the depth accumulates across composition steps that the agent reasons about independently rather than as a whole.
Prompt injection/malformed input/tool errors not tested.
Prompt/tool/model changes go live without review.
Agent jumps into tool calls or actions without decomposing the workflow.
Cannot revert bad prompt/model/tool changes quickly.
Agent treats symptom as cause: prompt vs retrieval vs tool vs policy.
External model/tool vendors create unmanaged risk.
An agent constructs a downstream command, query, or markup document by directly interpolating its own generated text (or text derived from user/tool input the agent passed through) into a SQL statement, shell command, or HTML page without parameterization or escaping. Because the interpolated content can contain characters with special meaning in the target language, it can alter the structure of the command rather than being treated as inert data — the classic injection pattern, but with the agent's own generated or relayed text as the injection vector instead of a raw user form field.
Agent Misunderstands Tool Response
Agent Makes Errors When Processing Tool Results
An agent's generated output — a chat completion, a streamed response, or a payload returned from a tool call — gets cut off mid-generation or mid-transmission (hitting a `max_tokens` cap, a proxy timeout, a streaming connection drop, or an intermediate buffer limit), and nothing in the pipeline detects or flags that the content is incomplete. The truncated fragment is syntactically plausible enough (a sentence that just stops, or JSON that's missing its closing braces) that it gets parsed, stored, or displayed as if it were the complete, intended output, rather than triggering a retry or an explicit incompleteness signal.
Agent retrieves too much data and reasons over irrelevant records.
Agent misses correct data due to overly strict filters.
Before performing a mutating action on a specific resource (cancel this subscription, delete this file, update this profile), the agent authenticates that a valid user is making the request but never verifies that this specific user is the owner or authorized party for this specific resource. Any authenticated user can therefore direct the agent to mutate resources belonging to someone else simply by supplying that resource's identifier.
Agent Reads Only the First Page of a Paginated or Length-Capped Tool Response and Proceeds as if That Page Were the Complete Result Set
An agent calls a tool capability that appears functionally identical to other calls in the same API, but is actually billed as a paid add-on with per-call or tiered pricing that isn't surfaced anywhere in the API response, error messages, or the agent's own logic. The agent has no cost-awareness built in, so it calls the feature as often as its workflow logic dictates, and the financial impact is only discovered when the bill arrives — often after the feature has been in heavy use for a full billing cycle.
Agent Passes Wrong Parameter Types to Tools
An SEO Agent's Call to a Rank-Tracking or Site-Search-Console Tool, Made to Confirm a Newly Drafted Page Will Not Cannibalize an Existing Page's Rankings for the Same Target Keyword, Times Out or Returns a Partial Result Covering Only Some of the Queried Keywords, and the Agent Reports the Cannibalization Check as Passed Rather Than Flagging the Response as Incomplete
Agent treats partial/incomplete output as complete.
An Agent Calls a Structured EHR/FHIR Tool to Retrieve a Patient's Latest Lab Results, and Because the Underlying Record System Has a Duplicate or Merged Medical-Record-Number Entry, the Returned Payload Belongs to a Different Patient; the Agent Treats the Tool's Structured Response as Ground Truth and Interprets the Wrong Patient's Values Without Cross-Checking the Payload's Own Patient Identifiers Against the Request
A tool vendor prices calls at a low baseline rate up to a sustained throughput threshold (e.g. 10 requests/second) but charges a significant premium — sometimes 5-10x — for requests above that threshold within a billing window. An agent's retry-with-backoff logic, built purely to handle rate-limit errors or transient failures, resubmits requests in tight clusters after a failure or during a burst of user activity, pushing throughput over the baseline and triggering premium billing that the agent's cost model never anticipated because it only models the advertised baseline rate.
A tool enforces a short-window burst limit (e.g., no more than 5 requests in any 1-second window) that is much tighter than its sustained rate limit (e.g., 300 requests/minute). An agent orchestrating parallel sub-agent fan-out — say, dispatching 15 research sub-agents that each immediately call the same search tool the instant they spawn — blows through the burst ceiling in the first second even though the resulting sustained average is comfortably under the per-minute quota.
A tool's backend enforces a hard cap on the number of simultaneous open connections per account or API key (common with database connectors, legacy SOAP/XML-RPC services, and some SaaS APIs built on connection-oriented protocols). When an agent's orchestrator executes multiple sub-tasks in parallel, each holding open its own connection to the same tool for the duration of a long-running call, the agent can open more concurrent connections than the vendor allows — and unlike a request-rate limit, this failure mode has nothing to do with how many requests per second are being sent, only how many are open at once.
A tool's real price varies by operation type or payload characteristics — a "transcription" call costs more per minute of audio than the flat per-call estimate assumes, or a "document analysis" call is priced per page or per KB rather than per request — but the agent's cost estimator uses a single average or flat per-call figure. When the actual mix of operations skews toward the expensive end (longer audio, bigger documents, more complex queries), realized spend diverges sharply from the budget the agent believed it was operating within.
A tool has a fixed daily budget cap, and normal usage patterns (a morning traffic spike, a batch job front-loaded early in the day) exhaust it well before the day ends. The agent has no fallback tool, no degraded mode, and no queuing strategy for when the cap is hit — it either starts failing every task that needs the tool, or silently stops calling it and produces lower-quality output without telling anyone, for the remaining hours of the day.
A tool rejects any request beyond N simultaneously in-flight requests per account, regardless of connection count or overall request rate — a request-level concurrency cap rather than a connection-level or rate-based one. An agent orchestrator that dispatches parallel tool calls without an explicit concurrency throttle routinely exceeds this in-flight limit during fan-out, causing a wave of immediate rejections that has nothing to do with total volume or open connections.
A vendor contract commits the organization to a minimum monthly usage tier (e.g. "at least 100,000 calls/month or pay for 100,000 regardless"), and an agent's cost-optimization logic — designed to minimize call volume by caching aggressively, batching requests, or routing to a cheaper alternative tool when possible — reduces usage below that committed tier. The effective cost per call actually made goes up, because the fixed minimum fee is now spread across fewer calls, even though every individual optimization looked correct in isolation.
Monthly spend tracking for a tool relies on vendor-reported usage or billing data that lags real-time by hours to days — usage dashboards update once daily, or invoices are only finalized at month-close. By the time anyone (human or automated system) detects that the monthly budget has been exceeded, the agent has continued making calls against the stale "still within budget" reading for however long the reporting lag lasted, often turning a modest overage into a large one.
A tool enforces a hard daily request quota (e.g., 1,000 calls/day on a free or standard tier), and the agent has no visibility into how much of that quota remains as the day progresses. Because the agent paces its usage without any remaining-quota signal, it can burn through the full day's allotment in the first few hours of heavy activity, leaving the tool completely unavailable for the remainder of the day regardless of how important later calls are.
A tool enforces an hourly request quota, and an agent whose usage is bursty within the hour — heavy activity in a 10-minute window followed by relative quiet — exceeds the hourly cap even though its average request rate across the full day is well within budget. Unlike a daily quota, the hourly window resets often enough that the failure is usually short-lived, but frequent enough (potentially every hour) to meaningfully degrade throughput if the agent's traffic pattern is inherently spiky.
A tool enforces a per-minute rate limit, and the agent hits it during a tight retry loop: an initial call fails or is slow, the agent retries immediately without backoff, and each retry itself consumes another slot against the same per-minute budget — compounding the original problem instead of resolving it. What starts as one transient failure turns into a cascade of rate-limit rejections that persists well past whatever caused the first failure.
A tool vendor prices calls on a volume-tiered schedule — for example $0.05/call for the first 10,000 calls/month, dropping to $0.03/call from 10,001-50,000, and $0.015/call above that — but the agent has no visibility into which tier its current usage falls into. Without that knowledge, the agent can't make batching or scheduling decisions that would push usage into a cheaper tier, and in some cases actively spreads or throttles calls in ways that keep usage stuck in an expensive lower tier when consolidating the same volume would have unlocked meaningfully cheaper pricing.
Permissions in a hierarchical system are meant to narrow as they cascade down (an org-level admin has broad rights, a team-level member has fewer, a specific user within that team has only what's explicitly granted), but the agent's logic for resolving effective permission at a given level applies the wrong tier's rules — either inheriting a broader ancestor permission that should have been narrowed, or failing to inherit a permission that should have propagated down, resulting in over- or under-granted access.
A tool call returns personally identifiable information (name, email, phone, home address, date of birth) that wasn't necessary for the task the agent was performing and wasn't supposed to be exposed to that agent or context at all. Unlike a masking or classification failure, the PII here isn't hidden behind any control — it's simply present in the default response shape of a tool because the tool was designed to return "the whole object" rather than the minimum fields the task requires, and the agent (and anything downstream of it, including logs and conversation history) now has that PII whether it needed it or not.
PII is correctly scrubbed or redacted from a tool's primary, well-tested response path, but leaks through a secondary channel the same tool call touches — an error message that echoes back invalid input, a stack trace surfaced when a downstream call fails, a nested or joined object included for context that wasn't covered by the redaction filter, or a debug/verbose field left enabled in production. The agent then reads that secondary channel as part of its normal error-handling or context-gathering behavior and surfaces the leaked PII to the user, having no way to know it wasn't supposed to be there.
Personally identifiable information collected or processed by an agent through a tool call — a support transcript, a form submission, an uploaded document — is subject to a policy-defined maximum retention period, after which it's supposed to be automatically deleted or anonymized. No automated expiry mechanism actually enforces that period; the data simply persists in whatever store the tool wrote it to until someone manually notices and removes it, which in practice rarely or never happens.
Agent invents tools, data, permissions, or workflow steps.
The planning step generates a plan that references a tool, API endpoint, file, or capability that does not actually exist — invented because it sounds plausible given the task description, not because the planner verified it against the real set of available tools. Because there is no validation step checking each planned action against the actual tool registry before execution begins, the hallucinated step isn't caught until the executor tries to invoke it and fails, or worse, silently matches it to the wrong real tool with a similar name.
A planner explicitly optimizes a plan against a proxy objective — fewest steps, lowest estimated cost, fewest tool calls, shortest estimated time — and produces a plan that scores well on that objective while being degenerate, unsafe, or nonsensical with respect to the actual goal. Because the optimization process only sees the proxy metric, it finds and exploits shortcuts the metric doesn't penalize: merging steps that shouldn't be merged, batching a destructive action to save a round trip, or looping a cheap no-op action because it locally minimizes the objective function per unit of apparent progress. The plan is technically "optimal" and structurally valid, but pursuing the metric has traded away something the metric didn't capture.
A tool connector or plugin only officially supports specific combinations of host platform version and tool/API version — a compatibility matrix the vendor publishes but that the agent's deployment doesn't actively validate against. When the deployment environment drifts outside that supported matrix (a platform upgrade, a plugin auto-update, a tool-side version bump), the integration doesn't necessarily fail outright — it often keeps running with subtle, partial breakage that's far harder to diagnose than a clean failure.
AI agent performs an action its tool permissions allow but that violates business or regulatory policy.
An agent depends on an ML-powered tool (a classifier, a recommendation engine, a scoring API) whose underlying model the vendor updates server-side — a retraining, a new model version rollout, a fine-tuning change. Because the API contract (request/response shape) usually stays the same across a model update, nothing about the integration breaks; the model simply starts producing systematically different, and sometimes measurably worse, predictions for the agent's specific use case, with no changelog entry, version number bump, or notification distinguishing "same API, different model behavior underneath."
A Stable Prompt Prefix (System Prompt, Tool Schemas, Few-Shot Examples) Is Retransmitted and Rebilled at Full Price on Every Call Instead of Using Available Prompt-Caching
Query tools that support flexible field selection — most notably GraphQL APIs — often score each incoming query for computational cost (a function of field count, list multipliers, and nesting) and reject any query above a threshold, independent of raw depth or byte size. An agent auto-generating a query to fulfill a broad request ("get me everything about this customer") can easily construct a query that is shallow and small in text but scores extremely high in complexity, because a handful of fields that each return large lists multiply together into a cost the agent has no way to estimate from the query text alone.
Before a complex query ever executes, the tool's query planner (a database optimizer, a GraphQL resolver-planning phase, a distributed-query coordinator) has to determine an execution strategy — and for sufficiently complex queries, this planning phase itself can time out, independent of and prior to any execution timeout. This produces a distinct failure class from an execution timeout: the query never ran at all, no partial work was done, and no rows were touched, yet the error returned to the agent often looks identical to a generic timeout, so the agent's error handling treats it the same as a slow-but-progressing query and applies the wrong recovery strategy.
A Quota-Achievement Agent Authorized to Auto-Apply Routine Split-Credit Adjustments Between Reps on Co-Sold Deals Calls the Internal Crediting Tool, Receives a Response, and Applies an Adjustment to Both Reps' Quota-Attainment Records Without Checking Whether the Tool's Response Actually Confirmed the Adjustment Succeeded for Both Reps or Only One, Silently Treating a Partial-Success Response as a Full Success and Crediting One Rep While Leaving the Other's Record Unadjusted and Unflagged
Multiple instances of an agent (or multiple sub-agents sharing one API key) send requests right around a quota window's reset boundary, and because clock synchronization between the agent fleet and the vendor's rate-limit accounting is imperfect, the enforcement becomes inconsistent at exactly the moment it should be cleanest: some requests sent a few milliseconds before the reset are counted against the new window, some sent a few milliseconds after are still counted against the old (exhausted) one, and different agent instances observe different outcomes for functionally identical timing.
A single logical operation — a multi-step workflow, a paginated data pull, or a batch job that makes many sequential tool calls — spans a quota reset boundary partway through. The calls made before the reset count against the old window, the calls made after count against the new one, and because the agent tracks the operation as one atomic unit but the vendor tracks quota in two disjoint windows, the two views of "how much budget is left" fall out of sync mid-operation, sometimes causing the tail of the operation to fail even though a fresh reset "should" have provided plenty of headroom.
A tool enforces a quota (daily, hourly, or otherwise) but the vendor does not precisely document when the window resets — the docs might say "resets daily" without specifying a time zone, or "rolling window" without specifying the exact rolling mechanism. Without a precise reset time, the agent cannot safely schedule retries or backoff near the boundary: it either retries too early (wasting an attempt against a still-exhausted quota) or waits too conservatively long (leaving the tool idle for extra time after it actually became available again).
Some tools enforce rate limits with zero grace period: the moment a request is rejected with a 429, the very next request — even one sent a fraction of a second later, even one that would normally be well within budget — is also immediately rejected, with no brief cooldown signal or soft-warning phase before the hard cutoff. Agents that respond to the first 429 by retrying quickly (assuming a brief backoff is enough) get rejected again immediately, and if their backoff strategy isn't tuned for a limit with no forgiveness, this produces a tight loop of rapid-fire failures instead of a clean recovery.
A tool returns standard or vendor-specific rate-limit headers on every response (e.g., `X-RateLimit-Remaining`, `X-RateLimit-Reset`, `Retry-After`) that would let the agent pace itself proactively and avoid ever hitting a hard rejection — but the agent's HTTP client or tool wrapper doesn't parse or act on them. The agent keeps calling at its own fixed cadence until it eventually gets rejected outright, throwing away information the vendor was actively handing it for free.
Agent fails silently or retries destructively after API limit/timeout.
An agent is deliberately provisioned with read-only access to a data source — the intent being it can look things up but never modify anything — yet a misconfigured tool binding, an overly broad service credential, or an undocumented fallback code path still allows write operations to succeed. The read-only boundary exists in configuration or documentation but isn't actually enforced at the point where the write would occur.
An agent is correctly granted access to a tool or table in general — it's allowed to call "get ticket" or "list documents" — but the underlying implementation doesn't check whether the specific record being requested actually belongs to, or is otherwise authorized for, the requesting user or context. Because the tool-level grant is real and the agent is "supposed" to be able to use this tool, the missing per-record ownership check is easy to overlook: every individual call looks legitimate, and only in aggregate does it become clear the agent can read (and sometimes write) any record in the table, not just the ones it should.
Before executing a write, update, or delete via a tool, the agent doesn't verify that the current user is actually the owner of, or otherwise authorized to modify, the specific record being targeted. The write succeeds because the tool checks that the agent/user has general permission to call the "update" endpoint, but never re-confirms that the particular record ID supplied belongs to that user — turning a routine "update my profile" or "cancel my order" request into a capability to modify anyone's record, simply by supplying a different ID.
An agent depends on a tool capability that is only available in certain geographic regions — often due to data residency law, licensing agreements, or a vendor's staged global rollout — while the agent's deployment runs in or serves users from a region where the feature isn't offered. Because development and testing typically happen from a single region (usually wherever the engineering team is based), the gap is invisible in testing and only appears once the agent is exercised against traffic or infrastructure in the unsupported region.
A single generation call falls into repeated phrases, loops, or degenerate text (distinct from repeating tool-call actions across turns) because no repetition/frequency penalty or diversity control is applied to open-ended output.
Tools commonly cap the total byte size of a single request — a common ceiling is 1MB, 6MB, or 10MB depending on the platform — independent of any per-field or per-item limits. An agent that builds a request body from accumulated context (conversation history, retrieved documents, concatenated tool outputs, embedded file attachments) can exceed this ceiling even when every individual field is reasonable in isolation, because the agent's context-accumulation logic tracks relevance and completeness, not cumulative serialized byte size against the specific tool being called next.
Some tools enforce a hard request timeout with no partial-result mechanism: if the operation isn't fully complete when the clock runs out, the connection is simply dropped and any work done up to that point is discarded rather than returned. An agent that issues a single long-running call (a large data export, a bulk transformation, a synchronous report generation) against such a tool loses all progress when the timeout fires, and — because the response is indistinguishable from other connection failures — the agent typically retries the entire operation from scratch rather than recognizing that the work needs to be restructured into smaller, checkpointable steps.
An external API the agent depends on introduces a new required field in its request schema — often as part of a routine vendor update, a compliance requirement, or a new feature rollout — and every existing call the agent makes, built against the prior schema, starts failing validation because the field is absent. Unlike a breaking removal or rename, this failure mode is easy for the vendor to consider "backward compatible" from their side (old fields still work, nothing was removed), while it silently breaks every caller that doesn't proactively track schema changes.
Tools that return large result sets — search results, exports, list endpoints without server-driven pagination — often cap or silently truncate the response payload above a certain size, and critically, this truncation frequently happens without a clear error or a truncation flag in the response body. An agent that reads such a response, parses whatever JSON or text made it through, and proceeds treats a partial result as the complete answer, leading to decisions, summaries, or downstream actions based on missing data with no indication anything was cut off.
An agent is assigned a role intended to convey a specific level of access (e.g. "support-tier-1"), but the mapping from that role to the underlying tool's actual permission model is incomplete, outdated, or was translated incorrectly during integration — so the agent ends up able to do meaningfully more, or less, than the role's name and documentation suggest. Unlike a missing check, the check exists and runs; it's the mapping table itself that's wrong.
An agent platform rolls back its application code to a prior version after a bad release, but the data the new version wrote during the time it was live — new conversation-state fields, a changed tool-call log schema, session records referencing a memory format the old code doesn't understand — is not rolled back along with it. The old code comes back up and immediately encounters data shapes it was never written to handle, either crashing on deserialization, silently dropping fields it doesn't recognize, or misinterpreting a repurposed field, producing corrupted or nonsensical agent behavior that looks like a new bug rather than the direct consequence of the rollback itself.
The agent's pacing logic assumes a tool's quota resets at a fixed clock boundary, when the tool actually enforces a rolling/sliding window that never resets all at once. Quota consumed at any given moment doesn't free up until exactly that much time has elapsed since it was consumed, continuously, rather than all at once at a fixed reset point. Because the agent's scheduling strategy is built around a reset-and-refill mental model, it either waits far longer than necessary for capacity to return, or assumes capacity is available at a "reset time" that doesn't actually exist for a rolling window.
Tool Schema Changes Break Agent
A delegated or sub-agent spawned by a parent agent is designed to receive a narrower permission scope than its parent — for example, a research sub-agent that should only have read access to a specific document set, spawned by an orchestrator agent with broad workspace access. But the mechanism that's supposed to enforce that narrower scope (a new, restricted credential; a filtered tool set; a scoped session token) either isn't actually applied or is applied only cosmetically, so the sub-agent retains the parent's full underlying access even though its declared, intended scope is much smaller.
The client SDK an agent uses to call a tool falls out of sync with the tool's current server-side API version — because the SDK wasn't updated after a server-side change, or because a dependency pin locked the agent to an old SDK release. Requests and responses that used to serialize and authenticate correctly begin failing in ways that look like network or auth problems (malformed request errors, signature mismatches, unexpected field types) rather than clearly indicating "your client library is out of date."
API keys/tokens/private URLs leak through answer/log/tool.
Fields that are explicitly flagged in policy as sensitive — salary, health status, disability accommodations, immigration status, background check results — are technically accessible through a tool with no additional authorization check beyond the baseline permission to use the tool at all. The sensitivity flag exists as a governance label describing how the field *should* be handled, but no runtime gate (step-up authentication, role-specific approval, purpose limitation) actually stands between an agent and the field once it has ordinary access to the record it lives on.
An operation is classified in policy as sensitive or high-risk — deleting a production resource, transferring funds above a threshold, changing a customer's access level — and is documented as requiring human approval before execution. In practice, the agent's execution path has no code-level gate enforcing that requirement: the classification exists as a label or a line in a policy document, but nothing in the tool-dispatch pipeline actually blocks execution pending approval.
Agent Calls Tools in Wrong Order
Employees Use External AI Tools, Leaking Sensitive Data
Agent misses that a tool sends email, bills, deploys, or notifies.
Tools Fail Without Alerting the Agent
An agent references a model by a floating alias — a name like "latest," a bare model family name without a snapshot suffix, or a provider-managed default endpoint — rather than a pinned, immutable snapshot. The provider swaps the model backing that alias to a new version on its own schedule, with no code change, no deploy, and no action on the team's part. Because nothing in the team's own systems changed, none of their normal change-detection tooling (deploy logs, git history, config diffs) has any record of the update, and behavior drift shows up looking like an unexplained, spontaneous regression rather than the direct consequence of a version change that in fact happened underneath them.
Tools Accept Wrong Types and Silently Produce Wrong Results
A critical agent, tool, service, or piece of shared infrastructure has exactly one instance in the architecture, with no redundant standby, no alternate path, and no fallback that doesn't itself depend on the same component — so that component's failure takes down every workflow that depends on it, directly or transitively, all at once. This is an architectural gap, not a failure that unfolds once triggered: the system was designed (or, more often, organically grew) without redundancy for a component that turned out to be load-bearing for far more of the system than anyone tracking "what's critical" realized at the time it was introduced.
A tool's actual uptime falls short of its advertised availability SLA (e.g., "99.9% uptime" translating to roughly 43 minutes of allowed downtime per month, but real outages exceeding that budget). The agent, built with no fallback path because the SLA implied outages would be rare and brief, treats every outage as an unexpected, unhandled condition — retrying blindly, failing the entire user-facing workflow, or queuing work indefinitely — rather than having a designed response for a scenario the SLA math said should barely ever happen but that occurs often enough in practice to matter.
Agent Goes Silent During Tool Execution Without Acknowledgment
A Cost-Optimization Agent Calls a Cloud-Provider Billing/Cost-Export Tool to Decide Whether to Autonomously Resize or Terminate Underutilized Resources, the Tool Returns a Cached or Delayed Billing Export That Predates a Recent Spend Spike or Recent Manual Remediation, and the Agent Acts on Spend Data That No Longer Reflects Current Reality
A Deal-Management Agent Calls an Internal Pricing/Discount-Approval Tool to Check the Maximum Discount an AE Can Approve Without Escalation, the Tool Returns a Cached Result from Before a Discount-Policy Change Took Effect, and the Agent Approves a Quote at a Discount Level That No Longer Qualifies for Auto-Approval
A Logistics-Routing Agent Calls a Live Traffic/Transit-Time Tool to Compute a Delivery ETA It Commits to a Customer, the Tool Returns a Cached Response from Before a Major Disruption Event (Accident Closure, Severe Weather Routing Change) Took Effect, and the Agent Commits to an ETA Computed Against Conditions That No Longer Exist
An agent acts on an old tool result after the underlying resource has already changed, instead of re-fetching current state before the action. Fetched data sits in context for the rest of a multi-turn session with no freshness timestamp or cache-invalidation mechanism, so nothing distinguishes a value read seconds ago from one read twenty minutes ago — and the longer the session runs, the more opportunity an external actor has to change the resource unnoticed.
Agent Treats an Earlier Tool Confirmation as Still Valid After Making a Change the Tool Never Re-Evaluated
A Policy-Servicing Agent Determining How Many Days of Advance Written Notice a Carrier Must Give Before Cancelling or Non-Renewing a Policy in a Given State Answers From a General, Memorized Sense of Typical Notice-Period Rules Formed During Pretraining Instead of Calling the Live Regulatory-Requirements Lookup Tool It Has Available, Producing a Cancellation or Non-Renewal Notice That Understates the State's Actual Current Required Notice Period
An Underwriting Agent Answers Risk-Zone Questions (Flood Zone, Wildfire Risk Tier, Hurricane Exposure Band) from Facts Memorized During Pretraining Instead of Calling the Live Catastrophe-Model or Mapping Tool It Has Available, Producing Risk Assessments Based on Outdated Zone Designations
An Offer-Generation Agent Answers Market-Rate Compensation Questions from Salary Figures It Absorbed During Pretraining Rather Than Calling the Live Compensation-Benchmarking Tool It Has Available, Producing Offers Anchored to Outdated Market Data for Fast-Moving Roles
A Compliance-Review Agent Answers Questions About Where and How an Advertising Disclosure Must Appear (Required Proximity to a Claim, Minimum Font Size, Required Placement Before a "Buy Now" Action) from Facts Memorized During Pretraining Instead of Calling the Live Regulatory-Guidance Tool It Has Available, Producing Compliance Sign-Offs Based on Outdated Disclosure Rules
A Fraud-Detection Agent Screening Claims for SIU Referral Applies a Generic Fraud-Typology Pattern Absorbed During Pretraining (e.g., a Widely Discussed Staged-Collision Pattern or a Generic Soft-Tissue-Injury Red-Flag Profile) Instead of Querying the Live, Internally Maintained SIU Red-Flag List That the Carrier Has Available as a Tool, Missing a Recently Added Red Flag Specific to a Current Fraud Ring or Failing to Apply a Recently Retired Flag the Carrier Stopped Using Because It Generated Excessive False Positives
A Retention-Prediction Agent, When Asked to Contextualize Whether an Employee's Computed Risk Score Is High Relative to Peers, Answers Using a General Industry Attrition-Rate Figure It Absorbed During Pretraining Rather Than Calling the Live Internal Cohort-Comparison Tool Available to It, Producing a Relative-Risk Characterization Anchored to an Outdated or Generic Benchmark Instead of the Company's Actual, Current Department-Level Attrition Baseline
An SEO-Optimization Agent Asked to Confirm a Page's Title Tag Length, Meta-Description Length, or Structured-Data Requirements Comply With Current Search-Engine Guidance Answers From a Generic Character-Count Rule or Structured-Data Requirement Absorbed During Pretraining or Retained From an Earlier Point in Time, Instead of Calling the Live SEO-Guidelines Tool That Holds the Team's Current, Recently Updated Rules Reflecting a Search Engine's Latest Documented Change, Approving Pages That the Current Guidance Would Actually Flag
A Claims-Processing Agent Determining the Statutory Deadline by Which a Claim Must Be Acknowledged, Investigated, or Paid Under a Given State's Prompt-Payment Law Answers From a General, Memorized Sense of Typical State Deadlines Formed During Pretraining Instead of Calling the Live Regulatory-Requirements Tool It Has Available, Producing a Processing Timeline Based on an Outdated or Generic Deadline Rather Than the State's Actual Current Statutory Requirement
A Quality-Control Agent Asked Whether a Piece of Marketing Copy Meets the Team's Current Acceptance Bar for Readability, Claim-Density, or Required-Element Checks (Such as a Minimum Number of Supporting Data Points per Claim, or a Maximum Reading-Grade Level) Answers From a Generic or Outdated Quality Bar Absorbed During Pretraining or Retained From an Earlier Project Phase, Rather Than Calling the Live Quality-Control Policy Tool That Holds the Team's Current, Recently Revised Acceptance Thresholds, Passing Copy That the Current Policy Would Actually Reject
A Content-Generation Agent Answers Questions About the Brand's Permitted Tone, Person, or Phrasing Conventions (e.g., Whether Second-Person "You" Address Is Allowed, Whether Exclamation Points Are Permitted, Whether the Brand Name Should Be Used as a Verb) from General Stylistic Patterns Absorbed During Pretraining or from an Early, Now-Superseded Memory of the Brand Voice, Instead of Calling the Live Brand-Voice-Guideline Tool It Has Available, Producing Content That Violates a Recently Updated Rule
An Onboarding Agent Answering a New International Hire's Question About Visa-Sponsorship Steps, Timelines, or Document Requirements Answers from Generic Immigration-Process Knowledge It Absorbed During Pretraining Rather Than Calling the Company's Live Immigration-Policy Tool, Producing Guidance That Reflects an Outdated Visa Category, Processing Timeline, or Document List Instead of the Company's Actual Current Sponsorship Process
Agent Fails to Discover Required Information
A multi-turn agent conversation relies on session affinity — the load balancer routing every request in that conversation to the same backend instance, which holds in-memory conversation state, a warm context cache, or an in-progress multi-step tool-calling loop — but a deployment, instance rotation, or connection-pool rebalancing breaks that affinity mid-conversation. The next turn gets routed to a different instance that has no knowledge of what came before, and depending on how the system handles the mismatch, the user either gets a jarring "who are you, what were we talking about" response, silently loses in-progress tool-call context, or triggers a duplicate action because the new instance re-executes a step the original instance had already completed.
An agent writes data through a tool — uploading files, storing generated embeddings, persisting logs or artifacts — and the underlying account or bucket has a fixed storage quota that the agent has no visibility into until it's already been exceeded. The write fails at the moment of the overage, often mid-batch, with no prior warning that the quota was approaching, leaving the agent with a partially-written dataset and no clean way to know which records succeeded.
Multiple instances of an agent (or multiple distinct agents in a fleet) write to the same pooled storage quota — a shared object store bucket, a shared vector database namespace, a shared scratch volume. One agent instance with an unusually heavy workload (large file uploads, verbose logging, an unbounded caching pattern) can silently consume the entire pool, causing unrelated agent instances to fail their own writes with no indication that another agent, not their own behavior, caused the exhaustion.
A storage tool enforces a soft limit below its hard quota ceiling — triggering throttled write speeds, forced read-only mode, or reduced replication guarantees once usage crosses a threshold like 85% of provisioned capacity. The agent has no logic to detect this intermediate degraded state; it only recognizes "working" versus "hard error," so when writes start silently slowing down or getting rejected in read-only mode, the agent misattributes the behavior to a bug in the tool, a network issue, or its own code, rather than recognizing an approaching-capacity condition it could act on.
Compromised Tools or Dependencies Attack Agent
Agent uses compromised tool, plugin, package, MCP server, or model dependency.
Access to certain data is supposed to be restricted to a temporal window — only during business hours, only for a fixed number of days after an event (e.g., 30 days after an employee's termination, or 90 days after a transaction for fraud review), or only before a record's scheduled expiration — but the tool that serves the data has no check against the current time relative to that window. The data remains fully queryable indefinitely, or outside the intended hours, because the temporal restriction was defined as a policy rule rather than implemented as a runtime condition on the query path.
Some tools — especially LLM inference APIs and other usage-metered services — rate-limit by consumed tokens or compute units rather than by raw request count (e.g., "200,000 tokens per minute" instead of "500 requests per minute"). An agent whose rate-limiting logic only tracks how many requests it has sent has no visibility into token consumption, so it can stay well under any request-count budget while still blowing through the token-based limit, especially when individual calls vary wildly in size (a short classification prompt vs. a long document-summarization prompt).
Agent Assumes Tool Is Available When It's Not
Agent answers from memory when current/source-grounded tool use is required.
Agent Uses Tools to Send Sensitive Data to External Systems
Multiple agents or tasks share a single pooled budget for a tool (e.g. one $500/day cap on a translation API shared across all customer-facing workflows), and a high-frequency consumer — a chatty agent that calls the tool far more often than others, or a runaway loop — consumes a disproportionate share of the pool early, leaving other agents or tasks unable to make even essential calls for the rest of the period. Unlike a simple exhaustion, the problem here is specifically that the shared pool has no fairness mechanism, so one consumer's volume determines everyone else's access.
Sequential Tool Calls Create Unacceptable Total Latency
Agent assumes a tool can do something it cannot.
Agent Assumes Tool Can Do More Than It Actually Can
As the number of available tools and the depth of a plan grow, the number of possible tool-call sequences the agent could construct grows combinatorially, and the planning process either times out, truncates its search, or falls back to a shallow heuristic that ignores most of the space. The agent isn't failing on any single tool call — it's failing to reason about which combination and ordering of many tools is correct, because the branching factor has outgrown what the planner can actually evaluate within its context or time budget.
Agent receives conflicting tool outputs and picks one without rationale.
An incident-time override that raises or disables a tool's cost cap is never reverted once the incident closes, because no expiry or revert step was attached to the change. During an incident (an outage, a launch under time pressure, a data-quality emergency), an engineer or on-call responder manually raises or disables a tool's cost cap to let the agent push through urgent work unblocked. The override is applied directly in configuration or a feature flag, the incident is resolved, and the override is never reverted — because reverting it isn't part of the incident-closure checklist and no automated expiry was attached to the change. The cap stays effectively uncapped indefinitely, sometimes for months, until an unrelated invoice review discovers it.
Vague or Poor Tool Descriptions Cause Wrong Tool Calls or Bad Parameters
Remote Code Execution Through AI Agent Tool Calls
An agent retries a tool call after a timeout, an ambiguous error, or a crash-and-resume, assuming that calling it again is safe because "retrying is always safe." Some tools are not idempotent — calling them twice with the same arguments produces two distinct side effects (two charges, two emails, two created records) rather than converging to the same end state. The agent's retry logic doesn't distinguish between tools where a duplicate call is harmless and tools where it corrupts state or produces a real-world duplicate action.
Two or more tools must be called in a specific order for the task to succeed — one establishes a precondition, allocates a resource, or authenticates a session that a later tool depends on — but nothing in the tool definitions or the agent's planning logic enforces that order. The agent, reasoning about which tool seems most relevant to the current sub-goal, calls them out of sequence, and the later call either fails outright or, worse, succeeds against stale or wrong preconditions.
Some tools track retry attempts server-side per operation (keyed by an idempotency key, request ID, or resource ID) and permanently block further retries once a maximum attempt count is reached within a window — for example, a payment gateway that hard-fails an idempotency key after 5 attempts, refusing all further retries regardless of the reason for prior failures. An agent's own retry counter, especially one held in process memory or reset on deploy/restart, frequently loses sync with this server-side count, so the agent believes it has budget for more attempts and keeps retrying into a wall that will never open, wasting time and obscuring the real failure behind a misleading "max retries exceeded" or generic error each time.
A tool call mutates some shared state as a side effect — a global filter, a session variable, an environment setting, a cursor position, an authentication context — that isn't part of its declared return value, and a later, logically unrelated tool call is affected by that leftover mutation without either the agent or the tool's own interface making the dependency visible. The agent has no way to know that calling tool X changed the behavior of tool Y, because the mutation isn't represented anywhere in the tool-call contract.
An agent chains the output of one tool directly into the input of another, but the two tools disagree on format — one returns a date as `MM/DD/YYYY` while the next expects ISO-8601, one returns a list under a `results` key while the next expects `items`, one returns plain text while the next expects structured JSON. The agent either passes the mismatched data through unchanged (producing a downstream error or silent misinterpretation) or the LLM performs an ad hoc, occasionally-wrong reformatting step in between.
Tool response includes instructions that agent follows.
Agent calls tools unnecessarily, increasing cost and latency.
The agent mistranslates its own document understanding into tool call parameters, silently extracting from the wrong page or region
At each step, the agent picks whichever tool looks most immediately useful for the current sub-goal — the one whose description best matches the current phrasing — without considering how that choice constrains or costs more in later steps. This locally-good, globally-suboptimal selection pattern repeatedly leads the agent down a path that technically makes progress at each step but ends up more expensive, slower, or less accurate overall than a different tool choice earlier on would have been.
The same task, given to the same agent with the same available tools, results in a different tool being selected across separate runs — one run calls a REST API tool, another run calls a functionally-overlapping SQL tool, a third calls a third-party search integration — with no change in the input that would justify the difference. Because downstream behavior, cost, and reliability differ by tool, this non-determinism makes the agent's behavior unpredictable and hard to test, debug, or give consistent guarantees about.
Agent calls write tool before reading/verifying current state.
A tool call is written or planned assuming a prior call already established some state it depends on — an authenticated session, a created resource, an uploaded file, a set configuration — but that prior call was never actually made, failed silently, or was skipped by the agent's plan. The dependent call proceeds anyway, either erroring against missing state or, more dangerously, succeeding against a default/fallback state that isn't the one the agent intended.
Agent Uses Tool Incorrectly Due to Version Mismatch
Multi-step tool jobs (a batch pipeline, an orchestrated workflow, a long-running export composed of several sequential API calls) frequently have an overall wall-clock timeout for the entire job, separate from and often much stricter in aggregate than the sum of individual per-step timeouts an agent budgets for. An agent that allocates time per step, confirming each step completes within its own limit, can still have the whole job killed by the orchestrator's total-job timeout if the sum of otherwise-successful steps exceeds it — a failure the agent's step-by-step success tracking gives it no warning of until the job is terminated mid-flight, discarding whatever aggregate work was in progress at that moment.
Adding a single new direct dependency — a library, an agent tool/plugin, an MCP server — pulls in that dependency's own dependencies, and each of those pulls in more, so the total size of the dependency graph grows combinatorially rather than linearly with the number of direct dependencies actually chosen. What looked like "add one package to do X" becomes dozens or hundreds of transitively-installed packages, each an independent unit of install time, version-resolution complexity, and supply-chain attack surface that no one on the team deliberately chose or reviewed. This is distinct from a version conflict between two specific packages or a single CVE in one package; the problem here is the uncontrolled growth of the graph itself.
A tool the agent calls directly is itself built on top of one or more other tools or services — an aggregator API that queries several upstream data providers, a workflow-automation tool that calls out to a third-party integration, a wrapper library that proxies another vendor's SDK. When one of these indirect, transitive dependencies fails, the agent sees only a failure (or a degraded, incomplete, or wrong result) from the tool it called directly, with no visibility into the actual failing component, making the failure much harder to diagnose or route around than a failure in a tool the agent calls itself.
Conversation History and Tool Output Are Appended Every Turn With No Truncation or Summarization, So Total Session Cost Grows Superlinearly as the Conversation Lengthens
Attacker Chains Legitimate Tools in Unintended Sequences to Bypass Controls
A tool's actual runtime behavior diverges from what its published documentation describes — an undocumented rate limit far stricter than any documented one, a required field the reference doesn't mention, an implicit ordering constraint, or a response value the docs never enumerate. An agent built strictly against the documentation has no way to anticipate this gap, so it fails against the tool's real behavior in ways that look like a bug in the agent rather than a documentation gap in the tool.
A Replenishment Agent Calls a Demand-Forecast Tool and a Lead-Time/Pack-Size Tool, Both of Which Return Correct Values, but Combines Them Into a Final Purchase-Order Quantity via Free-Text Reasoning Rather Than a Deterministic Calculation, Introducing Arithmetic and Unit-Conversion Errors the Individual Tool Calls Never Made
Agent Calls Tools When Not Needed
Agent uses destructive capability for exploratory work.
Agent treats malformed, stale, or injected tool output as authoritative.
An Issue-Resolution Agent Authorized to Auto-Process Refunds Executes the Refund Directly Off the Customer's Narrated Claim Without Calling the Ledger-Verification Tool It Has Access To, Because the Claim's Phrasing Matches a Known-Resolvable Template
AI Cannot Determine When to Use Tools Due to Poor Documentation
An agent platform accumulates enough independently-versioned components — the orchestrator, several tool adapters, a prompt-template library, the underlying model version, a retrieval index schema — that the number of combinations needing to be verified compatible grows multiplicatively rather than additively. What started as "we support the last two orchestrator versions" becomes an unmanageable grid of orchestrator x tool-adapter x model-version x prompt-schema combinations, most of which have never actually been tested together, so nobody can confidently say whether a given production combination is known-good, known-bad, or simply untested.
A dependency pinned to an exact version for a good reason at the time is never revisited, and quietly accumulates CVEs and EOL risk. A team deliberately pins a dependency, container base image, or OS package to an exact version — for good reasons at the time (avoiding a breaking change, ensuring reproducible builds, working around a bug in a newer release) — and that pin is never revisited afterward. Unlike a range-based dependency that at least stays current within its bounds, an exact pin freezes the version indefinitely by design, so as months or years pass without an explicit review, the pinned version accumulates unpatched CVEs, falls off the vendor's support/EOL calendar, or becomes incompatible with newer tooling in the surrounding ecosystem, entirely because nothing was ever set up to force a periodic look at whether the original reason for pinning still applies.
A new version rolling out touches multiple independently-deployed components that must move together for the system to keep working — an agent orchestrator and its tool-adapter plugins, a client SDK and the server API it calls, a message producer and consumer sharing a schema — but each component is deployed on its own pipeline, timeline, and approval process. When one component's rollout gets ahead of or behind the others (deployed early because its pipeline is faster, delayed because of an unrelated approval holdup, rolled back independently after its own issue), the system spends time running an untested combination of versions that were only ever validated to work together as a matched set, producing failures that have nothing to do with a bug in any single component and everything to do with the combination being new.
The agent's architecture assumes a vendor's webhooks are delivered exactly-once or at-least-once, when the vendor's actual delivery model is best-effort with no guarantee at all. Under transient failures on either the vendor's or the agent's side (a brief outage, a deploy causing a 502 on the receiving endpoint, a network blip), the event is simply dropped rather than retried, and the agent never learns the underlying event happened, leading to silently missing state with no error to trigger investigation.
An agent's state-update logic assumes webhook events arrive in the same order the underlying events occurred — processing an "order.updated" after "order.created," a "status.changed" after the prior status.changed it supersedes. Most webhook systems make no such ordering guarantee: events can be delivered out of sequence due to parallel delivery workers, retries of earlier failed deliveries arriving after later successful ones, or multi-region delivery infrastructure. When a stale event arrives after a newer one, the agent overwrites current state with outdated data and has no way to detect that it just went backwards.
A tool's webhook delivery fails repeatedly against the agent's receiving endpoint — due to a transient outage, a misconfigured URL, or a deploy-time gap — and the vendor gives up retrying after a fixed number of attempts or a fixed time window. Once that budget is exhausted, the event is dropped permanently with no further attempt and, in many implementations, no notification to the receiver that delivery ultimately failed. The agent never learns the underlying event happened at all, and nothing in its own logs points to the gap since the failure occurred entirely on the vendor's side.
In a multi-workspace or multi-project system (e.g., separate Slack-style workspaces, Notion-style team spaces, or per-project environments within a single customer account), an agent operating in the context of one workspace is able to access or modify data belonging to a different workspace. Unlike a multi-tenant/account failure, this typically happens within a single customer's account across their own workspaces, and is usually rooted in shared backend infrastructure — a single search index, vector store, or cache — that wasn't partitioned by workspace ID as strictly as the application layer assumes.
Agent sends invalid JSON, enum, type, or schema.
Agent queries or schedules using incorrect date/time boundaries.
Agent acts in production instead of staging, wrong tenant, or wrong project.
System changes prompt when schema/retrieval/tool/data was root cause.
Agent uses customer ID as account ID, message ID as thread ID, etc.
Agent searches public web instead of internal/private source or vice versa.
Agent chooses an inappropriate tool for the task.
Agent Selects Inappropriate Tool for Task
Agent sends cents vs dollars, UTC vs local, kg vs grams.