Fallback Chain Definition Prompt for Multi-Tool Workflows

This prompt is for agent application developers and platform reliability engineers who need to design resilient multi-tool workflows. The core job-to-be-done is taking a primary tool and its dependency graph, then producing an ordered, executable fallback chain. Each step in the chain must include eligibility conditions, a clear description of the capability gap compared to the primary tool, and explicit stop conditions that prevent infinite fallback loops. The ideal user is someone who already has a tool registry, understands their tools' failure modes, and needs a structured, repeatable way to define degradation paths rather than ad-hoc try/catch blocks in application code.

Use this prompt when you are building a new agent workflow that depends on a critical external tool—such as a payment processor, a vector database, or a proprietary API—and you need to define what happens when that tool is unavailable, returns invalid data, or exceeds a rate limit. It is also appropriate when refactoring an existing brittle workflow to add resilience. The prompt requires a well-defined input context: a primary tool specification, a list of available alternative tools with their capabilities and limitations, and the dependency relationships between them. Without this structured input, the model will generate a plausible but impractical chain that fails in production.

Do not use this prompt for simple single-tool retry logic, which is better handled by a dedicated retry decision prompt. It is also inappropriate when the fallback tools are not well-defined or when the capability gap between the primary and fallback tools is so large that any fallback would produce a fundamentally incorrect result. In high-stakes domains like healthcare or finance, the generated fallback chain must be treated as a draft for human review; the prompt includes a [RISK_LEVEL] parameter that, when set to high, should automatically route the output to an approval queue before it is wired into production. The next step after reading this section is to gather your tool specifications and dependency graph, then proceed to the prompt template to generate your first chain.

This prompt template takes a primary tool, its dependency graph, and a registry of available alternatives to produce a structured fallback chain definition. The output is designed to be consumed directly by an agent orchestrator's runtime logic, not just read by a human. Each fallback step includes the tool name, the conditions under which it is eligible, the capability gaps compared to the primary tool, and explicit stop conditions that prevent infinite fallback loops.

textCopy
You are defining a fallback chain for a multi-tool agent workflow. Your output will be parsed by an orchestrator and must follow the exact schema.

PRIMARY TOOL:
[PRIMARY_TOOL_NAME]

PRIMARY TOOL DEPENDENCY GRAPH:
[DEPENDENCY_GRAPH]

AVAILABLE TOOL REGISTRY (name, capabilities, constraints, cost_profile):
[TOOL_REGISTRY]

TASK CONTEXT:
[TASK_CONTEXT]

CONSTRAINTS:
- Maximum fallback depth: [MAX_DEPTH]
- Required capabilities that must be preserved: [REQUIRED_CAPABILITIES]
- Forbidden tools or capability combinations: [FORBIDDEN_TOOLS]
- Latency budget per fallback step (ms): [LATENCY_BUDGET_MS]
- Risk level: [RISK_LEVEL]

OUTPUT_SCHEMA:
{
  "primary_tool": "string",
  "fallback_chain": [
    {
      "priority": "integer starting at 1",
      "tool_name": "string",
      "eligibility_conditions": ["condition string"],
      "capability_gaps": ["gap description string"],
      "gap_severity": "critical | major | minor | acceptable",
      "stop_conditions": ["condition that aborts this fallback path"],
      "expected_latency_ms": "integer"
    }
  ],
  "circular_dependency_check": {
    "cycles_detected": "boolean",
    "cycle_details": ["string describing any cycle found"]
  },
  "chain_completeness": {
    "all_required_capabilities_covered": "boolean",
    "uncovered_capabilities": ["string"]
  },
  "degradation_summary": "string describing overall capability loss from primary to last fallback"
}

RULES:
1. Each fallback step must be strictly ordered by priority.
2. Eligibility conditions must reference specific error types, capability requirements, or state conditions from the dependency graph.
3. Stop conditions must prevent infinite loops, including: repeated tool invocation, circular dependencies, budget exhaustion, and capability degradation below a usable threshold.
4. If no fallback covers a required capability, flag it in chain_completeness.uncovered_capabilities.
5. For risk_level "high" or "critical", include a stop condition that escalates to human review before the last fallback is exhausted.
6. Do not include the primary tool in the fallback chain.
7. Detect and report any circular dependencies where fallback tool A depends on fallback tool B which depends on fallback tool A.

To adapt this prompt, replace each square-bracket placeholder with concrete values from your tool registry and task definition. The [TOOL_REGISTRY] should be a structured list of tool objects with name, capabilities array, constraints, and cost profile fields. The [DEPENDENCY_GRAPH] should describe what the primary tool depends on—upstream data sources, auth services, other tool outputs—so the model can reason about cascading failures. Before deploying, validate the output against the schema programmatically and run the chain through a circular dependency detector. For high-risk workflows, add a human approval gate that reviews the fallback chain before the orchestrator executes it.

The fallback chain definition prompt is not a one-off query; it is a configuration-generation step that should run inside a controlled harness before any multi-tool workflow executes. The harness is responsible for providing the prompt with a complete, machine-readable dependency graph, a registry of available tools with their capability signatures, and the specific failure context that triggered the fallback evaluation. The prompt's output—an ordered list of fallback steps with eligibility conditions, capability gaps, and stop conditions—must be treated as structured configuration that downstream orchestrators consume, not as free-text advice. This means the harness must validate the output schema before the fallback chain is loaded into the execution loop.

Validation and Schema Enforcement. The harness must validate that the generated fallback chain is a valid JSON array, that each step includes the required fields (tool_name, eligibility_conditions, capability_gap_assessment, stop_condition), and that no circular dependencies exist (e.g., Tool A falls back to Tool B which falls back to Tool A). Implement a post-generation validator that walks the chain and rejects any output that references tools not present in the provided registry or that creates dependency loops. For high-stakes workflows—such as payment processing or clinical data retrieval—add a human review gate that surfaces the generated chain for approval before it is activated. Log the raw prompt, the generated chain, and the validator results as an audit trail entry.

Caching and Chain Reuse. Fallback chains for a given tool and failure mode are often stable across many invocations. The harness should cache generated chains keyed by a hash of (primary_tool, failure_type, tool_registry_version, dependency_graph_hash). Before invoking the LLM, check the cache. When the tool registry or dependency graph changes, invalidate the cache and regenerate. This reduces latency and cost while ensuring that stale chains do not survive infrastructure changes. Model choice matters here: use a model with strong structured-output discipline (e.g., GPT-4o with response_format or Claude with tool-use mode) and set temperature=0 to maximize reproducibility. If the generated chain fails validation, retry once with the validation errors appended to the prompt as additional [CONSTRAINTS]. If the retry also fails, escalate to a human operator and fall back to a hardcoded safe default chain.

Wiring into the Orchestrator. Once validated, the fallback chain is loaded into the agent's tool-execution loop. The orchestrator should treat each fallback step as a guarded transition: check eligibility_conditions against the current state before invoking the fallback tool, log the capability_gap_assessment for observability, and honor the stop_condition to prevent infinite fallback cascades. If the chain is exhausted without success, the orchestrator must execute the final escalation action—typically a human handoff or a graceful degradation message to the user. Never allow the agent to hallucinate a tool result when the fallback chain is empty.