Contingency Planning

A fallback execution path is a predefined, alternative sequence of actions an agent switches to when its primary plan fails or violates a performance threshold. This is a core fault-tolerance mechanism.

• Example: An agent generating a report first attempts to call a proprietary data API. If the API times out, its fallback path queries a cached database snapshot.
• Design Principle: Fallbacks should be simpler, more reliable, and often provide degraded but acceptable functionality (graceful degradation).
• Key Consideration: Fallback logic must include clear triggers (e.g., timeout, error code, confidence score) to avoid unnecessary switching.

A compensating action is an operation designed to semantically undo the effects of a previously committed action, enabling forward recovery. This is critical for maintaining system state consistency after partial failures.

• Contrasts with Rollback: While action rollback reverts to a prior checkpoint, a compensating action logically 'cancels' a specific effect (e.g., issuing a refund to compensate for a processed charge).
• Use Case: Essential in Saga Pattern implementations for distributed, long-running transactions where a simple database rollback is not feasible.
• Challenge: Designing idempotent compensating actions that can be safely retried.

This is the systematic process of identifying and categorizing failures. Effective contingency planning requires precise error detection to trigger the correct recovery procedure.

• Detection Methods: Timeouts, exception handling, output validation frameworks, anomaly detection on metrics, and LLM-based self-evaluation of result quality.
• Classification: Errors are categorized (e.g., Transient Network, Permanent Tool Failure, Logical Error, Data Validation Error) to map to specific contingencies.
• Integration: Feeds directly into automated root cause analysis and informs the selection of corrective action planning strategies.

Dynamic replanning is the real-time generation of a new action sequence when the original plan becomes invalid. Goal-directed repair focuses this effort on finding a minimal path from the current (possibly erroneous) state to the original objective.

• Mechanisms: Often employs backtracking search to a viable decision point or uses constraint relaxation to find a feasible, if suboptimal, solution.
• Context-Awareness: Effective replanning incorporates real-time environmental data and system state (context-aware replanning).
• Relation to Planning: Leverages flexible paradigms like partial order planning where actions have minimal sequencing, allowing for runtime reordering.

State recovery is the mechanism for restoring an agent's operational context after a failure. This relies on robust state management throughout execution.

• Checkpoint/Restore: Periodically saving a complete, serializable snapshot of the agent's internal state and external context to allow rollback to a known-good point.
• Challenge: State must be immutable and versioned to support reliable recovery. This often involves write-ahead logging (WAL) principles.
• Scope: Includes conversation history, tool call results, environmental variables, and the agent's own reasoning chain.

These are foundational software engineering patterns applied to agentic systems to prevent localized failures from causing total collapse.

• Circuit Breaker Pattern: Prevents an agent from repeatedly calling a failing external service, allowing it time to recover.
• Bulkhead Isolation: Partitions resources (e.g., pools for different tool calls) so a failure in one partition doesn't exhaust all resources.
• Retry with Exponential Backoff: A strategy for transient failures, increasing wait time between retries to reduce load.
• Deadline Propagation: Enforcing time constraints across a chain of actions so upstream processes can fail fast.

A primary use case is handling the unreliability of external dependencies. A well-designed contingency plan for an agent calling a payment gateway API would include:

• Primary Path: Call the primary payment provider (e.g., Stripe).
• Contingency 1: Retry the call with exponential backoff.
• Contingency 2: Switch to a secondary provider (e.g., PayPal) using cached credentials.
• Contingency 3: Log the transaction to a durable queue for asynchronous processing and immediately notify the user of a delay. This layered approach ensures the core business function—initiating a payment—can proceed despite transient or persistent downstream failures.

Contingency plans activate when ingested data fails validation rules. For an agent processing customer support tickets:

• Validation Failure: If a ticket lacks a required customer_id field, the contingency plan prevents the main classification model from running.
• Contingency Action: The agent routes the ticket to a low-confidence queue, appends a request for clarification to the customer, and invokes a secondary, rule-based triage system.
• Outcome: This prevents garbage-in/garbage-out scenarios, maintains service quality, and provides a clear audit trail for data issues.

When a language model agent generates an output with low confidence or detected hallucinations, contingency planning dictates the recovery path.

• Detection: The agent's self-evaluation layer flags an answer as ungrounded or below a confidence threshold (e.g., < 85%).
• Contingency Execution: Instead of presenting the flawed output, the agent:
  1. Switches to a verification tool to fact-check key claims against a knowledge base.
  2. Reformulates the query using a different prompt strategy (e.g., chain-of-thought).
  3. As a final fallback, escalates to a more capable (but slower/costlier) model for regeneration. This ensures outputs meet a minimum reliability bar before being acted upon.

In embodied systems like autonomous mobile robots (AMRs), contingency planning is critical for safety and task completion. For a robot navigating a warehouse:

• Primary Plan: Follow the calculated optimal path to Bin A7.
• Contingency Triggers: An unexpected obstacle (e.g., a fallen box) blocks the path.
• Contingency Actions:
  • Replan: The robot's local planner immediately calculates a new route around the obstacle.
  • Escalate: If the obstacle is unmovable and blocks all paths, the robot classifies it as a navigation fault, marks the location on the shared map, and requests human assistance via the fleet manager.
  • Task Adaptation: If Bin A7 is unreachable, the system may dynamically reassign the pick to another robot.

In systems where multiple agents compete for shared resources, contingency plans resolve deadlocks. Consider agents managing cloud compute instances:

• Failure Mode: Two agents simultaneously request the last available GPU instance, leading to a race condition and failed deployments.
• Contingency Protocol: The orchestration layer detects the conflict via a distributed lock service.
• Resolution Path: A pre-defined priority-based backoff rule is invoked. The lower-priority agent's contingency plan executes:
  1. Releases its claim.
  2. Waits a randomized interval.
  3. Requests a less optimal instance type (CPU-only) to keep its broader workflow progressing.
  4. Schedules a retry for the preferred resource at a later time. This prevents system-wide gridlock.

For systems governed by regulations (e.g., GDPR, HIPAA), contingency plans handle potential compliance violations. An agent processing personal data might have a plan for:

• Trigger: Detection of an attempt to export data to an unapproved geographical region.
• Contingency Actions:
  1. Immediate Block: The export action is halted.
  2. State Isolation: The data involved is quarantined.
  3. Compensating Action: Any preparatory steps (e.g., temporary file creation) are securely erased.
  4. Mandatory Logging: A high-severity incident is logged to an immutable audit system with full context.
  5. Human Alert: The security team is automatically notified. This transforms a potential breach into a documented, contained security event.

The real-time modification of an autonomous agent's sequence of actions or tool calls in response to errors, changing conditions, or new information during execution. Unlike pre-scripted contingency plans, this involves generating a new plan on-the-fly.

• Key Mechanism: Often triggered by a monitor-and-repair loop.
• Example: A delivery robot recalculating its route after encountering a blocked road, considering new traffic data.

A fault-tolerant strategy where an autonomous system switches to a predefined alternative action or workflow when a primary operation fails or exceeds performance thresholds. This is a core implementation of a contingency plan.

• Structure: Typically involves a hierarchy of methods (e.g., primary LLM → smaller LLM → rule-based system).
• Use Case: An API call fails; the agent uses cached data or a simplified local calculation instead.

The process of modifying a partially executed or failed plan to achieve the original goal, often by substituting actions, reordering steps, or relaxing constraints. It focuses on minimal deviation from the original plan.

• Contrast with Replanning: Tends to be more surgical than generating a wholly new plan.
• Techniques: May use goal-directed repair or backtracking search to find the point of failure and patch the plan.

An operation specifically designed to semantically undo or counteract the effects of a previously executed action. This enables forward recovery in long-running, stateful processes.

• Critical for: Implementing the Saga pattern for distributed transactions.
• Example: An e-commerce agent that successfully charges a card but fails to reserve inventory executes a refund as a compensating action.

A system design principle where functionality is progressively reduced in a controlled manner under failure or high-load conditions to maintain core service availability. It is a systemic form of contingency planning.

• Implementation: May involve disabling non-essential features, switching to lower-fidelity models, or increasing latency tolerances.
• Goal: Preserve user trust and core utility when perfect operation is impossible.

A fail-fast design pattern that prevents an application from repeatedly attempting an operation that is likely to fail (e.g., a downed external API). It is a key contingency mechanism for tool-calling agents.

• States: Closed (normal operation), Open (failing fast), Half-Open (testing recovery).
• Purpose: Allows underlying services time to recover and prevents resource exhaustion from cascading failures.