Detecting and classifying failures

Once agents run for long periods and act autonomously, failure stops being an exception and becomes part of normal operation. In multi-agent systems, something will eventually go wrong: a task produces no result, a dependency disappears, or an assumption turns out to be false. This lesson exists to orient us to how failures are recognized and understood, so recovery decisions can be made deliberately instead of reactively.

What constitutes a failure in an agent system

A failure is any situation where an agent cannot make forward progress toward its intended goal. This does not require an exception or crash. A worker that returns no output, a task that stalls indefinitely, or a result that violates expectations all qualify as failures.

In agent systems, failures are defined by behavior, not just errors. If the system cannot proceed as designed, something has failed.

Expected failures versus unexpected failures

Some failures are anticipated as part of normal operation. A request may return no data, a worker may report that a task is not applicable, or a dependency may be temporarily unavailable. These outcomes are expected, even if they are undesirable.

Unexpected failures violate assumptions. They include corrupted state, malformed outputs, missing signals, or contradictions that the system does not know how to interpret. These failures usually require stronger intervention or escalation.

Distinguishing between these two categories prevents overreacting to normal conditions while still surfacing serious problems.

Classifying failures by cause and severity

Failures can be classified by cause, such as missing input, invalid state, tool failure, or coordination breakdown. They can also be classified by severity, ranging from minor delays to complete task blockage.

This classification does not fix the failure. It gives the system context. A low-severity, known cause might justify a retry, while a high-severity, unknown cause may require stopping work entirely.

Clear classification makes downstream decisions predictable and consistent.

Detecting failures through state, results, and signals

Failures are detected by observing what the system produces and how its state changes over time. A task result may be empty, incomplete, or inconsistent. State may stop progressing. Expected signals may never arrive.

Detection relies on explicit checks, not intuition. Agents must look at their own state, the outputs they receive, and the signals they expect, and decide whether progress is still possible.

Without detection, failures quietly accumulate and become harder to diagnose.

Using failure information to guide recovery decisions

Once a failure is detected and classified, that information becomes an input to decision-making. The system can choose to retry, wait, escalate, or halt based on what kind of failure occurred.

At this stage, no recovery happens yet. The system is simply oriented. It knows what went wrong, how serious it is, and why it matters. That orientation is what enables controlled recovery instead of chaotic behavior.

Conclusion

At this point, we are no longer treating failure as an anomaly. We can recognize when an agent system is failing, distinguish normal setbacks from serious problems, and classify failures in a way that supports deliberate recovery. With this foundation, failure becomes something the system can reason about instead of something it merely reacts to.