Error Propagation Rules Across Tool Steps Prompt

This prompt is for platform engineers and agent infrastructure developers who need to define explicit failure semantics for multi-step tool chains. The core job is to produce a machine-readable set of rules that govern how an error at any step in a sequence propagates to downstream steps, including classification of the error type, retry eligibility, partial result preservation, and abort conditions. You should use this prompt when you are building an agent harness that orchestrates multiple tool calls and you cannot afford silent error swallowing, cascading retries that mask root causes, or over-propagation that aborts an entire workflow when partial results are still valuable. The ideal user has a concrete tool chain topology in hand—a list of steps, their dependencies, and the expected output schema for each—and needs to encode failure-handling logic that the agent runtime can execute deterministically.

Do not use this prompt for single-step tool calls, simple try/catch wrappers, or workflows where the agent is expected to reason about errors in an ad-hoc way. This prompt is also inappropriate when the error taxonomy is undefined or when the team has not agreed on what constitutes a retryable versus terminal failure. If you are still designing the tool contracts themselves, start with the Tool Contract Definition and Schema Mapping playbook first. If you need to define the overall sequence plan, use the Tool Call Sequence Planning Prompt Template. This prompt assumes you already know the happy path and are now hardening it against the unhappy paths that will occur in production. It is a reliability engineering artifact, not a planning artifact.

Before using this prompt, gather your tool chain's dependency graph, the error codes or exception types each tool can produce, and your organization's policies on retry budgets, idempotency requirements, and human escalation thresholds. The output of this prompt should feed directly into your agent's execution loop as a structured ruleset that the orchestrator evaluates after each tool call. If your workflow involves financial transactions, healthcare data, or irreversible side effects, you must pair these propagation rules with human approval gates and audit logging—this prompt defines the automation logic, not the governance layer. After generating the rules, test them against a matrix of injected failures at each step to verify that error swallowing, over-propagation, and recovery path gaps are caught before deployment.

This prompt template produces a structured error propagation specification for a defined tool chain. It takes a sequence of tool steps, their expected outputs, and the failure modes you care about, then returns classification rules, retry eligibility, partial result preservation instructions, and recovery path definitions. Use it when you need explicit, machine-readable failure semantics before wiring an agent into production tool orchestration.

textCopy
You are defining error propagation rules for a multi-step tool execution chain. Your output will be consumed by an agent execution engine that needs deterministic failure handling.

## TOOL CHAIN DEFINITION
[TOOL_CHAIN_STEPS]
<!-- Each step must include: step_id, tool_name, description, expected_output_schema, is_mutable (boolean), and dependencies (list of step_ids) -->

## ERROR CLASSIFICATION TAXONOMY
[ERROR_TAXONOMY]
<!-- Define the error categories you want the rules to use, e.g., TRANSIENT, PERMANENT_INPUT, PERMANENT_DEPENDENCY, TIMEOUT, PERMISSION, DATA_CORRUPTION, RATE_LIMITED -->

## CONSTRAINTS
[CONSTRAINTS]
<!-- e.g., max_total_retries, max_retries_per_step, required_human_approval_for_categories, idempotency_requirements, data_sensitivity_level -->

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "tool_chain_id": "string",
  "error_propagation_rules": [
    {
      "step_id": "string",
      "error_category": "string from taxonomy",
      "propagation_action": "BLOCK_CHAIN | CONTINUE_WITH_DEFAULT | CONTINUE_WITH_PARTIAL | RETRY | ESCALATE_HUMAN | CALL_FALLBACK",
      "retry_policy": {
        "max_retries": "integer",
        "backoff_strategy": "CONSTANT | LINEAR | EXPONENTIAL",
        "retryable_error_subtypes": ["string"]
      },
      "partial_result_preservation": {
        "preserve_fields": ["string"],
        "discard_fields": ["string"],
        "preservation_condition": "string describing when partial results are safe to keep"
      },
      "fallback_step_id": "string or null",
      "human_approval_required": "boolean",
      "downstream_impact": {
        "affected_steps": ["string"],
        "impact_description": "string explaining what downstream steps receive (error, default, partial, nothing)"
      },
      "recovery_path": "string describing how the chain can recover from this error, or 'NONE'"
    }
  ],
  "global_abort_conditions": [
    {
      "condition": "string describing when to abort the entire chain",
      "cleanup_actions": ["string"],
      "user_notification_template": "string"
    }
  ],
  "partial_success_policy": {
    "commit_partial_results": "boolean",
    "rollback_instructions": "string or null",
    "compensating_actions": [{"step_id": "string", "action": "string"}]
  }
}

## RULES
1. Every step in TOOL_CHAIN_STEPS must have at least one error_propagation_rule covering its most likely failure mode.
2. If a step has dependencies, include rules for PERMANENT_DEPENDENCY errors when an upstream step fails.
3. For mutable steps (is_mutable: true), partial_result_preservation must be conservative—prefer discard over preserve when data consistency is at risk.
4. RETRY actions require a retry_policy. BLOCK_CHAIN actions must specify downstream_impact.
5. ESCALATE_HUMAN actions require human_approval_required: true and a recovery_path that explains what the human must decide.
6. If CONSTRAINTS specify idempotency requirements, ensure retry policies do not violate them.
7. Do not invent error categories outside the provided ERROR_TAXONOMY.
8. If a recovery path is impossible, set recovery_path to "NONE" and ensure the downstream_impact explains the terminal state.

## EXAMPLE INPUT
TOOL_CHAIN_STEPS:
- step_id: "fetch_customer", tool_name: "get_customer", description: "Retrieve customer record by ID", expected_output_schema: {customer_id: string, name: string, tier: string}, is_mutable: false, dependencies: []
- step_id: "apply_discount", tool_name: "update_invoice", description: "Apply tier-based discount to invoice", expected_output_schema: {invoice_id: string, discount_applied: float, new_total: float}, is_mutable: true, dependencies: ["fetch_customer"]

ERROR_TAXONOMY: ["TRANSIENT", "PERMANENT_INPUT", "PERMANENT_DEPENDENCY", "TIMEOUT"]

CONSTRAINTS: max_retries_per_step=3, required_human_approval_for_categories=["PERMANENT_INPUT"]

## EXAMPLE OUTPUT
{
  "tool_chain_id": "discount_application",
  "error_propagation_rules": [
    {
      "step_id": "fetch_customer",
      "error_category": "TRANSIENT",
      "propagation_action": "RETRY",
      "retry_policy": {"max_retries": 3, "backoff_strategy": "EXPONENTIAL", "retryable_error_subtypes": ["NETWORK_ERROR", "TIMEOUT"]},
      "partial_result_preservation": {"preserve_fields": [], "discard_fields": [], "preservation_condition": "N/A"},
      "fallback_step_id": null,
      "human_approval_required": false,
      "downstream_impact": {"affected_steps": ["apply_discount"], "impact_description": "Downstream step blocked until retry succeeds or exhausts"},
      "recovery_path": "Retry with exponential backoff; if exhausted, escalate as PERMANENT_DEPENDENCY"
    },
    {
      "step_id": "fetch_customer",
      "error_category": "PERMANENT_INPUT",
      "propagation_action": "ESCALATE_HUMAN",
      "retry_policy": null,
      "partial_result_preservation": {"preserve_fields": [], "discard_fields": [], "preservation_condition": "N/A"},
      "fallback_step_id": null,
      "human_approval_required": true,
      "downstream_impact": {"affected_steps": ["apply_discount"], "impact_description": "Chain blocked; human must provide valid customer ID or abort"},
      "recovery_path": "Human provides corrected customer ID; chain restarts from fetch_customer"
    },
    {
      "step_id": "apply_discount",
      "error_category": "PERMANENT_DEPENDENCY",
      "propagation_action": "BLOCK_CHAIN",
      "retry_policy": null,
      "partial_result_preservation": {"preserve_fields": [], "discard_fields": [], "preservation_condition": "N/A"},
      "fallback_step_id": null,
      "human_approval_required": false,
      "downstream_impact": {"affected_steps": [], "impact_description": "No further steps; chain terminates with error"},
      "recovery_path": "NONE"
    }
  ],
  "global_abort_conditions": [
    {"condition": "Any step exhausts retries without fallback", "cleanup_actions": ["log_failure", "notify_on_call"], "user_notification_template": "Tool chain {tool_chain_id} failed at step {step_id} with error {error_category}. Manual intervention required."}
  ],
  "partial_success_policy": {
    "commit_partial_results": false,
    "rollback_instructions": "Discard all state; no partial commits for mutable discount operations",
    "compensating_actions": []
  }
}

## YOUR TASK
Using the TOOL_CHAIN_STEPS, ERROR_TAXONOMY, and CONSTRAINTS provided above, generate the complete error propagation specification following the OUTPUT SCHEMA and RULES exactly.

Adaptation notes: Replace [TOOL_CHAIN_STEPS] with your actual step definitions—each step needs a unique ID, the tool name, its output schema, whether it mutates state, and its upstream dependencies. Replace [ERROR_TAXONOMY] with the error categories your platform can detect and handle programmatically. Replace [CONSTRAINTS] with your operational bounds: retry limits, approval requirements, idempotency guarantees, and data sensitivity levels. The example input and output are included in the prompt to ground the model in your expected shape—keep them or replace them with your own canonical examples. For high-risk chains where incorrect propagation rules could cause data corruption or financial impact, always route the generated specification through human review before loading it into your agent execution engine.

The error propagation rules prompt is designed to sit between your tool orchestration engine and the agent's execution loop. It should be invoked before any multi-step tool sequence begins, producing a static or semi-static rule set that the orchestrator enforces at runtime. The prompt takes a list of tool definitions, their dependency graph, and your organization's reliability requirements, then outputs structured propagation rules—error classifications, retry eligibility, partial result preservation policies, and abort conditions. This rule set becomes the contract that your orchestrator reads on every tool failure, eliminating the ambiguity that causes agents to silently swallow errors or cascade failures across unrelated steps.

Wiring the prompt into your application requires three integration points. First, a pre-execution hook calls the prompt with the planned tool sequence and receives the rule set as structured JSON. Store this rule set alongside the execution plan in your state store. Second, a runtime error handler intercepts every tool call failure and consults the rule set to decide: classify the error (transient, permanent, data-corruption, auth, timeout), determine retry eligibility with backoff parameters, identify which downstream steps must be skipped or can proceed with degraded inputs, and preserve any partial results that the rules mark as salvageable. Third, a post-execution audit logger records every error event, the rule that fired, the decision made, and the resulting state change. This audit trail is essential for debugging silent failures and proving governance to reviewers. For high-risk domains, insert a human approval gate when the rules trigger an abort condition or when error classification confidence falls below your threshold—the prompt's [RISK_LEVEL] parameter should map to your approval policy.

Validation and testing must happen at two levels. At the rule-generation level, validate the prompt's output against a schema that enforces: every tool step has an error classification mapping, retry policies include max attempts and backoff strategy, abort conditions reference specific error types and severity thresholds, and partial result preservation rules specify which output fields survive which failure modes. Run regression tests with known tool failure scenarios—a timeout on step 2, an auth failure on step 4, a malformed output on step 1—and verify the generated rules produce the expected propagation behavior. At the runtime level, instrument your orchestrator to detect rule violations: errors that propagate when rules said to abort, retries that exceed max attempts, partial results that were preserved when rules said to discard. These violations are your leading indicators that the prompt's output has drifted or that new failure modes have emerged that the rules don't cover. Model choice matters: use a model with strong structured output capabilities and low refusal rates on technical specification tasks. GPT-4o and Claude 3.5 Sonnet perform well here; avoid smaller models that conflate error types or produce incomplete rule coverage. Cache the rule set aggressively—error propagation rules should only change when the tool sequence or reliability requirements change, not on every execution.

What to avoid: Do not treat the prompt's output as advisory. If your orchestrator can override the rules at runtime, you've reintroduced the ambiguity this prompt exists to eliminate. Do not skip the audit logging—without it, you'll never know whether errors were handled correctly or silently swallowed. Do not use this prompt for sequences with fewer than three tool calls; the overhead isn't justified for simple chains. And do not assume the rules are complete on first generation. Run the eval harness described in the topic's evaluation section against your actual tool failure history, and iterate on the prompt's [CONSTRAINTS] and [TOOLS] descriptions until the rules cover your real failure distribution. The next step after implementing this harness is to wire the generated rules into your observability stack so that every error propagation decision appears in your traces alongside the tool call spans.