In every scenario, the failure propagated because the system had no mechanism to contain it at the point of origin. The failure crossed from one agent to the next because:

1. The failing agent produced output in the correct format (so no format check caught it)
2. There was no output validation at the agent's boundary that checked content against expectations
3. There was no circuit breaker that stopped processing when the output looked anomalous
4. Downstream agents trusted the output because it came from an authorized source
5. Actions at the end of the pipeline had no rate limiting or human confirmation that could catch the accumulated error

Category A — Failure detection: Mechanisms that notice something has gone wrong before it propagates. Output validation, anomaly detection on outputs, sanity checks against expected ranges, confidence thresholds below which output is quarantined. Detection turns a silent failure into an explicit one that can be handled.

Category B — Failure containment: Mechanisms that limit how far a detected (or undetected) failure can travel. Circuit breakers that stop passing data from a failing agent. Blast radius limits on terminal actions (rate limiting, human confirmation for large-scale operations). Fallback behaviors that degrade gracefully instead of propagating errors. Isolation between agents that share dependencies.

Cascading failures are particularly costly because downstream agents take real-world actions — emails sent, trades executed, files modified, customers charged. Unlike a database query that can be rolled back, many agentic actions are irreversible or expensive to reverse. The longer a cascade runs before detection, the larger the set of irreversible actions that must be recovered from manually. This is why detection speed and blast radius limits at the action-taking end of the pipeline are both essential — and why human confirmation for bulk irreversible actions is not overhead, but risk management.