Irreversible Action Approval Request Prompt

This prompt is for product engineers building agent systems that must pause before executing a destructive or irreversible action. Its job is not to make the approval decision, but to structure the available context—proposed action, consequences, alternatives, and rollback feasibility—into a concise, human-readable approval request. The ideal user is an engineering lead or developer integrating a human-in-the-loop checkpoint into an automated workflow where a wrong action cannot be easily undone, such as deleting a production database, sending a mass customer communication, or merging a pull request that bypasses CI checks.

Use this prompt when the agent has already gathered the necessary context about the action's scope, downstream impact, and available alternatives. The prompt assumes the agent has access to tool outputs, system state, or a knowledge base that provides this information. It is designed for high-stakes, low-frequency decisions where the cost of a bad automated action far exceeds the cost of a brief human review. The output is a structured summary, not a binary approve/reject signal, ensuring the human reviewer can make a fast, informed decision without re-investigating the entire context.

Do not use this prompt for low-risk, reversible operations where the overhead of human review outweighs the risk, such as updating a non-critical cache or drafting an internal document. It is also unsuitable for real-time, high-throughput systems where human latency is unacceptable; in those cases, invest in rigorous automated guardrails, canary deployments, or staged rollouts instead. Finally, this prompt does not replace the need for a secure approval mechanism (e.g., a review queue, audit log, or two-person control system); it only prepares the information payload that feeds into that mechanism.

This template is designed to be the final gate in an agent's execution loop before it performs an action that cannot be easily undone, such as deleting a resource, sending a high-stakes communication, or modifying a production configuration. It forces the agent to summarize the proposed action, its consequences, and the alternatives considered, presenting a clear, structured payload for a human reviewer. The prompt is not a decision-maker; it is a summarizer that ensures all critical context is surfaced for a human to make the final call.

textCopy
You are an approval gate for an autonomous agent. Your task is to generate a structured, human-readable summary of a proposed irreversible action. You do not approve or deny the action. You must present the facts, risks, and context clearly so a human operator can make the decision.

# PROPOSED ACTION
[ACTION_DESCRIPTION]

# EXECUTION CONTEXT
- **Triggering Event:** [TRIGGER_EVENT]
- **Agent's Goal:** [AGENT_GOAL]
- **Relevant History:** [RELEVANT_HISTORY]

# CONSTRAINTS
- Summarize the action in plain, non-technical language for a human reviewer.
- Explicitly state the consequences of both executing and not executing the action.
- List at least one alternative action that was considered and why it was rejected.
- Assess the feasibility of rolling back or undoing this action.
- Classify the urgency as one of: [Low, Medium, High, Critical] and justify the classification.
- If the action involves a financial cost, data loss, or a security change, highlight this in a dedicated **Risk Warning** section.
- Do not ask the human for more information. The summary must be self-contained.

# OUTPUT FORMAT
You must respond with a JSON object matching this exact schema:
{
  "approval_request_id": "string",
  "urgency": "Low | Medium | High | Critical",
  "urgency_justification": "string",
  "action_summary": "string",
  "consequences_of_action": "string",
  "consequences_of_inaction": "string",
  "alternatives_considered": [
    {
      "alternative": "string",
      "rejection_reason": "string"
    }
  ],
  "rollback_feasibility": "string",
  "risk_warnings": ["string"],
  "proposed_timestamp": "string"
}

To adapt this template for your system, replace the square-bracket placeholders with live data from your agent's execution context. The [ACTION_DESCRIPTION] should be a precise technical summary of the function call and its arguments. The [RELEVANT_HISTORY] should include the key observations and previous steps that led to this decision. For high-risk domains like infrastructure or finance, consider adding a [DRY_RUN_OUTPUT] placeholder to show the predicted result of the action before it is executed. Always validate the generated JSON against the schema before presenting it to a human reviewer; a malformed approval request is a silent failure that can delay critical interventions.

This prompt is not a standalone chatbot interaction—it is a safety-critical component inside an agent execution loop. It should be invoked immediately after the agent has selected a destructive or irreversible tool call (e.g., DELETE, DROP, PUBLISH, TRANSFER, DEACTIVATE) but before that tool is executed. The system must pause the agent's execution, populate the prompt's placeholders with the proposed action, its consequences, alternatives considered, and rollback feasibility, then route the completed approval request to a human review queue. The agent must not proceed until it receives an explicit APPROVED or REJECTED signal from the review system.

Wiring pattern: Implement this as a blocking middleware or a pre-execution hook in your agent framework. When the agent emits a tool call matching a configurable list of irreversible actions, intercept it. Populate the prompt template with structured data from the agent's planning state: the exact tool name and arguments in [PROPOSED_ACTION], a summary of downstream effects in [CONSEQUENCES], a list of alternatives the agent considered in [ALTERNATIVES_CONSIDERED], and a boolean or detailed description of rollback capability in [ROLLBACK_FEASIBILITY]. Set [RISK_LEVEL] based on your internal risk taxonomy (e.g., LOW, MEDIUM, HIGH, CRITICAL). Send the assembled prompt to your LLM to generate the human-readable approval request. Validation: Before displaying the request to a human, validate that the output contains all required sections (Action, Consequences, Alternatives, Rollback) and that the urgency framing in the subject line matches the [RISK_LEVEL]. If validation fails, retry once with a more explicit instruction; if it fails again, escalate the raw agent state to a human operator without the LLM-generated summary.

Model choice and logging: Use a fast, instruction-following model (e.g., GPT-4o, Claude 3.5 Sonnet) for this generation step—latency matters because a human is waiting. Log the full prompt, the generated approval request, the validator result, and the human's final decision immutably. This audit trail is non-negotiable for irreversible actions. What to avoid: Never allow the agent to self-approve. Never skip the prompt generation step and dump raw JSON to a reviewer—the prompt's job is to translate machine state into a decision-ready summary. If your system has a Service Level Objective (SLO) for human review response time, implement an escalation path: if no human responds within the SLO window, the default must be rejection, not approval. Finally, periodically run eval suites that test whether the generated approval requests correctly convey severity, omit no critical consequence, and avoid alarmist language that causes reviewer fatigue.