Fallback Path Selection Prompt for Agent Failures

This prompt is designed for SRE teams and platform engineers who operate multi-agent pipelines where a primary agent can fail due to tool errors, timeouts, capability gaps, or model unavailability. Instead of a hard failure, the system must select the best fallback path from a registry of alternative agents, static responses, or human queues. Use this prompt when you need a ranked, reasoned selection of fallback options that considers capability match, degradation impact, latency budget, and cost. It is not a retry prompt or a simple error handler; it assumes the primary agent has already exhausted its recovery options and the orchestrator must now route the task elsewhere.

The ideal user is an orchestration engineer or platform operator who maintains a fallback registry—a structured catalog of available agents, their capabilities, cost profiles, and average latencies. The prompt requires this registry as input, along with the failed agent's context, the original task, and any error diagnostics. It is not suitable for real-time, sub-100ms decision loops where a hardcoded static fallback is more appropriate. Do not use this prompt when the primary agent's failure mode is unknown or when the system lacks a defined fallback registry; in those cases, the output will be speculative and unreliable.

Before wiring this prompt into production, ensure you have instrumented the primary agent's failure signal with enough detail: the error type, the tool that failed, the remaining latency budget, and the task's risk classification. The prompt's value comes from its ability to weigh trade-offs—trading accuracy for speed, or cost for capability—but it can only do that if the input context is complete. Proceed to the prompt template section to see the exact input schema and adapt it to your agent topology.

This prompt is designed to be placed in your orchestrator's error-handling step, immediately after an agent returns a failure status, timeout, or invalid output. Its job is to reason over the available fallback agents, their capabilities, current system state, and the original task to produce a ranked, actionable routing decision. Do not use this prompt for initial task routing; it assumes a failure has already occurred and focuses strictly on graceful degradation.

textCopy
You are a fallback path selector for a multi-agent system. An agent has failed to complete its assigned task. Your job is to select the best fallback agent or path to minimize disruption.

## FAILED AGENT
- Agent ID: [FAILED_AGENT_ID]
- Agent Role: [FAILED_AGENT_ROLE]
- Failure Reason: [FAILURE_REASON]
- Failure Type: [FAILURE_TYPE] (e.g., timeout, tool_error, invalid_output, capability_gap, policy_block)

## ORIGINAL TASK
- Task ID: [TASK_ID]
- User Intent Summary: [USER_INTENT_SUMMARY]
- Required Capabilities: [REQUIRED_CAPABILITIES]
- Task Priority: [TASK_PRIORITY] (e.g., critical, high, medium, low)
- SLA Deadline (ms): [SLA_DEADLINE_MS]
- Remaining SLA Budget (ms): [REMAINING_SLA_BUDGET_MS]

## AVAILABLE FALLBACK AGENTS
[FALLBACK_AGENTS_LIST]
<!-- Each entry: agent_id, role, capabilities (list), current_load (0.0-1.0), avg_latency_ms, cost_per_call_usd, reliability_score (0.0-1.0) -->

## CONSTRAINTS
- Do not select the failed agent.
- Prefer agents whose capabilities cover the required capabilities.
- If no agent covers all required capabilities, select the agent with the highest partial coverage and note the gap.
- If remaining SLA budget is below any agent's avg_latency_ms, recommend a fast-degradation path (e.g., cached response, static fallback, human queue with urgency flag).
- If task priority is critical, prefer reliability over cost.
- If failure type is policy_block, do not route to another automated agent; escalate to human review.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "fallback_decision": {
    "selected_agent_id": string | null,
    "selected_agent_role": string | null,
    "ranked_candidates": [
      {
        "agent_id": string,
        "role": string,
        "capability_match_score": number (0.0-1.0),
        "missing_capabilities": [string],
        "degradation_impact": "none" | "minor" | "moderate" | "severe",
        "estimated_latency_ms": number,
        "estimated_cost_usd": number,
        "rationale": string
      }
    ],
    "escalation_required": boolean,
    "escalation_target": "human_review" | "incident_queue" | null,
    "circuit_breaker_triggered": boolean,
    "decision_rationale_summary": string
  }
}

## RULES
- Rank candidates by capability_match_score descending, then by degradation_impact ascending, then by reliability_score descending.
- If the top candidate has a capability_match_score below [MIN_CAPABILITY_THRESHOLD], set escalation_required to true.
- If the same task has failed more than [MAX_CONSECUTIVE_FAILURES] times across any agents, set circuit_breaker_triggered to true and escalate.
- Provide specific, actionable rationale for each candidate.

Adaptation notes: Replace every square-bracket placeholder with runtime values from your orchestrator's state. The [FALLBACK_AGENTS_LIST] should be populated from your agent registry, filtered to exclude the failed agent and any agents currently in a circuit-broken state. Wire [MAX_CONSECUTIVE_FAILURES] and [MIN_CAPABILITY_THRESHOLD] to your operational config. For high-risk domains, add a [REQUIRES_HUMAN_APPROVAL] boolean field to the output schema and route decisions through a review queue before execution. Validate the JSON output against the schema before acting on the routing decision; if parsing fails, default to the human escalation path and log the raw response for debugging.

This prompt is not a standalone one-shot. It is designed to run inside an agent orchestrator's fallback selection step, triggered only after the primary agent has exhausted its retry budget. The orchestrator should invoke this prompt with a structured context payload containing the original task, the primary agent's failure trace, and the available fallback agent registry. The prompt's output—a ranked list of fallback paths with capability match scores and degradation impact—is then consumed by the orchestrator to route the task to the next best agent or to a human queue.

To integrate this prompt, build a FallbackSelector module in your orchestrator with the following contract: Inputs include [ORIGINAL_TASK] (the user request and any partial results), [FAILURE_TRACE] (error codes, retry count, tool-call failures, timeout events), and [FALLBACK_REGISTRY] (a JSON array of available agents with their capability descriptions, cost profiles, and SLA windows). Output validation must check that the returned JSON contains a ranked_fallbacks array where each entry has agent_id, capability_match_score (0-1 float), degradation_impact (enum: low/medium/high/critical), and rationale (string). Reject and retry the prompt if the top-ranked agent is not present in the input registry or if scores fall outside the 0-1 range. Log every fallback selection event with a fallback_selection_id for traceability.

For production observability, instrument the harness with two key metrics: fallback success rate (did the selected fallback agent complete the task successfully?) and fallback latency (time from primary agent failure to fallback completion). Store these alongside the fallback_selection_id in your monitoring system. If the top-ranked fallback also fails, the orchestrator should re-invoke this prompt with the updated failure trace but exclude the already-failed agent from the registry. Set a hard limit of two fallback attempts before routing to a human review queue with the full failure history. Avoid running this prompt in hot paths where latency is critical—it is a recovery mechanism, not a real-time router.