Dependency Failure Retry Prompt for Chained Tool Calls

This prompt is designed for multi-step agent workflows where a tool call fails not because of a simple typo or transient network error, but because a prior step in the chain produced invalid, missing, or unexpected data that the current step depends on. The core job-to-be-done is backward reasoning through a dependency graph. When your agent harness detects a cascading failure—for example, a get_order_details call returns a malformed customer_id, causing a subsequent lookup_customer_tier call to fail—this prompt instructs the model to stop, identify the root dependency that failed, generate corrected arguments for that upstream call, define a safe rollback scope, and then retry the dependent call. The ideal user is an AI engineer or platform team building an agent harness that already maintains a directed acyclic graph (DAG) of tool call dependencies and can inject that context into the prompt.

Do not use this prompt for single-step tool failures, simple schema validation errors, or infrastructure-level retries (such as HTTP 429 rate limits or 503 service unavailability) where no upstream data dependency exists. Those scenarios are better served by a targeted Invalid Tool Call Schema Repair Prompt or an API and Infrastructure Error Retry strategy. This prompt becomes necessary only when the failure signature indicates that the current tool's arguments are symptomatic of a prior step's output defect. Before invoking this prompt, your harness should confirm that the failing tool call's arguments were derived from a previous tool's response, and that the previous tool's response failed post-hoc validation or produced a null value for a required downstream field. Using this prompt without a clear dependency chain will cause the model to hallucinate a non-existent root cause.

To implement this safely, your harness must provide the model with a structured representation of the dependency graph, including which fields flow from one tool to the next. The prompt template includes placeholders for [DEPENDENCY_GRAPH], [FAILED_TOOL_CALL], and [UPSTREAM_OUTPUTS] to make these relationships explicit. In high-risk domains such as finance or healthcare, the recovery plan produced by this prompt should be treated as a draft recommendation that requires human approval before re-execution, especially if the corrected upstream call would modify persistent state or trigger a side effect. Always log the original failure, the model's identified root cause, and the corrected arguments for auditability. If the model cannot identify a clear root dependency with high confidence, the harness should escalate to a human operator rather than risk a recursive repair loop.

This prompt is designed to be injected into your agent harness immediately after a tool call fails and the error trace indicates that the root cause is not the current tool's logic, but a faulty output from a prior step in the chain. Instead of simply retrying the failed call, this prompt instructs the model to analyze the dependency graph, identify the specific upstream failure, and produce a structured recovery plan. The plan includes a corrected call to the failed dependency and a subsequent retry of the dependent call, effectively rolling back and replaying a segment of the workflow.

textCopy
You are an AI agent orchestrator diagnosing a failure in a chained tool execution workflow. A tool call has failed, and the error trace points to an upstream dependency that produced invalid or missing data.

Your task is to generate a structured recovery plan. Do not re-execute the failed tool call directly. Instead, analyze the provided context to identify the root cause and define the minimal set of corrective actions.

[CONTEXT]
- Original User Goal: [USER_GOAL]
- Dependency Graph (ordered list of completed steps): [DEPENDENCY_GRAPH]
- Failed Tool Call:
  - Tool Name: [FAILED_TOOL_NAME]
  - Arguments: [FAILED_TOOL_ARGUMENTS]
  - Error Message: [ERROR_MESSAGE]
- Upstream Tool Outputs (keyed by step): [UPSTREAM_OUTPUTS]

[CONSTRAINTS]
- The recovery plan must be minimal; only re-execute the specific upstream dependency that failed and the dependent tool call.
- Do not alter arguments for steps that executed successfully and are not implicated in the failure.
- If the error message indicates a data type mismatch, a missing required field, or an invalid value from an upstream output, the corrected upstream call must explicitly fix that issue.
- If the failure is due to a timeout or transient error in the upstream tool, the corrected call should be identical but may include an idempotency key from [UPSTREAM_OUTPUTS] if available.
- If the root cause is ambiguous, propose a single most-likely recovery plan and flag the ambiguity.

[OUTPUT_SCHEMA]
Produce a JSON object with the following structure:
{
  "root_cause_analysis": "A concise explanation of which upstream dependency failed and why.",
  "recovery_plan": [
    {
      "step_number": 1,
      "action": "re-execute_upstream",
      "tool_name": "[UPSTREAM_TOOL_NAME]",
      "corrected_arguments": {},
      "rationale": "Why this corrected call will resolve the root cause."
    },
    {
      "step_number": 2,
      "action": "retry_dependent",
      "tool_name": "[FAILED_TOOL_NAME]",
      "arguments": {},
      "rationale": "Retry the original call with the corrected upstream data now available."
    }
  ],
  "ambiguity_flag": true or false,
  "ambiguity_note": "If ambiguity_flag is true, explain the uncertainty here."
}

[EXAMPLES]
- If an upstream web search returned an empty 'results' array, causing a 'summarize_results' tool to fail with a 'missing required field' error, the corrected upstream call should modify the search query to be broader.
- If an upstream API call returned a 500 error, the corrected call should be identical but the rationale should note the transient nature of the error.

To adapt this template, replace the placeholders with data from your agent's execution context. The [DEPENDENCY_GRAPH] should be a serialized representation of the workflow's steps and their data dependencies, which your harness must maintain. The [UPSTREAM_OUTPUTS] are critical; inject the raw outputs of all completed steps so the model can inspect the actual data that caused the failure. After receiving the recovery plan, your harness must parse the JSON, validate that the proposed tool_name values exist in your tool registry, and then execute the steps in order. If the ambiguity_flag is true, log the plan and escalate to a human operator or a more capable model for review before executing any tool calls.

The Dependency Failure Retry Prompt is not a standalone prompt—it is a recovery subroutine inside an agent execution harness. When a tool call fails because a prior dependency produced invalid, missing, or malformed data, the harness must pause the execution pipeline, construct a dependency graph snapshot, and invoke this prompt to produce a recovery plan. The prompt expects the harness to supply: the original user intent, the failed tool call and its error, the dependency chain that led to the failure, and the output of the upstream dependency that caused the problem. Without this context, the model cannot distinguish between a dependency failure and a simple argument error.

Harness integration steps: (1) Trap tool-call failures and classify the error type. If the error is a schema violation, missing parameter, or type error on the current call, route to the appropriate single-call recovery prompt instead. This prompt is specifically for failures where the current call's arguments are correct but the data they depend on is wrong. (2) Walk the execution DAG backward from the failed call to identify the upstream dependency whose output is suspect. Capture the dependency's tool name, arguments, raw output, and any validation errors that output produced. (3) Assemble the [DEPENDENCY_GRAPH] placeholder as a structured summary showing the causal chain: which call produced which output, how that output fed into the failed call, and where the break occurred. (4) Inject the [RETRY_BUDGET_REMAINING] and [MAX_ROLLBACK_DEPTH] constraints so the model knows whether it can propose re-executing multiple upstream steps or must limit recovery to the immediate dependency. (5) Parse the model's recovery plan—it should return a structured decision: either a corrected argument set for the failed dependency (with rollback instructions) or an escalation signal when recovery is infeasible.

Validation and safety gates: Before executing any re-run proposed by the recovery plan, validate that the corrected dependency arguments conform to that tool's schema. If the plan proposes rolling back multiple steps, check that each step's output is still needed and that re-execution won't cause side effects (e.g., duplicate writes, state mutations). For high-risk workflows—financial transactions, clinical data, legal filings—require human approval before re-executing any dependency that produced a side effect. Log every recovery attempt with: the original failure, the dependency graph snapshot, the model's proposed plan, validation results, and the outcome of re-execution. This audit trail is essential for debugging retry loops and demonstrating governance compliance.

Model choice and performance: This prompt requires strong reasoning about causal chains and trade-offs. Use a capable model (GPT-4-class or equivalent) for the recovery planning step. Do not use a lightweight model here—misidentifying the root dependency or proposing an unsafe rollback can amplify the original failure. Cache the dependency graph structure across retry attempts to avoid redundant context reconstruction. If the recovery plan itself fails validation or produces another dependency failure, increment the retry counter and check against [RETRY_BUDGET_MAX]. When the budget is exhausted, bypass the prompt entirely and route to the Tool Call Retry Budget Exhaustion Escalation Prompt to produce a structured handoff to a human operator or fallback workflow. Never let the harness loop indefinitely on dependency failures—convergence is not guaranteed when upstream data is fundamentally broken.