Cascading Failures: When One Agent's Problem Becomes Everyone's Crisis
In interconnected agent systems, a single failure doesn't stay single for long. Retry storms, error propagation, resource exhaustion, and chain-reaction outages can take down an entire multi-agent ecosystem in minutes — turning a minor timeout into a catastrophic system failure.
What Are Cascading Failures?
Distributed systems have always faced cascading failures — but agentic systems make them worse. Traditional microservices fail in predictable patterns. AI agents fail in creative ways: an agent might decide to work around a failure by trying a different approach, spawning new sub-agents, making more API calls, or escalating to higher-privilege operations — each "recovery" attempt amplifying the original problem.
Cascading failures in multi-agent systems occur when a failure in one agent or service propagates through interconnected components, causing a chain reaction of degraded performance, incorrect outputs, or complete outages. Unlike traditional cascading failures, agent-driven cascades can be adaptive — the agents themselves make the cascade worse by trying to recover.
Database timeout → Agent retries 3x →
Agent asks orchestrator for help → Orchestrator spawns 3 new agents →
Each new agent retries 3x → 27 simultaneous DB queries
→ Database overloaded → All agents fail → Orchestrator spawns more agents...
✗ A single timeout became a self-amplifying denial-of-service attack — from the inside.
Failure Patterns
Cascading failures in agent systems follow several distinct patterns, each with different amplification dynamics and mitigation strategies:
Retry Storms
When a downstream service fails, agents retry — often aggressively. Without exponential backoff, jitter, and retry budgets, N agents each retrying M times creates N×M load on an already failing service. Worse, many agent frameworks default to unlimited retries, turning a transient failure into a sustained DDoS attack from your own infrastructure.
Error Propagation
In agent pipelines, one agent's error becomes the next agent's input. An agent that receives an error message might interpret it as data, incorporate it into its reasoning, and produce a plausible but completely wrong output. This "error laundering" is unique to AI agents — the error gets processed, not just passed through.
Resource Exhaustion
Agents consume resources — API rate limits, tokens, compute time, memory, database connections. When agents compete for the same resources without coordination, they can exhaust shared pools, starving other agents and services. LLM API costs can spiral exponentially when agents autonomously retry with longer prompts, include more context, or spawn sub-agents to "try harder."
Single Point of Failure
Many multi-agent systems rely on centralized orchestrators, shared memory stores, or single LLM API endpoints. When these central components fail, every agent fails simultaneously. The system has no graceful degradation path — it's all or nothing. Agent registries, tool servers, and compliance services are common single points of failure.
Cascade Scenarios
An orchestrator detects a failed task and creates a "recovery agent" to fix the problem. The recovery agent encounters the same failure (the downstream service is still down), so the orchestrator creates another recovery agent. Within minutes, hundreds of recovery agents are running, each consuming tokens, each retrying the same failed operation, each spawning more recovery attempts.
An agent encounters an error and includes the full error trace in its next LLM call for debugging context. The error trace includes the original prompt, doubling the token count. The next error doubles it again. Each retry costs exponentially more tokens, burning through API budgets and hitting rate limits that cascade to all other agents sharing the same API key.
Agent A needs compliance verification from Service X before proceeding. Service X needs data from Agent B. Agent B is waiting for Agent A to provide context. All three are holding connections, consuming resources, and timing out simultaneously. When the timeouts trigger, all three retry — recreating the deadlock instantly.
An upstream agent hallucinates a data value. The downstream agent treats it as fact and builds a report. The report agent uses the hallucinated data to make calculations. The summary agent presents the calculations as verified findings. By the time a human sees the output, the original hallucination has been laundered through four layers of "processing" that look like verification.
How KYM Mitigates This
KnowYourModel's architecture is designed to contain failures at every level, preventing the cascade amplification patterns that plague multi-agent systems:
KV-Backed Rate Limiting
KYM enforces per-key, per-endpoint rate limits using Cloudflare KV. Every API call is
checked against configurable sliding-window limits before execution. When agents hit
rate limits, they get clear 429 responses with Retry-After headers — not timeouts that trigger infinite retry loops. This
prevents any single agent from monopolizing shared resources.
Probe Health Monitoring
KYM's agent registration system includes periodic probe checks that verify agent availability. When an agent becomes unhealthy, its status is updated in the registry before other agents try to connect. This "circuit breaker" pattern prevents agents from wasting resources connecting to known-dead services.
Reputation-Based Trust Scoring
Agent trust scores on KYM factor in reliability metrics — uptime, response latency, error rates. An agent that repeatedly fails or produces inconsistent results sees its trust score decrease, which can trigger compliance escalation or removal from federation. This creates a natural feedback loop that identifies unreliable agents before they cause cascades.
Cloudflare Workers Isolate Boundaries
Each KYM request runs in its own V8 isolate with strict CPU and memory limits. A runaway process can't consume host resources or affect other requests. If an isolate exceeds its time limit, it's terminated cleanly — no zombie processes, no resource leaks, no cascading resource exhaustion.
Queue-Based Async Processing
KYM uses Cloudflare Queues for non-critical operations like GitHub sync. This decouples request handling from background processing — if the sync pipeline fails, it doesn't block API responses. Failed queue messages are retried with built-in backoff, not in the request path where they'd cascade to users.
Defense Checklist
Essential Defenses
- Implement circuit breakers: Stop calling failed services immediately. Use health checks and exponential backoff with jitter to prevent thundering herd problems when services recover
- Set retry budgets: Limit total retries per operation, per agent, and per system. A global retry budget prevents the multiplicative retry storms that agent orchestrators create
- Enforce resource limits: Set hard limits on tokens, API calls, compute time, and agent spawn counts per request. Cap LLM context window sizes to prevent token bombs
- Use async processing: Decouple request handling from background work via queues. This prevents slow operations from blocking fast ones and limits cascade propagation speed
Common Mistakes
- Unlimited agent spawning: Letting orchestrators create unlimited sub-agents to "solve" problems. Each new agent is a resource multiplier that can turn a linear failure into an exponential one
- No timeout budgets: Setting timeouts per-call but not per-pipeline. An agent pipeline with 5 steps and 30s timeouts per step can hang for 2.5 minutes — multiply by retries and the cascade window extends indefinitely
- Error messages as context: Including raw error traces in LLM prompts for "self-debugging." This creates token bombs and can leak sensitive system information into model context
Further Reading
Complete the OWASP Agentic Top 10
All 10 Threats Covered — Explore the Full Series
You've reached the end of our OWASP Agentic Top 10 deep-dive series. Return to the overview to explore all 10 threats and how KnowYourModel addresses each one.
View the Full OWASP Agentic Top 10