Cascading failures in agent workflows

What it is

This entry is about propagation, whatever the origin. A hallucinated value, a poisoned memory or a faulty tool starts as one fault. Because agents act on each other's output, store it and delegate from it, the fault is copied, amplified and made persistent. The root causes have their own entries; the cascade is a distinct risk because it calls for containment.

How it happens

• One agent's wrong output becomes another's trusted input.
• Agents retry and escalate automatically, multiplying the action.
• A faulty result is saved and reused in later runs.
• Several workflows share an agent, a tool or a memory, giving the fault a path between them.

Why it matters

Step-by-step human checks are what usually stop an error spreading, and autonomous chains remove them. The time from first fault to widespread harm can be seconds, and the saved state means the harm resumes after a restart.

Warning signs

• No workflow has a defined point at which it halts for a person.
• Volumes of an action rise sharply without a matching business cause.
• The same error appears in several agents' output within minutes.
• No one can say which workflows share which components.

Who owns it

The owner of the business process is accountable for its resilience. Engineering owns checkpoints and limits. The operational resilience function includes agent cascades in scenario testing.

In practice

A pricing agent misreads a data feed and lowers one product's rate. A second agent, which keeps offers in line with published rates, updates live quotations. A third sends the new quotation to customers who had asked to be alerted. The error reaches customers before the first agent's output has been looked at. The same pattern generalises to any chain where agents consume each other's output without a checkpoint.