Human Approval Request Prompt with Blocking Conditions

This prompt is designed for platform engineers who need to insert a human approval gate before an AI agent executes a high-risk action. It forces the model to produce a structured, machine-readable approval request that clearly defines what action is proposed, what conditions block automatic execution, and what irreversible consequences are at stake. Use this when your agent workflow reaches a step that requires explicit human sign-off before proceeding, such as deleting production data, making a financial commitment, or changing a security policy. The output is designed to be consumed by an approval queue system, not just read by a human in a chat window.

The ideal user is an engineering lead or platform engineer building agentic workflows where the cost of an incorrect autonomous action is high. You need this prompt when your system cannot programmatically determine safety—for example, when the action involves a novel configuration change, a spend above a dynamic threshold, or a user request that falls outside predefined policy boundaries. The prompt requires you to supply the proposed action details, the agent's reasoning, the relevant policy or context, and the risk level. It then generates a blocking approval request that downstream systems can parse, route, and log. Do not use this prompt for low-risk, reversible, or pre-authorized actions where a human gate adds latency without reducing material risk.

Before using this prompt, ensure your application layer can handle the structured output: parse the JSON, route the approval request to the correct human or team, enforce a timeout, and act on the approval or rejection signal. The prompt itself does not implement the gate—it produces the request payload. You must build the queue, the notification, and the timeout logic. Also, avoid using this prompt in real-time user-facing chat where a blocking request would freeze the conversation; instead, design an asynchronous handoff. The next section provides the copy-ready template you can adapt to your specific risk taxonomy and output schema.

This prompt template is designed to be placed directly into your agent's system prompt or used as a step instruction before any high-risk action. It forces the model to pause, assess the proposed action against a set of defined blocking conditions, and package a complete request for a human reviewer. The output is a structured object, not a conversational message, making it suitable for programmatic parsing by an orchestration layer that will halt execution until a signed approval is received.

textCopy
You are an approval gate agent. Your sole task is to evaluate a proposed action and generate a structured approval request for a human reviewer. You do not execute the action. You do not decide if the action is safe. You only prepare the review packet.

## Inputs
- [PROPOSED_ACTION]: A description of the action the system wants to take.
- [ACTION_CONTEXT]: The surrounding context, including user request, relevant data, and system state.
- [BLOCKING_CONDITIONS]: A list of conditions that, if met, must be explicitly acknowledged by the human reviewer. Example: 'Action modifies production data', 'Action incurs a cost > $100'.
- [IRREVERSIBLE_FLAGS]: A list of flags indicating if the action is permanent, destructive, or has a wide blast radius. Example: 'Deletes data permanently', 'Sends email to all users'.
- [REQUIRED_APPROVAL_ROLES]: A list of roles or individuals who must approve this action.

## Task
1. Analyze [PROPOSED_ACTION] against [BLOCKING_CONDITIONS] and [IRREVERSIBLE_FLAGS].
2. Generate a JSON object conforming to the [OUTPUT_SCHEMA] below.
3. In the `summary_for_reviewer` field, write a concise, neutral description of the action, its context, and its implications. Do not advocate for or against the action.
4. In the `blocking_conditions_triggered` field, list only the conditions from [BLOCKING_CONDITIONS] that apply to this action. For each, include a one-sentence explanation of why it is triggered.
5. In the `irreversible_consequences` field, list the flags from [IRREVERSIBLE_FLAGS] that apply.
6. If no blocking conditions are triggered, set `approval_required` to `false` and provide an empty list for `blocking_conditions_triggered`. The action will still be logged.

## Output Schema
```json
{
  "approval_required": boolean,
  "action_id": "string, a unique identifier for this request",
  "summary_for_reviewer": "string, a plain-language summary of the proposed action and its context",
  "action_scope": {
    "target_system": "string, the system or service affected",
    "target_resource": "string, the specific resource, table, or endpoint",
    "estimated_impact": "string, a qualitative description of the blast radius"
  },
  "blocking_conditions_triggered": [
    {
      "condition": "string, the exact condition from [BLOCKING_CONDITIONS]",
      "reason": "string, a one-sentence explanation of why it applies"
    }
  ],
  "irreversible_consequences": ["string, from [IRREVERSIBLE_FLAGS]"],
  "required_approvers": ["string, from [REQUIRED_APPROVAL_ROLES]"],
  "timestamp": "string, ISO 8601 format"
}

Constraints

• Do not execute the action.
• Do not add warnings or recommendations beyond the structured fields.
• If the action is unclear, set approval_required to true and note the ambiguity in the summary.
• Output only the JSON object. No markdown fences, no surrounding text.

To adapt this template, replace the square-bracket placeholders with values injected by your application logic. The [BLOCKING_CONDITIONS] and [IRREVERSIBLE_FLAGS] should be defined as configuration, not hardcoded in the prompt, allowing operations teams to update policy without changing code. The [OUTPUT_SCHEMA] is included inline for clarity, but in production you should enforce the schema in your application layer using a JSON Schema validator after the model responds. If the output fails validation, retry once with the validation error included as additional context; if it fails again, escalate the raw output to a human operator for manual triage.

The Human Approval Request Prompt is not a standalone artifact; it is a gate in a larger agent workflow. The application layer must call this prompt before executing any action flagged as high-risk, irreversible, or regulated. The prompt's output should be treated as a structured approval request object, not free text. The calling system must parse the output, validate its schema, and then enforce a blocking wait state until a human reviewer provides an explicit decision. Do not proceed on timeout, default, or null.

Wire the prompt into a pre-action hook. Before the agent calls a tool like DELETE_RECORD, PROCESS_REFUND, or UPDATE_CONFIG, the orchestrator should invoke this prompt with the proposed action, its scope, and the relevant context. The prompt returns a JSON object containing approval_required (boolean), blocking_conditions (list of strings), action_scope (object), and irreversible_consequences (list of strings). The application must validate this JSON against a strict schema. If approval_required is true, the system must serialize the entire object into a human-readable ticket, push it to a review queue, and block the parent workflow. Implement a retry loop for malformed JSON: if the output fails schema validation, re-prompt the model once with the validation error included. If it fails again, escalate to an on-call engineer with the raw output attached.

Model choice matters. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o or Claude 3.5 Sonnet, with response_format set to json_object and the JSON Schema provided directly in the API call. For high-compliance environments, log the full prompt, the raw model response, and the validated output to an append-only audit store before any approval request is surfaced to a reviewer. Never allow the model to execute the action itself. The prompt's job is to produce the request; the human's job is to decide. The system's job is to enforce the gap between them.