Partial Failure Status Update Prompt

This prompt is for agent operators and workflow monitors who need a structured, machine-readable status when a multi-step plan completes with a mix of successes and failures. The job-to-be-done is clear: produce a single artifact that separates completed work from failed steps, inventories partial results that can be salvaged, and recommends a concrete next action—resume, rollback, escalate, or abandon. Without this prompt, partial failures often produce ambiguous logs or verbose traces that force an operator to manually reconstruct what happened, which is slow and error-prone in production systems where minutes matter.

Use this prompt when your agent runtime has finished executing a plan (or hit a terminal error state) and at least one step succeeded while at least one step failed or was skipped due to upstream dependency failure. The prompt expects a structured execution trace as input, including step IDs, statuses, outputs, error messages, and dependency relationships. It is designed for supervised autonomy workflows where a human operator or an upstream orchestrator needs a concise, actionable summary before deciding whether to resume execution, roll back side effects, or escalate. Do not use this prompt for fully successful runs (use a Task Completion Summary instead) or for runs where every step failed identically (use a Retry Exhausted Escalation or Goal Abandonment prompt). It is also not appropriate for real-time streaming updates during execution—this is a post-execution analysis prompt.

The prompt produces a structured output with four required sections: a completion summary table mapping each step to a status (completed, failed, skipped), an artifact inventory listing preserved outputs from completed steps with their locations or identifiers, a failure analysis grouping failed steps by root cause and recoverability, and a recommended action with rationale. The recommendation must be one of four enumerated values: RESUME, ROLLBACK, ESCALATE, or ABANDON. This constrained output shape lets you wire the prompt into automated decision pipelines—for example, a RESUME recommendation can trigger an automatic replanning step, while ESCALATE can create a ticket in your incident management system with the full failure payload attached.

Before deploying this prompt, define your evaluation criteria. At minimum, test that the output correctly classifies every step from the input trace (no dropped or hallucinated steps), that the artifact inventory includes only outputs from genuinely completed steps, and that the recommended action is consistent with your operational policies. Common failure modes include the model recommending RESUME when a failed step has irreversible side effects, omitting artifacts from steps that succeeded but whose outputs were overwritten by later failures, and producing an artifact inventory that references internal memory addresses or ephemeral paths that are not accessible to the operator. Run this prompt against a golden dataset of known partial-failure traces and measure step-classification accuracy, artifact recall, and recommendation alignment before production use.

This prompt template produces a structured status update when a multi-step workflow has completed some steps successfully while others have failed. It forces the model to distinguish completed work from failed steps, preserve partial results, inventory artifacts from successful steps, and recommend a concrete recovery path—resume, rollback, or escalate. Use this when your agent orchestrator or workflow engine needs to communicate partial progress to operators, downstream systems, or replanning modules without losing the value of completed work.

textCopy
You are a workflow status reporter. Your task is to produce a structured partial failure status update from the execution trace provided.

## INPUT
[EXECUTION_TRACE]

## CONSTRAINTS
- Distinguish clearly between completed steps, failed steps, and steps not yet attempted.
- For each failed step, include: step identifier, error type, error message, retry count, and whether the failure blocks downstream steps.
- For each completed step, include: step identifier, completion timestamp, a one-line summary of output, and any artifacts produced with their locations or identifiers.
- Preserve all partial results. Do not discard outputs from completed steps.
- Classify the overall status as one of: resumable, requires_rollback, requires_escalation, or abandoned.
- If resumable, specify which step to resume from and any preconditions that must be re-validated.
- If rollback is recommended, specify which steps must be undone and in what order.
- If escalation is recommended, provide a structured handoff summary for a human operator.
- Flag any silent failure risks: steps that appear successful but produced empty results, schema-compliant garbage, or outputs outside expected ranges.
- Do not invent outcomes for steps that did not execute.
- If [RISK_LEVEL] is high or critical, include an explicit statement that human review is required before any recovery action.

## OUTPUT SCHEMA
Return valid JSON matching this structure:
{
  "workflow_id": "string",
  "status": "resumable | requires_rollback | requires_escalation | abandoned",
  "summary": "string (one-paragraph operator summary)",
  "completed_steps": [
    {
      "step_id": "string",
      "completed_at": "ISO8601 timestamp",
      "summary": "string",
      "artifacts": [{"type": "string", "location": "string", "description": "string"}]
    }
  ],
  "failed_steps": [
    {
      "step_id": "string",
      "error_type": "string",
      "error_message": "string",
      "retry_count": "integer",
      "blocks_downstream": "boolean",
      "blocked_step_ids": ["string"]
    }
  ],
  "unattempted_steps": ["string"],
  "silent_failure_flags": [
    {"step_id": "string", "concern": "string", "evidence": "string"}
  ],
  "recovery_recommendation": {
    "action": "resume | rollback | escalate | abandon",
    "resume_from_step_id": "string | null",
    "preconditions_to_revalidate": ["string"],
    "rollback_steps": ["string"],
    "escalation_handoff": "string | null",
    "requires_human_review": "boolean"
  },
  "artifact_inventory": [
    {"step_id": "string", "artifact_type": "string", "location": "string", "preserved": "boolean"}
  ]
}

## RISK_LEVEL
[RISK_LEVEL]

Adapt this template by adjusting the output schema to match your workflow engine's state model. If your system uses a different set of terminal statuses—such as blocked, degraded, or awaiting_approval—replace the enum values in the status field and recovery_recommendation.action field. The silent_failure_flags array is critical for production systems where valid JSON does not mean correct results; pair this output with a validator that checks artifact locations are reachable and step summaries are non-empty. For regulated workflows, set [RISK_LEVEL] to high and ensure the requires_human_review flag gates any automated recovery action. Before deploying, run eval cases with mixed success and failure traces to confirm the model correctly distinguishes resumable from requires_rollback and does not silently drop completed artifacts.

The Partial Failure Status Update Prompt is designed to be called by an agent orchestrator or monitoring service immediately after a step or sub-plan returns a non-success status. It is not a continuous monitoring prompt; it is a point-in-time diagnostic that consumes the plan definition, the execution trace for the failed scope, and any partial artifacts produced. The prompt's primary job is to produce a structured status object that distinguishes completed work from failed steps, preserves partial results, and recommends a recovery action. This structured output should be consumed programmatically by the orchestrator to decide whether to resume, rollback, or escalate.

To integrate this prompt, the calling system must assemble three input blocks: the original plan with step IDs and expected outputs, the execution log showing which steps succeeded and which failed with error details, and an artifact inventory mapping completed steps to their output locations or payloads. The prompt template uses the placeholders [PLAN_DEFINITION], [EXECUTION_LOG], and [ARTIFACT_INVENTORY]. The orchestrator should inject these as structured JSON or formatted text blocks. The model response must conform to a strict [OUTPUT_SCHEMA] that includes completed_steps, failed_steps, partial_results_preserved, recovery_recommendation (enum: resume, rollback, escalate), and escalation_reasoning. Implement a post-generation validation layer that checks for schema compliance, valid enum values, and cross-referencing between completed_steps and failed_steps to ensure no step appears in both lists. If validation fails, retry once with the validation error injected into [CONSTRAINTS]. Log every invocation, including the input plan version, the raw model output, and the validation result, for audit and debugging.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid smaller or older models that may collapse the recovery recommendation into a generic 'escalate' or fail to preserve partial results accurately. Set temperature to 0 or a very low value (0.1) to maximize deterministic, schema-compliant output. The prompt should run with a timeout appropriate for the size of the execution log; if the log is large, consider summarizing or truncating it before injection, but always preserve error messages and step IDs. For high-risk workflows where the recovery recommendation triggers irreversible actions (e.g., database rollback, customer-facing notification), route the output to a human review queue before execution. The escalation_reasoning field is designed to be displayed directly in that review interface. Do not use this prompt for real-time streaming status; it is a batch diagnostic meant for transition points between execution phases.