Graceful Degradation Prompt for Partial Results

This prompt is designed for multi-step AI workflows where independent subtasks can succeed or fail without invalidating the entire run. The core job-to-be-done is to produce a structured partial-result response that clearly separates completed work from failed steps and provides explicit remediation paths. Ideal users are platform engineers and AI product teams building data extraction pipelines from multiple sources, batch processing jobs, or multi-tool agent runs. The required context includes a list of subtasks with their statuses, any partial outputs generated, and the specific errors encountered. The prompt's value is in preventing silent data loss and enabling downstream systems or users to act on what succeeded immediately, rather than blocking on a full retry.

Do not use this prompt for single-step tasks where the concept of partial success is meaningless. If your workflow requires atomic all-or-nothing completion with rollback semantics—such as a database transaction or a compliance filing—this pattern is inappropriate and could create an inconsistent state. Similarly, avoid this prompt when the subtasks are tightly coupled and the failure of one step makes the output of successful steps unusable. In those cases, a simple failure response with a full retry mechanism is safer and less confusing for the end user.

Before implementing, map your workflow's dependency graph. Identify which steps are truly independent and can be reported separately. For each step, define a clear success criterion and a structured error object that includes an error code, a human-readable message, and a suggested remediation. This preparation ensures the prompt template's placeholders for [COMPLETED_STEPS], [FAILED_STEPS], and [REMEDIATION_PATHS] are populated with actionable data, not just raw logs. The next section provides the copy-ready template you will wire into your application's error-handling layer.

This template is designed to be pasted directly into your system prompt or task-level instruction block. It forces the model to compartmentalize a multi-step workflow into discrete outcomes, preventing the common failure mode where a single error causes the entire response to be discarded or, worse, where the model silently omits failed steps. Replace every square-bracket placeholder with values specific to your application's workflow, output schema, and risk tolerance before deployment.

textCopy
You are an assistant that executes multi-step workflows and reports results with strict separation of completed and failed steps. You must never silently drop a failed step or fabricate a success.

## WORKFLOW STEPS
[STEP_DEFINITIONS]

## OUTPUT SCHEMA
Return a single JSON object with this exact structure:
{
  "overall_status": "partial_success" | "complete_success" | "complete_failure",
  "completed_steps": [
    {
      "step_id": "string",
      "step_name": "string",
      "result": "object | string",
      "evidence": "string (optional, cite sources or data used)"
    }
  ],
  "failed_steps": [
    {
      "step_id": "string",
      "step_name": "string",
      "failure_reason": "string (specific, actionable, no speculation)",
      "partial_output": "object | string | null (any usable intermediate result)",
      "remediation": "string (concrete next step the user or system can take)"
    }
  ],
  "unattempted_steps": [
    {
      "step_id": "string",
      "step_name": "string",
      "reason_skipped": "string (e.g., dependency failed, blocked by policy)"
    }
  ],
  "summary": "string (one-sentence overall status for logging and user display)"
}

## CONSTRAINTS
- If a step fails, you MUST include it in `failed_steps`. Never move a failed step into `completed_steps`.
- If a step cannot be attempted because a dependency failed, list it in `unattempted_steps` with the blocking step referenced.
- `failure_reason` must describe what went wrong, not why you think it went wrong. Do not guess root causes.
- `remediation` must be a single, actionable instruction. Do not list multiple options unless they are ordered by likelihood of success.
- If all steps succeed, `failed_steps` and `unattempted_steps` must be empty arrays.
- If all steps fail, `completed_steps` must be an empty array.
- Do not include a step in both `completed_steps` and `failed_steps`.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## TOOLS
[AVAILABLE_TOOLS]

## RISK LEVEL
[RISK_LEVEL: low | medium | high | critical]

## ESCALATION RULES
[ESCALATION_RULES]

To adapt this template, start by replacing [STEP_DEFINITIONS] with a numbered or bulleted list of the discrete steps your workflow performs. Each step must have a stable step_id that your application code can map to a known operation. Next, populate [FEW_SHOT_EXAMPLES] with at least two examples: one showing a partial success with a clear failure reason, and one showing a complete success. If your workflow uses tools, define them in [AVAILABLE_TOOLS] using the exact function signatures your model expects. Set [RISK_LEVEL] to high or critical for workflows where a missed failure could cause downstream data corruption, financial impact, or safety issues—this should trigger additional validation in your harness. Finally, define [ESCALATION_RULES] to specify when the system should stop retrying and request human review, such as when a failed_step has a failure_reason matching a known unrecoverable error pattern.

Before shipping, validate that your application harness can parse this exact JSON structure and that your eval suite checks for the three silent-failure modes this prompt is designed to prevent: a failed step appearing in completed_steps, a failed step being omitted entirely, and an unattempted step being reported as failed rather than skipped. Run adversarial test cases where every step fails, where a middle step fails, and where the input is malformed, and confirm the output schema holds. If your risk level is high or critical, add a human-review gate that surfaces any response where overall_status is not complete_success and the failed_steps array is non-empty.

This prompt is designed to be called after a multi-step workflow has partially failed. It should not be the primary orchestrator of the workflow itself. Instead, your application code should execute the steps, collect their individual success/failure states and outputs, and then pass that structured summary into this prompt as the [PARTIAL_RESULTS] input. The prompt's job is to format a user-facing message that honestly separates completed work from failed steps and provides clear remediation paths. It is a presentation-layer prompt, not an execution-layer prompt.

To wire this in, build a post-execution handler that constructs the [PARTIAL_RESULTS] object. This object must be a structured list of steps, each containing a step_id, step_name, status (one of completed, failed, or timed_out), output_summary (for completed steps), and error_summary (for failed steps). Your application should never pass raw stack traces to the model; sanitize errors into user-readable summaries first. After the prompt returns, validate the output against a defined [OUTPUT_SCHEMA] that requires a completed_work array, a failed_work array, and a remediation_suggestions array. If validation fails, retry once with a repair prompt that includes the schema violation error. Log every instance of this prompt being triggered, including the input state and the final validated output, to monitor the frequency and types of partial failures in your system.

For high-stakes workflows where partial results could mislead users, insert a human review step before the final message is sent. Route outputs where the number of failed steps exceeds a threshold, or where a critical step has failed, to a review queue. Do not rely solely on this prompt to decide what constitutes a critical failure; that logic belongs in your application's orchestration layer. The model choice here favors models with strong instruction-following and formatting reliability, such as GPT-4o or Claude 3.5 Sonnet. Avoid using smaller, less reliable models for this task, as schema conformance and honest failure disclosure are paramount. The primary failure mode in production is the model omitting a failed step from the failed_work array, effectively hiding the error. Your eval harness must explicitly check that every step with a failed or timed_out status in the input appears in the output's failed_work array.