Operations

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.

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

Agents Pursue Conflicting Objectives

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

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

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

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

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.

Too Many Pending Approvals Cause Delays or Dropped Requests

Agent Behaves Incorrectly When Human Approval Times Out

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.

Wrong Person Approves Action

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.

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

Processing Items Individually When Batching Would Be More Efficient

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

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

Request Batching Adds Unacceptable Wait Time

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.

Internal Cost Tracking Doesn't Match Vendor Invoices

Critical Failures Occur in Unmonitored Agent Code Paths

Slow Tool Calls Block All Other Operations

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

Agent Exceeds Budget Limits Without Being Stopped

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

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

Redundant LLM Calls for Identical or Similar Requests

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

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

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

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

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

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

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

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

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

Sequential Agent Calls Create Unacceptable End-to-End Latency

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

First Request After Idle Has Unacceptable Delay

Information Lost or Corrupted Between Agents

Memory Compaction Removes Critical Information

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

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

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

Multiple agents/users modify same object without coordination.

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

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

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

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

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

Multi-Agent Voting or Agreement Fails to Resolve

Race Conditions During Context Assembly Cause Inconsistent State

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

Low-Priority Content Displaces High-Priority Content

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

Large Context Windows Cause Quadratic Latency Growth

Overloading Context with Irrelevant Information

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.

Agent Silently Drops Input Context When Message Exceeds Context Window

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

Unusual Cost Patterns Go Undetected

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

Cost Optimization Degrades Agent Quality

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

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

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

Current task is polluted by unrelated previous context.

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

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

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

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

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

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

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

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

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

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

Information Needed for Debugging Lost Before Investigation

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.

Agents Delegate to Sub-Agents Creating Unbounded Depth

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

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

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

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

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

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

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

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.

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

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

Raw Errors Expose Internal Details and Waste Context

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

Agent Fails to Escalate to Human When Required

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

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

External APIs and Tools Fail, Causing Agent Errors

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

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

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

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

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.

Human Corrections Ignored in Subsequent Agent Decisions

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

No Fallback When Required Approver Is Unavailable

Agent repeats a write action and creates duplicates.

Only Some Agent Actions Are Logged, Creating Blind Spots

Agent recalls wrong past preference or fact.

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

Unpredictable Model Inference Times

Agent Gets Stuck in Infinite Retry Loops

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Agent misreads/transforms tool output incorrectly.

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

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

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

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.

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

Cannot Understand Why Agent Made Specific Decisions

Agent ignores tool warning/error and continues.

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

Retrieved Memories Contradict Each Other

Two memories contradict; agent fails to resolve.

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

Agent fails to forget information when requested.

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

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

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

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

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

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

Malicious or wrong content gets stored and later trusted.

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

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

Agent uses private memory in inappropriate context.

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

Relevant Memories Not Retrieved When Needed

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

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

Workflow Lacks Required Approval Step for High-Risk Action

Agent Actions Not Recorded for Later Review or Compliance

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

Request Flows Through Multiple Components Without Unified Trace Context

Agent Fails Completely When Dependency Unavailable Instead of Degrading Gracefully

Agent fails to use relevant durable information.

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

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

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

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

Agent Omits Required Tool Parameters

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

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

Events Logged Without Accurate Timing Information

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.

Using Expensive Models When Cheaper Alternatives Suffice

A Coordinator Broadcasts Full Shared Context/History to Every Sub-Agent Regardless of Relevance, Multiplying Token Cost by Agent Count

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.

Inference traffic — especially large prompt payloads (long context windows, embedded images/documents), streaming token responses to many concurrent clients, and cross-node traffic for tensor-parallel or pipeline-parallel model sharding — saturates available network bandwidth on a node or rack. Once bandwidth saturates, requests that should be GPU-bound become network-bound: token streaming stalls, tensor-parallel all-reduce operations slow the entire batch down to the pace of the slowest network hop, and unrelated services sharing the same network fabric see cascading timeouts, all while GPUs sit fed at a fraction of their real throughput and continue billing at full rate for degraded output.

System Doesn't Account for Network Round-Trip Time

Agent Re-Derives an Identical Multi-Step Plan From Scratch for Every Occurrence of a Routine, Frequently-Repeated Operation

Agent's "Reused" Plans Are Not Actually Parameterized, So Near-Identical Requests Still Trigger Full Re-Planning Instead of a Template Substitution

Cannot Replay Agent Execution to Reproduce or Debug Issues

Central Orchestrator Becomes System Chokepoint

Operations Cannot Be Linked Back to Originating Request or Agent

Agent uses information that changed.

An agent generates output text and serializes it in one encoding while the downstream consumer (an API client, a file writer, a terminal, an email client) expects or declares a different one, corrupting non-ASCII characters — accented letters, currency symbols, emoji, non-Latin scripts — before the text reaches its destination. Unlike an input encoding mismatch, the corruption is introduced by the agent's own serialization step rather than inherited from a source, and it typically affects every non-ASCII character the agent itself generates or passes through, not just specific fields.

An agent produces output intended to conform to a specific schema (JSON with required fields, a fixed CSV column set, an API response contract) and hands it directly to a downstream consumer without verifying it actually matches that schema first. Because LLM-generated output is probabilistic rather than mechanically guaranteed, a small but nonzero fraction of responses have a missing field, wrong type, extra field, or malformed structure — and without a validation gate, that malformed output reaches the consumer exactly as if it were valid, causing it to fail unpredictably rather than being caught at the source.

When an agent is required to produce output matching a fixed schema, it will sometimes fabricate a plausible-looking value for a field it has no actual basis for — inventing a tracking number, a confidence score, a source citation, or an ID — rather than leaving the field empty, marking it as unknown, or declining to complete the schema. The output is structurally valid and passes any format/type check, which makes the fabrication far more dangerous than a free-text hallucination: it looks exactly like a correctly-populated field to any downstream system or reviewer that trusts schema conformance as a proxy for correctness.

The same logical input, processed by an agent on separate occasions, produces output with a different structure, field set, ordering, or format each time — not because the underlying data changed, but because the generation process itself is nondeterministic and nothing constrains it to produce a stable shape. A consumer that parses the first call's output shape and hardcodes assumptions from it breaks on the next call, even though nothing about the request changed.

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.

An agent generates output without any hard cap on its length, and a downstream consumer with an actual limit — a database column with a fixed `VARCHAR` size, a UI element with a character budget, an SMS/notification channel with a payload cap, a third-party API with a field-length restriction — receives output that exceeds it. Depending on the consumer, this either causes a hard rejection (a database `INSERT` failing, an API returning a 400) or, worse, a silent truncation somewhere in the chain that the agent itself has no visibility into and cannot compensate for.

An agent returns a list or array whose element order varies from call to call for logically equivalent input, even though the consuming system depends on a stable order — for pagination cursors, for diffing successive results, for deterministic display, or for stable IDs derived from position. Because the list's *contents* are correct each time, the failure is easy to miss in isolated testing and only surfaces when two calls are compared against each other or when a consumer's assumption of stability is violated.

An agent generates or serializes a numeric value in a way that loses precision relative to the actual computed or intended value — rounding a currency amount that needed exact cent-level precision, formatting a large integer through a floating-point representation that can't represent it exactly, or truncating decimal places in a scientific/financial figure. The output looks like a reasonable number and passes any type check, but its value is subtly different from the correct one, and that difference compounds when the number feeds further calculation.

An agent generates text that must be embedded inside a structured format — a JSON string value, a CSV field, a shell argument, a string literal in generated code — and the content itself contains quote characters, apostrophes, or backslashes that need to be escaped for the target grammar. Because the model produces the escaped output as free-form text generation rather than by running a deterministic escaping function, it frequently gets the transform wrong: under-escaping (leaving a raw quote that terminates the string early), over-escaping (doubling an already-correct escape sequence), or escaping for the wrong target grammar entirely (JSON-escaping content destined for a shell command, or vice versa). The result is a downstream parse failure or a corrupted field, distinct from output injection in that no malicious input is required — the model breaks its own well-intentioned output on ordinary content like a customer's name containing an apostrophe.

A pipeline runs agent-generated output through a sanitization step — a blocklist filter, an HTML-stripping function, a pattern-based scrubber — before it reaches a downstream consumer, and the sanitizer genuinely runs and genuinely modifies output that matches its rules. The gap is that the sanitizer's rules cover a specific, enumerable set of dangerous patterns rather than the full space of ways the same underlying danger can be represented: an encoded or obfuscated variant of a blocked pattern passes through untouched because it doesn't match the literal pattern the sanitizer looks for, or content that was safe at the moment it was sanitized becomes dangerous again after a later transformation step (minification, template re-interpolation, client-side re-parsing) that the sanitizer never accounted for. This is distinct from having no sanitization at all — the defense exists, runs, and has a real but incomplete coverage boundary that a sufficiently different-looking payload slips past.

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.

An agent produces output whose values are of one type — a string, a loosely-formatted number, a mixed-case boolean word — and the downstream system consuming that output performs an implicit type coercion while deserializing or ingesting it, silently converting the value into something semantically different rather than rejecting it. Because the coercion happens inside the consumer's parsing/deserialization layer rather than inside the agent, the agent has no visibility into the mismatch and no chance to correct it; the corrupted value simply propagates into the receiving system as if it were correct.

Agent applies a past preference where it does not belong.

Agent retrieves too much data and reasons over irrelevant records.

Agent misses correct data due to overly strict filters.

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.

Agents Operating in Parallel Cause Conflicts or Inconsistencies

Agent Passes Wrong Parameter Types to Tools

Agent treats partial/incomplete output as complete.

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.

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.

An agent commits to a plan generated at the start of a task and continues executing it step by step even after circumstances relevant to the plan have visibly changed mid-execution — new information arrives, an assumption the plan relied on turns out false, or the user's actual need shifts. Rather than re-planning or adjusting, the agent treats the original plan as fixed, executing later steps that no longer make sense given what's now known.

When a branch of a plan fails or turns out to be a dead end, the agent needs to cleanly undo whatever partial side effects that branch caused and return to a known-good state before trying an alternative. Many agents lack this capability: they either can't identify which prior actions need to be reversed, leave partial side effects in place while proceeding down a new branch, or attempt an undo that itself only partially succeeds, leaving the system in a state that matches neither the old branch nor the new one.

An agent estimates the time, money, compute, or API-call cost a plan will require before executing it, but the estimate is badly wrong — often by an order of magnitude — because the estimation step relies on a shallow heuristic (counting plan steps, or a flat per-step assumption) rather than reasoning about the actual work each step entails. Downstream systems that make decisions based on that estimate (budget approval, scheduling, user-facing time expectations) are then working from a number that bears little relation to reality.

When a planner decomposes a task into subtasks, it sometimes produces a set of dependencies where subtask A requires subtask B to complete first, B requires C, and C requires A — a circular dependency that has no valid execution order. Because the planner reasons about each dependency relationship locally (does this subtask need that one) rather than validating the full dependency graph globally, the cycle isn't caught at planning time, and the executor discovers the plan is structurally unexecutable only when it tries to find a starting point.

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.

While an agent is mid-execution on a multi-step plan, something in the external world changes in a way that invalidates the plan's premise — a price changes, an item goes out of stock, a policy is updated, a file the plan depends on is deleted — but the agent has no mechanism actively watching for such changes and keeps executing the now-invalid plan exactly as originally generated. Unlike a step that fails outright, an invalidated plan often continues to execute "successfully" step by step, since none of the individual actions error out; the plan simply no longer serves its original purpose.

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 planner, in an effort to reduce total execution time, marks two or more subtasks as safe to run in parallel because they don't appear to reference each other's stated inputs or outputs. In reality, the subtasks share a hidden data or resource dependency — one writes to a location the other reads from, both mutate the same underlying state, or one's precondition is silently established by the other's side effect — and the planner's dependency analysis wasn't deep enough to catch it. The plan itself contains no cycle and looks well-formed; the error is a misclassification made at planning time, before execution, that only manifests as a race condition once the two branches actually run concurrently.

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.

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."

Agent treats a soft preference as a hard rule.

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

Verbose but Relevant Prompt Content Is Sent Uncompressed at Full Token Cost When Established Compression Techniques Would Preserve Meaning at a Fraction of the Length

A model is quantized to reduce inference cost, and the accuracy drop it introduces is real but small enough, or spread thinly enough across the output distribution, that pre-production evaluation — typically a quick smoke test or a comparison against a loose acceptance threshold — doesn't catch it. The quantized model ships to production because it "passed," and the accuracy gap only surfaces later through downstream signals (increased user corrections, retries, escalations, or a slow drift in a business metric) that take weeks to trace back to the quantization change, by which point the cost savings have been partly or fully offset by the quality cost, and root-causing requires reconstructing a change that's no longer top-of-mind.

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.

Request Queues Build Up Causing Latency Spiral

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).

Retrieval-Augmented Generation System Collapses When Corpus Scales Beyond Threshold

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 or Degrades When Hitting API Rate Limits

Agent fails silently or retries destructively after API limit/timeout.

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 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.

The process of recovering a system after a failure — replaying a write-ahead log, re-running a batch job from a checkpoint, restoring from a snapshot combined with incremental logs — itself introduces data corruption, rather than faithfully restoring the pre-failure state. A partial write during log replay, a crash that interrupts the recovery process itself mid-way, or an off-by-one in checkpoint/log-offset alignment can leave the recovered system with malformed or partially-applied data. This is specifically about the recovery mechanism damaging data, as opposed to recovery simply being slow (recovery-time-objective-miss) or replaying events out of causal order (recovery-ordering-violation).

A single instance that recovers from a failure — restarting after a crash, restoring from a snapshot, resuming from a checkpoint — ends up in a state that differs from what its pre-failure state actually was, even though the recovery process completes without error and reports success. This is the single-instance version of the problem (as opposed to cascade-divergent-recovery, which is about multiple components recovering into mutually inconsistent states relative to each other): here, the concern is purely whether the one recovered instance matches its own prior true state, regardless of what any other component believes.

During recovery, logged operations are replayed in an order that violates the causal dependencies between them — an operation that logically depended on an earlier one is applied before it, or two operations that must be applied in a specific relative order are applied out of sequence — producing a state that no valid execution of the original system could ever have reached. This is distinct from recovery-data-corruption (which is about a single operation being malformed or partially applied): here every individual operation replays correctly in isolation, but the sequence is wrong.

A recovery operation spanning multiple components or subsystems completes successfully for some of them but not others, leaving the overall system in a mixed state where part of it is back online with fresh, correct state and another part is still down, still on stale state, or stuck mid-recovery. Unlike cascade-divergent-recovery (where every component recovers but into mutually inconsistent states), this pattern is about recovery simply not finishing everywhere — some components never complete recovery at all, and the system limps along in a half-recovered condition, often without anyone noticing because the components that did recover look healthy.

The organization has a defined Recovery Point Objective (RPO) — the maximum acceptable amount of data loss measured in time, e.g. "no more than 5 minutes of data may be lost in any failure" — and an actual incident loses more data than that objective allows. This is a measurement-and-commitment failure specifically about the RPO number itself: the system's actual replication/backup cadence, under real failure conditions, produces a larger data-loss window than what was promised to stakeholders, discovered only when a real failure exposes the gap between designed and actual RPO.

A documented recovery or disaster-recovery procedure exists — a runbook, an automated failover script, a restore-from-backup process — but has never actually been executed end-to-end against a real or realistic failure. When a real failure finally occurs and the procedure is invoked for the first time, it fails: a step references infrastructure that no longer exists, a credential has expired, a script depends on a manual precondition nobody remembers to satisfy, or the procedure simply takes far longer than anyone expected because nobody had a real timing baseline. The defining feature of this pattern is that the failure is discovered at the worst possible time — during an actual outage — rather than during a drill.

The organization has a defined Recovery Time Objective (RTO) — the maximum acceptable duration of an outage, e.g. "service must be restored within 30 minutes" — and an actual incident's total recovery time exceeds it. This pattern is specifically about the RTO commitment being broken, as a measurable, reportable event distinct from general slowness: it requires a documented target and an actual, measured overrun against that target, and is the aggregate/governance-level counterpart to specific timing failures like failover-delay-too-long (which describes the mechanics of why failover itself is slow).

A system runs multiple redundant instances of the same agent, worker, or failover component deliberately, for availability — but the instances have no coordination mechanism (a lock, a lease, a consensus protocol) governing who acts when, so two or more of them independently decide they are the one responsible for a given task and both act on it. This produces either duplicate execution of a side-effecting action (two remediation scripts both restart the same service, two agent replicas both send the same customer notification) or an outright split-brain, where two instances each believe themselves to be the sole active primary and take conflicting, contradictory actions on the same shared resource at the same time.

Agent Runs Multiple Self-Critique/Verification Calls by Default, Regardless of Whether the Task Actually Benefits From Them

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.

Agent Has No Negative-Cache/Failure-Memory, So It Regenerates and Re-Serves an Answer Already Confirmed Wrong When the Same or a Similar Question Recurs

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.

Agent Exceeds Allocated Resources Before Completion

A gradual, unbounded leak of memory, GPU memory, file handles, or connection-pool slots in the inference-serving process accumulates over the service's uptime until it degrades throughput or crashes the process, requiring a restart to fully recover. Because the leak is slow, it doesn't trip acute alerting thresholds early — instead it manifests as a steady decline in requests served per GPU-hour as the process approaches its limit, silently raising cost-per-token for hours or days before anyone notices, and then as a hard outage when the leak finally exhausts the resource.

A platform team allocates GPU/CPU/memory quotas to multiple inference workloads (teams, models, or environments) that sum to more than the physical capacity actually available, betting on the statistical assumption that not everyone will hit peak demand simultaneously — a standard and often reasonable cloud-capacity technique. When that assumption breaks (correlated demand spikes, a shared upstream event driving traffic to several agents at once, or one workload's usage pattern shifting), multiple workloads contend for the same physical resources at the same time, and instead of one workload being cleanly capacity-constrained, all of them experience degraded throughput and elevated latency simultaneously, which the serving layer often resolves through more replicas or emergency reserved capacity purchased at a premium.

Reserved/committed inference capacity is sized against a historical or forecasted peak-load estimate, but real peak demand exceeds it — from organic growth outpacing the forecast refresh cycle, a marketing event, or simple seasonality the original sizing didn't account for. When reserved capacity is exhausted, the system either throttles requests (queueing or rejecting them, degrading the user-facing SLA) or bursts onto on-demand capacity priced significantly higher than the reserved rate, so the exact moments that matter most for the business (peak demand, high-visibility traffic) are also the moments inference cost-per-token spikes hardest, inverting the cost curve exactly when it should be most efficient.

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.

System Exceeds Latency Commitments

A retrieval system's relevance or similarity score (cosine similarity, a reranker's confidence output, a hybrid search's combined score) is meant to signal how useful a retrieved memory will be for the current query, but in practice that score frequently doesn't correlate well with actual usefulness — a high-scoring result can be topically similar but practically useless (a near-duplicate that adds nothing new, an outdated version of a fact), while a lower-scoring result can be exactly the piece of context the agent needs. Agents that treat the raw score as a trustworthy confidence signal — using it to decide what to include, how much to trust a fact, or whether to ask a clarifying question — inherit whatever miscalibration the scoring function has, often without any indication that the score wasn't dependable.

A memory store accumulates near-duplicate entries — the same fact stated slightly differently across multiple writes, or the same document ingested more than once — and the retrieval layer has no deduplication step, so a single query returns several near-identical results occupying multiple slots in a limited top-k result set. Instead of surfacing k genuinely distinct, useful pieces of information, the agent receives k-minus-several redundant restatements of the same one or two facts, wasting context budget and pushing genuinely different, useful candidates below the cutoff.

The retrieval index itself — the vector index's internal graph/tree structure, an inverted index's postings lists, or a search engine's shard metadata — becomes structurally corrupted, from a bad write during an index rebuild, a version mismatch between index format and query engine, a crashed process leaving a partial index update, or disk/memory corruption at the infrastructure level. Unlike corruption of an individual memory record, this degrades retrieval quality or availability across the entire index (or a whole shard/partition of it), producing wrong, missing, or inconsistent results for many unrelated queries at once rather than for one specific fact.

Retrieval ranks results primarily or purely by semantic similarity to the query, with no explicit weighting for recency, so when a memory store contains both an older fact and a newer fact that supersedes it, the older one can outrank the newer one simply because it happens to phrase things in a way that scores higher against the query embedding. The agent then surfaces or acts on the stale result ahead of the current one, not because the current one is missing from the store, but because the ranking function that decided what to return never considered which one is actually more recent.

Exponential Retry Logic Multiplies Costs Beyond Original Request

Retries Multiply Latency Instead of Improving Reliability

Aggressive Retries Multiply Costs

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.

An emergency rollback of an agent service is triggered to undo a bad release, but the rollback itself fails to complete across the whole fleet — some instances revert to the prior version successfully while others fail to redeploy, get stuck mid-restart, or silently keep running the bad version because the rollback pipeline hit an error partway through and stopped without either finishing or reverting its own progress. The system ends up in a worse state than before the rollback started: a mixed fleet running both the broken version and the reverted version simultaneously, with no clear record of which instances are in which state, during what is already an active incident.

The agent's pacing logic assumes a tool's quota resets at a fixed clock boundary (e.g., "resets at midnight UTC" or "resets at the top of the hour"), but the tool actually enforces a rolling/sliding window — 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.

Orchestrator Routes Task to Wrong 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."

When the embedding model used to index a memory store is upgraded or swapped — a new model version, a provider change, a fine-tuning update — the vector space it produces shifts: distances and similarity relationships that held under the old model don't hold the same way under the new one, so old embeddings computed with the previous model and new embeddings computed with the current model are no longer meaningfully comparable, even though they're stored in the same index and queried together as if they were. Retrieval quality degrades in a way that has nothing to do with the content of the memories themselves, purely because the "ruler" used to measure similarity changed without the stored data being re-measured against it.

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.

Agent Calls Tools in Wrong Order

Agent misses that a tool sends email, bills, deploys, or notifies.

Agent Completes Despite Failures in Intermediate Stages, Outputting Incorrect Results

Tools Fail Without Alerting the Agent

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.

Ambiguous Blueprint Specifications Cause Agents to Interpret Roles Differently

Speculative decoding (using a small, cheap draft model to propose several tokens ahead, then verifying them in one pass with the large target model) and similar speculative-execution techniques are adopted to cut inference latency and cost by accepting multiple tokens per verification pass instead of one. When the draft model's acceptance rate is low — because it's poorly matched to the target model's distribution, the task domain shifted away from what the draft model was tuned on, or decoding parameters weren't retuned after a target-model update — the technique burns extra compute generating and verifying draft tokens that get rejected, and the workload ends up paying for both the draft model's compute and largely wasted target-model verification passes, sometimes at a higher total cost per accepted token than standard autoregressive decoding would have cost outright.

Agent Uses Old Approval for New or Changed Context

Outdated Information Kept While Current Information Discarded

Agent uses old tool results after new data arrives.

Agent Treats an Earlier Tool Confirmation as Still Valid After Making a Change the Tool Never Re-Evaluated

An agent that must confirm its local or cached view of state matches an authoritative source — a sync check against a database, a quorum read, a reconciliation call to another service — issues that check, the check exceeds its timeout, and the agent proceeds with the action anyway using whatever state it already had. The timeout is treated as a soft failure ("couldn't verify, continue") rather than a hard stop, so the agent acts on state that may already be stale or wrong.

State that an agent writes with one encoding — a character set, a serialization scheme (JSON vs. protobuf field ordering), a number format (float vs. decimal string), or a timezone convention — is later read by a different component that assumes a different encoding. The read succeeds without error but produces subtly wrong values: mojibake in text, truncated precision in numbers, or a timestamp shifted by hours. Because the read doesn't throw, the corruption propagates silently into downstream decisions.

An agent system accumulates state — completed task records, expired session memory, superseded conversation checkpoints, orphaned lock entries — that should be cleaned up once it's no longer needed, but the cleanup process (a TTL expiry, a reference-counted collector, a scheduled sweep) fails to run, fails silently, or falls behind the rate of new state creation. The stale state isn't just inert; it keeps being scanned, indexed, and loaded, degrading query latency and eventually memory or storage capacity.

Agent believes a step happened when it did not.

Agent forgets completed steps or user-provided constraints.

An entity that an agent manages (an order, a support ticket, a workflow run) is meant to move through a defined sequence of states with specific allowed transitions, but the agent — due to a missing guard, a race, or a direct write that bypasses the transition logic — moves it into a state or a state sequence the state machine should have forbidden. The entity ends up in a combination of fields that no valid path through the workflow should ever produce, and downstream logic that assumes the state machine's invariants hold then behaves unpredictably.

An agent writes state to a primary store and then, moments later, reads it back from a replica (a read-replica database, a cache, a secondary region) that hasn't yet caught up with the write. The agent proceeds as though the read reflects current reality, making a decision based on data that is seconds or minutes out of date relative to what it itself just wrote or what another writer has since changed.

State that an agent needs to persist or transmit across a process, network, or storage boundary fails to serialize or deserialize correctly — the write produces a truncated or malformed payload, or the read cannot fully reconstruct the original object graph. Unlike an encoding mismatch (where values decode to the wrong thing) or a version mismatch (where an old/new schema disagrees), this is a failure of the serialization mechanism itself: an unsupported type, a circular reference, a size limit, or a partial write leaves the stored representation broken rather than merely inaccurate.

State written to persistent storage by one version of an agent's code is later read by a different version — typically an older reader encountering a newer schema, or a rolled-forward deployment encountering state written before a schema change — and the reader either crashes, silently drops fields it doesn't recognize, or misinterprets a field whose meaning changed between versions. This is especially common during rolling deployments, where old and new code versions run simultaneously against the same shared state store.

Agent Fails to Discover Required Information

Agent Repeats Same Steps Without Progress

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.

Token Streaming Pauses or Stutters During Response

A planner decomposes a task into subgoals whose dependency graph is acyclic and individually valid, but sequences those subgoals in the wrong relative order because it reasoned about each subgoal's readiness or priority in isolation rather than against a complete precedence model. Unlike a circular dependency, there is a valid execution order available — the planner simply didn't pick it, instead ordering subgoals by something like generation order, apparent urgency, or estimated ease, and only implicitly (and incorrectly) assuming that order also respects real-world preconditions between subgoals that were never captured as an explicit dependency edge.

Repeated Summarization Degrades Information Quality

System Prompt Gets Truncated or Overwritten

Work Lost or Duplicated During Agent Transitions

Agent Doesn't Know When to Stop

A team optimizes an inference serving stack against raw throughput metrics — tokens generated per second, requests served per second, or GPU utilization — and improves them measurably, but the optimization increases the rate of failed, retried, or low-quality outputs that require rework, so the cost-per-successful-output actually gets worse even as the headline throughput number improves. Because throughput is easy to measure directly from the serving layer and "successful outcome" requires tracing further downstream (did the user accept the output, did the task actually complete, did a human have to redo it), teams optimize the visible metric and only discover the economic regression later, if at all.

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.

Timeouts Set Too Short or Too Long for Use Case

Attacker Intentionally Triggers High-Token Operations to Exhaust Cost Budget

Internal Token Counts Don't Match Actual Usage

Exponential Token Usage Growth

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.

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.

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.

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.

Agent Misunderstands Tool Response

Agent Makes Errors When Processing Tool Results

Agent calls tools unnecessarily, increasing cost and latency.

Tool Schema Changes Break Agent

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.

During a deployment or failover, traffic is shifted away from a set of agent instances — a canary rollback, a bad-version pool being drained, a zone failover — and redirected to the remaining healthy capacity, but the remaining pool wasn't sized to absorb the extra load. The sudden influx pushes the receiving instances past their own capacity limits, causing them to slow down or start failing too, which triggers their health checks to fail, which pulls them from rotation, which shifts their load onto whatever capacity is left — a cascading failure that starts as a routine traffic shift and ends with the entire fleet unhealthy, worse than the original problem the traffic shift was meant to fix.

A traffic-routing configuration meant to apply uniformly during a version rollout — a canary weight, a header-based version pin, a geographic or tier-based split — instead applies inconsistently across different request paths, entry points, or protocols. A user hitting the agent through the REST API gets routed according to the intended canary percentage, while the same logical traffic arriving through a WebSocket streaming endpoint, an internal service-to-service call, or a retry path bypasses the routing rule entirely and always lands on one version regardless of the configured split. The result is that "5% canary" is only true for some fraction of actual traffic, while another slice is either entirely exposed to the new version or entirely shielded from it, undermining both the safety intent and the statistical validity of the rollout.

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.

Critical Information Lost When Context is Truncated

Conversation History and Tool Output Are Appended Every Turn With No Truncation or Summarization, So Total Session Cost Grows Superlinearly as the Conversation Lengthens

Agent Skips Upfront Planning on a Task That Genuinely Needed It, Causing Failed Attempts and Expensive Rework

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.

N Expensive Model Calls Run in Parallel to Vote/Merge on an Answer, for Tasks a Single Call Would Have Handled Just as Well

Agent Runs a Full Planning/Decomposition Call for Tasks Simple Enough to Execute Directly

Agent Calls Tools When Not Needed

Agent uses destructive capability for exploratory work.

Cannot Track How Data Moved Through Agent Pipeline

Agent makes assumptions then treats them as facts.

Agent treats malformed, stale, or injected tool output as authoritative.

AI Cannot Determine When to Use Tools Due to Poor Documentation

Agent attaches wrong value to wrong entity.

Excessive Chain-of-Thought Output

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.

An operator (or an automated rollback script) attempts to revert a specific dependency, library, runtime, or container base image to an older version — commonly to work around a regression introduced by a recent upgrade — and the downgrade operation itself fails to produce a working system. This happens in one of two ways: the target older version is no longer actually installable (it's been yanked from the package registry, the container tag was deleted or overwritten, the release was pulled for a security issue), or the downgrade installs cleanly at the artifact level but the surrounding application code, configuration, or transitively-pinned peer dependencies have already drifted forward to depend on APIs, config keys, or behavior that only exist in the newer version — so the "successfully downgraded" component is now missing something the rest of the system requires.

A project's lock file (`package-lock.json`, `poetry.lock`, `Cargo.lock`, `Gemfile.lock`) pins the exact resolved version of every dependency at the moment it was last regenerated, and that lock file is checked into source control and treated as the source of truth for what actually gets installed in CI and production. Over time, the manifest's version ranges (`^2.1.0`, `>=1.4`) would permit newer releases, but because nobody regenerates the lock file, every install — regardless of how much time has passed — keeps resolving to the same increasingly old exact versions, silently accumulating unpatched vulnerabilities and missed bug fixes while the manifest itself looks perfectly current.

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 dependency, model endpoint, or platform component is pinned to a prerelease, beta, release-candidate, or nightly-build version — sometimes intentionally to get early access to a needed fix or feature, sometimes accidentally because a version-range specifier didn't exclude prerelease tags — and that prerelease version ends up running in production rather than being confined to a controlled evaluation. Prerelease versions carry no stability or support guarantee: the vendor can change, break, or withdraw them without following the deprecation notice process used for stable releases, and production traffic ends up exposed to instability that a stable-channel pin would never have carried.

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.

A system upgrades a component directly from an old version to a much newer one — skipping several intermediate major versions in one jump, often because the intermediate upgrades were deferred for a long time — and the vendor or maintainer only officially supports sequential, one-major-at-a-time upgrade paths (or specific documented multi-version jumps), not the arbitrary skip actually being attempted. The upgrade proceeds anyway, because nothing enforces the supported-path requirement at execution time, and it fails partway through, corrupts state that assumed intermediate migration steps had run, or "succeeds" while leaving the system in an undefined state the vendor never tested or committed to supporting.

An agent's architecture assumes a tool's webhook events are delivered reliably — exactly once, or at least once with guaranteed eventual delivery — when the tool'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.

The algorithm that computes how much traffic to send to each version during a weighted or gradual rollout contains a bug in the weight-computation logic itself — an off-by-one in a percentage calculation, a stale cached weight table that doesn't reflect the latest configured split, integer rounding that silently drops a low-percentage version's share to zero, or a race condition where concurrent weight updates and live traffic routing interleave incorrectly. Unlike infrastructure that executes a correct set of weights unevenly across different paths, here the weights being executed are themselves wrong: every routing decision faithfully applies a miscalculated split, so the actual traffic distribution differs from the intended one consistently and reproducibly, not intermittently or path-dependently.

Content Cut at Token Boundaries Creates Artifacts

Too Much Information Retrieved for Effective Use

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.

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.