Post-Action Verification Failure Handoff Prompt

This prompt is designed for infrastructure engineers and SRE teams running automated remediation, deployment, or configuration workflows. When an AI agent executes an action and the post-action verification step fails, the system must not silently proceed or retry indefinitely. This prompt produces a structured handoff for a human operator containing the executed action, the expected versus actual outcome, the specific verification checks that failed, and clear rollback or resume instructions. Use this prompt when your automation pipeline includes a verification gate and that gate returns a non-passing result. Do not use this prompt for pre-action approval, general incident response, or conversational handoffs where no automated action was taken.

The ideal trigger is a deterministic failure from a verification script or monitoring check—not a model's self-assessment of its own work. For example, if an agent runs a database migration and the row-count validation check returns a mismatch, this prompt structures the handoff. If the agent restarts a service and the health check still returns 503 after the defined backoff window, this prompt captures the state. The handoff must include the exact command or API call executed, the expected post-condition, the actual observed state, and the specific assertion that failed. This prevents the operator from wasting time rediscovering what the system already knows.

Avoid using this prompt when the verification failure is transient and a defined retry strategy with exponential backoff is more appropriate. Also avoid it when the failure is expected and a compensating action is already defined in the runbook—in that case, the agent should execute the rollback or fallback directly rather than handing off. This prompt is for cases where automated recovery is exhausted or undefined, and human judgment is required to decide whether to roll back, proceed with caution, or investigate further. Wire this prompt into your workflow engine's error path, not the happy path.

This prompt template is designed to be injected into your automation system's failure-handling logic. When a post-action verification check fails, the system should populate the placeholders with runtime data and invoke the model to produce a complete, structured handoff. The output is intended to be consumed by a human operator who needs to understand exactly what was attempted, what went wrong, and how to safely resume or roll back the operation.

textCopy
You are an AI operations handoff assistant. An automated action was executed, but the subsequent verification step failed. Your job is to produce a structured handoff report for a human operator. Do not attempt to fix the problem. Do not re-execute the action. Your only output should be the handoff report.

## Action Context
- Action ID: [ACTION_ID]
- Action Description: [ACTION_DESCRIPTION]
- Executed Command / API Call: [EXECUTED_COMMAND]
- Execution Timestamp: [EXECUTION_TIMESTAMP]
- Target System / Resource: [TARGET_SYSTEM]
- Initiating Workflow: [INITIATING_WORKFLOW]

## Expected Outcome
[EXPECTED_OUTCOME]

## Actual Outcome
[ACTUAL_OUTCOME]

## Verification Details
- Verification Check Performed: [VERIFICATION_CHECK]
- Expected Verification Result: [EXPECTED_VERIFICATION_RESULT]
- Actual Verification Result: [ACTUAL_VERIFICATION_RESULT]
- Verification Failure Reason: [VERIFICATION_FAILURE_REASON]

## System State
- Partial Completion State: [PARTIAL_COMPLETION_STATE]
- Affected Resources: [AFFECTED_RESOURCES]
- Relevant Log Snippets: [LOG_SNIPPETS]

## Rollback Instructions
[ROLLBACK_INSTRUCTIONS]

## Resume Point for Operator
[RESUME_POINT]

## Output Schema
Generate a JSON object with the following structure:
{
  "handoff_type": "post_action_verification_failure",
  "action_id": "string",
  "severity": "critical|high|medium|low",
  "summary": "A concise, one-paragraph summary of the failure for a busy operator.",
  "action_context": {
    "description": "string",
    "executed_command": "string",
    "timestamp": "string",
    "target_system": "string"
  },
  "verification_gap": {
    "expected": "string",
    "actual": "string",
    "check_performed": "string",
    "failure_reason": "string"
  },
  "current_state": {
    "partial_completion": "string",
    "affected_resources": ["string"],
    "relevant_logs": ["string"]
  },
  "operator_instructions": {
    "immediate_actions": ["string"],
    "rollback_steps": ["string"],
    "resume_point": "string",
    "do_not_attempt": ["string"]
  },
  "risk_assessment": "string",
  "escalation_path": "string"
}

## Constraints
- If any input field is missing, set its value to "UNKNOWN" and note it in the summary.
- Classify severity as "critical" if the action involved data deletion, security changes, or financial transactions.
- The "do_not_attempt" field must list actions the operator should explicitly avoid.
- Do not fabricate details. Only use the provided input data.

To adapt this template, replace each [PLACEHOLDER] with data from your automation runtime. The [PARTIAL_COMPLETION_STATE] is critical—it tells the operator whether the action partially succeeded (e.g., a database record was created but a notification failed to send) or failed entirely. The [ROLLBACK_INSTRUCTIONS] should be pre-defined steps from your runbook, not generated by the model. For high-risk actions, ensure the output is logged to an immutable audit system before the operator acknowledges it. Always validate the generated JSON against the schema before presenting it to the operator; if validation fails, fall back to a simpler text-based handoff and alert the platform team.

This prompt is designed to be the final step in an automated action pipeline. It fires only when a post-action verification check fails—meaning the system executed an action (a deployment, a configuration change, a data mutation) but the subsequent health check, state assertion, or output validation did not return the expected result. The prompt's job is to package the full failure context into a structured handoff for a human operator. Do not call this prompt for successful verifications or for pre-action approval; those are separate workflows.

Wire the prompt into your pipeline by wrapping it in a dedicated failure-handling function. The function should receive the original action payload, the expected outcome definition, the actual observed state, and the results of any verification checks. Before calling the LLM, validate that all required inputs are present and non-null—an incomplete handoff is worse than no handoff. On the output side, parse the generated JSON handoff payload and validate it against a strict schema that requires fields like action_summary, verification_results, rollback_instructions, and resume_point. If parsing or schema validation fails, retry once with a stronger constraint instruction appended to the prompt. If the second attempt also fails, fall back to a pre-formatted template that includes the raw input data and a clear MANUAL_REVIEW_REQUIRED flag. Log every handoff attempt, including the full prompt, the model response, and the validation result, for post-incident review.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities, such as Claude 3.5 Sonnet or GPT-4o, and set the temperature low (0.0–0.2) to maximize factual consistency. This workflow is high-risk because it involves actions that have already been executed and may need rollback. The handoff payload must be ingested by your incident management or ticketing system. Map the severity field from the handoff to your internal P1–P4 scale, and use the recommended_next_steps array to pre-populate the operator's runbook view. Never allow the LLM to autonomously execute the rollback instructions it generates; those instructions are advisory for the human operator. The rollback_instructions field should be treated as a suggested procedure, not an automated script.