Fallback Mechanism

Overview

Agents fail, pipelines go down, models return unusable output, and external dependencies time out. In multi-agent systems, a failure at one node can silently stall or corrupt the whole flow. Designing only for the happy path assumes failures never happen. Fallback Mechanism treats degradation as a normal state: a clear path to route work to a person or a simpler automated process when the primary agent can't complete its task.

When to use

Multi-agent considerations

In a single-agent flow, fallback is contained: one agent fails, one handoff to a person. In a multi-agent flow, failure is harder to detect and harder to contain.

• A failure mid-flow may not surface until a downstream agent produces an obviously wrong result, by which time several steps have run on bad input.
• The fallback has to hand off not just the work item but the flow state: what each agent received, what it decided, and where in the chain the failure happened.
• Kill switches must be scoped. Halting the whole pipeline when only one node has failed causes unnecessary disruption, so design node-level and pipeline-level stops separately.
• Fully automated modes should be off after a fallback event and need an explicit operator decision to turn back on.

Questions to ask

Ask these at kickoff, when design work starts. Tick them off as your team answers.

• What does the system show when the agent is unavailable? Is the degraded state visible or silent?
• Which fallback path takes over: a human queue, a rule-based step, or a simpler automated process?
• Who is notified when a fallback is triggered, and through which channel?
• In a multi-agent flow, can individual nodes be halted without stopping the whole pipeline?
• What context does the person or fallback process receive when taking over mid-flow?
• How does the system restart after a fallback: does it need a person's decision, or does it recover automatically?

Example

An automated document pipeline stalls because the classification service times out. Items stop moving, but the system doesn't drop them or carry on silently. The operator view shows the pipeline as degraded, how many items are affected and at which step. From the same view, the operator can route held items to a manual review queue or halt the pipeline. When the service recovers, the operator restarts it; it doesn't resume on its own.

Anti-pattern: Silent failure

The agent goes down and items stop moving. No alert fires, the dashboard doesn't change and no queue fills. The operator finds out when someone notices nothing has happened for two hours. Items are in an unknown state, with no record of what the agent had processed when it failed.

Anti-patterns to pay attention to

• Agent failure causes no visible change in the operator view.
• There's no kill switch or manual override for automated modes.
• The fallback hands work to a person without the context the agent had.
• The pipeline resumes automatically after a failure, without a person deciding to restart it.

References

Related

• User Action Recovery · Agent Behaviour
• Monitoring Dashboard · Human Oversight
• Audit Trail · Agent Behaviour
• Hard Gate · Human Oversight

Principles applied