Partial Success Handling in Tool Chains Prompt

This prompt is for agent developers and platform engineers who need their multi-step tool chains to survive partial failure without losing completed work or producing inconsistent state. The job-to-be-done is generating explicit instructions that tell an agent how to preserve successful step results, report which steps failed and why, and decide whether to commit partial work, roll back, or escalate. The ideal user already has a working tool chain but has observed production incidents where one failed step caused the entire workflow to discard valid results, or where partial commits left downstream systems in an unrecoverable state. You need this prompt when your agent orchestrates three or more tool calls with data dependencies, when some tools have side effects that cannot be easily undone, or when the business can tolerate partial completion but cannot tolerate silent data corruption.

Do not use this prompt for single-tool invocations, simple retry loops, or workflows where atomicity is already guaranteed by the underlying system. If your tool chain is stateless and idempotent by design, a basic error-handling wrapper is sufficient. This prompt becomes necessary when you cross the threshold into multi-step workflows with mixed success states—for example, an agent that successfully creates a ticket in one system, updates a record in a second, but fails to send a notification in a third. Without explicit partial-success handling, the agent will either discard the ticket and update (wasting work) or silently proceed (leaving the notification gap undetected). The prompt template requires you to supply the tool sequence, expected outputs per step, side-effect classifications, and your organization's policy on partial commits. If you cannot articulate which steps are reversible and which are not, resolve that ambiguity before using this prompt.

The output you should expect is a structured handling plan that includes: a per-step success/failure classification, rules for preserving successful results, a decision matrix for commit-vs-rollback based on failure location and severity, and a user-facing summary template that honestly reports partial completion. Wire this into your agent's execution loop after each tool call returns, not just at the end of the sequence. The most common production failure mode is not the prompt itself but the integration point—agents that buffer all results and only apply the handling logic after the final step, by which time partial state has already leaked into downstream systems. Start by implementing the per-step preservation logic first, then add the commit decision logic, and only then expose partial-success summaries to end users. If any step in your chain triggers irreversible external effects (payments, provisioning, credential issuance), insert a human approval gate before that step executes, regardless of what the prompt's decision matrix recommends.

This prompt template instructs the model to execute a sequence of tool calls while explicitly handling partial success. It separates the workflow into three phases: execution with per-step result tracking, a structured summary of successes and failures, and a decision framework for whether to commit partial work, roll back, or escalate. Use this template when your agent orchestrates multiple dependent or independent tool calls where some steps may fail while others succeed, and you need the agent to preserve successful results rather than discarding everything on first failure.

codeCopy
You are an agent executing a multi-step tool workflow. Your primary directive is to maximize useful completion while preventing data inconsistency. Follow these rules:

## EXECUTION PHASE
1. Execute each tool call in the specified order: [TOOL_SEQUENCE].
2. After each tool call, record the result in this structure:
   - step_id: [STEP_IDENTIFIER]
   - tool_name: [TOOL_NAME]
   - status: SUCCESS | FAILURE | PARTIAL
   - output_summary: [BRIEF_RESULT_DESCRIPTION]
   - error_details: [ERROR_MESSAGE_IF_FAILED]
   - data_preserved: [KEY_OUTPUT_FIELDS_SAVED]
3. If a step fails, do NOT discard successful results from previous steps.
4. If a step produces partial results (e.g., batch operation with some items failed), preserve the successful subset and note which items failed.

## DECISION PHASE
After all steps complete or an abort condition is triggered, evaluate the results against these rules:
- If [COMMIT_THRESHOLD]% or more steps succeeded AND no data integrity constraint is violated, mark the workflow as PARTIAL_SUCCESS and preserve all successful outputs.
- If a step failure makes downstream steps impossible due to missing dependencies, skip those dependent steps and mark them as BLOCKED.
- If [ABORT_CONDITIONS] are met, stop execution, preserve results so far, and escalate.
- If any step violates [DATA_INTEGRITY_RULES], mark the entire workflow as REQUIRES_ROLLBACK and list the compensating actions needed.

## OUTPUT FORMAT
Return a JSON object with this schema:
{
  "workflow_status": "COMPLETE" | "PARTIAL_SUCCESS" | "REQUIRES_ROLLBACK" | "ESCALATED",
  "steps_executed": [
    {
      "step_id": "string",
      "tool_name": "string",
      "status": "SUCCESS" | "FAILURE" | "PARTIAL" | "BLOCKED" | "SKIPPED",
      "output_summary": "string",
      "error_details": "string | null",
      "data_preserved": {}
    }
  ],
  "successful_outputs": {},
  "failed_steps": [],
  "blocked_steps": [],
  "rollback_actions": [],
  "escalation_reason": "string | null",
  "recommendation": "string"
}

## CONSTRAINTS
- Never fabricate successful outputs for failed steps.
- Never silently discard partial results without recording them.
- If [HUMAN_APPROVAL_GATES] are configured, pause and request approval before executing [IRREVERSIBLE_ACTIONS].
- Respect [TOOL_CALL_BUDGET] and stop if exceeded.
- Apply [OUTPUT_VALIDATION_RULES] to each step's output before passing it to the next step.

## CONTEXT
[WORKFLOW_CONTEXT]

## INPUT
[USER_INPUT_OR_TRIGGER_EVENT]

To adapt this template, replace the square-bracket placeholders with your specific workflow configuration. [TOOL_SEQUENCE] should contain the ordered list of tool calls with their input mappings. [COMMIT_THRESHOLD] defines what percentage of steps must succeed to consider the workflow partially successful—set this based on your business tolerance for incomplete results. [ABORT_CONDITIONS] should enumerate specific failure patterns that require immediate termination, such as authentication failures, data corruption detected, or critical dependency chain breaks. [DATA_INTEGRITY_RULES] must specify the invariants that cannot be violated, such as "order total must match line item sum" or "user identity must be consistent across all steps." [HUMAN_APPROVAL_GATES] should list which actions require human review before execution, particularly for write operations, financial transactions, or data deletion. Before deploying, test this prompt against scenarios where the first step fails, a middle step fails, the last step fails, and multiple non-adjacent steps fail—each should produce a different but correct output structure with appropriate rollback or partial-success decisions.

This prompt is designed to sit between tool execution and the agent's next planning step. After a multi-step tool chain completes—or halts mid-sequence—you feed the raw results, error payloads, and the original plan into this prompt. Its job is to produce a structured partial success report that downstream code can act on without ambiguity. The prompt does not execute tools or make commit decisions; it classifies outcomes, preserves successful work, and recommends next actions. Your orchestration harness must enforce those recommendations through explicit control flow, not by trusting the model to self-limit.

Wire the prompt into your agent loop as a post-execution analysis step. After each tool sequence completes, capture three inputs: the original execution plan with per-step success criteria, the ordered list of tool call results including status codes and error bodies, and any intermediate state artifacts produced by successful steps. Feed these into the prompt template using the [EXECUTION_PLAN], [TOOL_RESULTS], and [INTERMEDIATE_STATE] placeholders. Parse the output against a strict schema that includes completion_status (enum: full_success, partial_success, full_failure), preserved_results (array of step outputs to keep), failed_steps (array with error classification and retry eligibility), compensation_required (boolean), and recommended_action (enum: commit_partial, rollback_all, retry_failed, escalate). Validate that every step in the input plan appears in either preserved_results or failed_steps—missing steps indicate a hallucinated or truncated analysis. Log mismatches as critical errors and escalate to a human operator rather than silently proceeding with incomplete state.

The highest-risk failure mode is the model recommending commit_partial when the system of record cannot accept incomplete transactions. Your harness must enforce a policy layer above the prompt's recommendation. Maintain a registry of tool chains marked as atomic—where partial commit is forbidden regardless of the model's output. For atomic chains, override any commit_partial recommendation to rollback_all and trigger compensating actions using the saga pattern. For non-atomic chains, gate commit_partial on a human approval step if the preserved results include writes to production databases, customer-facing state, or financial records. Log every override decision with the model's original recommendation, the policy rule applied, and the operator's approval status. This audit trail is essential for debugging production incidents where the model's partial success analysis was correct but the business rules required a different outcome. Test this harness with injected failures at every step position—first step, middle step, last step—and verify that the combined prompt-plus-policy system produces the expected commit, rollback, or escalation behavior without data inconsistency.