Why AI Agents Crash and How to Prevent It

Model API Failures

The most common cause of AI agent crashes is the loss of connection to the underlying language model. Every major LLM provider has experienced significant outages, and even during normal operation, rate limiting, timeout errors, and capacity throttling are routine events.

When an agent sends a request to a model API and receives a 429 (rate limited), 503 (service unavailable), or 500 (internal server error) response, the agent must decide what to do next. Without error handling, the agent crashes. With naive error handling (retry immediately), the agent hammers the already-overloaded API and makes the situation worse for everyone.

The correct response depends on the error type. Rate limit errors (429) include a Retry-After header that tells the agent exactly how long to wait. Server errors (500, 503) suggest transient issues that may resolve with exponential backoff. Authentication errors (401, 403) indicate permanent problems that retrying will not fix. Model deprecation (404 on a model endpoint) requires switching to a different model entirely.

Prevention: Implement a circuit breaker for every model API connection. Use exponential backoff with jitter for transient errors. Configure model fallback chains so the agent can switch to an alternative model when the primary one is unavailable. Always set reasonable timeouts on API calls, never wait indefinitely for a response.

Context Window Overflow

Every language model has a maximum context window, the total number of tokens it can process in a single request. When an agent accumulates more conversation history, tool output, and retrieved context than this limit allows, it crashes, truncates silently, or produces degraded output.

This problem is particularly insidious because it develops gradually. Each step of a multi-step task adds tokens to the context. Tool outputs, especially from web scraping or database queries, can be surprisingly large. Retrieved documents from RAG pipelines add thousands of tokens. Eventually the accumulated context exceeds the limit, often at the most critical moment in a long workflow.

Silent truncation is arguably worse than crashing. When a model silently drops earlier parts of the conversation to fit within the context window, the agent loses important instructions, constraints, or intermediate results. It continues operating but with amnesia about critical context, producing results that are confidently wrong.

Prevention: Implement context window monitoring that tracks token usage in real time and triggers compression or summarization before hitting the limit. Use summarization checkpoints that periodically condense conversation history into compact summaries. Limit tool output sizes with truncation and pagination. Design prompts to be token-efficient, avoiding verbose system instructions that consume context budget.

Infinite Loops and Runaway Execution

AI agents can get stuck in reasoning loops where they repeatedly attempt the same action, receive the same error, and decide to try again. This happens because the model cannot distinguish between "this will work if I try again" and "this will never work no matter how many times I try."

A common pattern: the agent calls a tool with incorrect parameters. The tool returns an error. The agent interprets the error, adjusts its parameters slightly, and tries again. But the adjustment is insufficient or incorrect, so it gets the same error. Without loop detection, this cycle can continue for hundreds of iterations, consuming API credits and producing no useful work.

Runaway execution also occurs when an agent interprets its task too broadly. Asked to "research competitors," the agent might start crawling the entire internet, following links from one site to another indefinitely. Asked to "clean up the code," it might rewrite every file in the project. Without scope boundaries, agents optimize for task completion without considering resource constraints.

Prevention: Implement step counters that limit the maximum number of actions per task. Add loop detection that identifies repeated identical or near-identical tool calls. Set budget limits on API token consumption per task. Use circuit breakers that trip when error rates exceed thresholds. Define explicit scope boundaries in task specifications.

State Corruption

State corruption occurs when an agent crashes or fails partway through a multi-step operation, leaving the system in an inconsistent state. The agent has completed some actions but not others, and the recorded state does not accurately reflect reality.

Consider an agent that processes a customer refund in three steps: (1) reverse the charge in the payment system, (2) update the order status in the database, and (3) send a confirmation email to the customer. If the agent crashes after step 1 but before step 2, the charge is reversed but the order still shows as "paid." If it then restarts and processes the refund again from the beginning, the customer gets refunded twice.

State corruption is the hardest failure mode to detect because the system appears to be working normally. It produces incorrect results without error messages, and the inconsistencies may not surface until much later when they have already caused real damage.

Prevention: Design operations to be idempotent whenever possible, meaning that performing the same operation multiple times produces the same result as performing it once. Use state checkpoints that record exactly which steps have been completed. Implement write-ahead logging that records intended actions before executing them. For critical operations, use transaction-like patterns that make groups of state changes atomic.

Tool Execution Failures

AI agents that use tools, and most useful agents do, inherit the failure modes of every tool they call. A web scraping tool can fail because the target website changed its structure, implemented bot detection, or went offline. A database tool can fail because of connection pool exhaustion, query timeouts, or schema changes. A file system tool can fail because of permission errors, disk space exhaustion, or concurrent access conflicts.

The diversity of tool failure modes makes comprehensive error handling challenging. Each tool can fail in multiple ways, and the appropriate response differs for each failure type. A timeout might warrant a retry with a longer timeout. A permission error needs escalation to a human. A schema change requires the agent to update its understanding of the data structure.

Tool failures also create cascading risks. If tool A writes data that tool B reads, and tool A fails silently (producing partial or incorrect output), tool B operates on bad input and produces bad output in turn. The error propagates through the pipeline without triggering any explicit failure detection.

Prevention: Validate tool outputs before using them as inputs to subsequent operations. Implement timeouts for every tool call, never let a tool run indefinitely. Use structured error types that distinguish between retryable and permanent failures. Test tool integrations against realistic failure scenarios, not just happy paths. Consider using supervision trees to isolate and restart failed tool processes.

Memory and Resource Leaks

Long-running AI agents are particularly susceptible to resource leaks. Every model API call allocates memory for the request and response. Every tool invocation might open a file handle, network connection, or subprocess. Every retrieved document adds to the agent working memory. Over hours and days, these accumulated resources can exhaust the available supply.

Memory leaks in AI agents are often subtle. The agent might cache model responses for potential reuse, building up a cache that grows without bound. It might maintain a list of "visited URLs" for deduplication that grows with every web request. It might accumulate log entries in memory instead of flushing them to disk.

The symptoms of resource leaks are often misdiagnosed. Increasing response times might be attributed to model API slowness rather than local memory pressure. Intermittent failures might be blamed on network issues rather than file handle exhaustion. The gradual nature of the degradation makes it hard to pinpoint the root cause.

Prevention: Implement resource monitoring that tracks memory usage, open connections, file handles, and subprocess counts. Set explicit limits on cache sizes and implement eviction policies. Use connection pooling with maximum pool sizes. Design agents with bounded working memory that explicitly discards old information when new information arrives. Schedule periodic restarts for agents that run continuously.

Hallucinated Tool Calls

A failure mode unique to AI agents is the hallucinated tool call, where the model invents a tool that does not exist, uses incorrect parameters for a real tool, or calls a tool in a context where it should not be used. These failures are particularly dangerous because the agent acts with confidence, producing errors that look like legitimate operations to downstream systems.

Hallucinated tool calls occur more frequently when the model is working at the edge of its capabilities: handling unusual requests, operating with limited context, or using tools with complex parameter schemas. They also increase when the agent has too many tools available, as the model must choose from a larger set of options and is more likely to confuse similar tools.

Prevention: Validate all tool calls against a strict schema before execution. Limit the number of tools available to any single agent, using specialized agents with focused tool sets rather than one agent with dozens of tools. Implement confirmation steps for destructive or irreversible tool calls. Log all tool calls for post-hoc analysis and pattern detection.