Human-in-the-Loop Handoff Structuring Prompt for Delegated Tasks

This prompt is for product teams and AI platform engineers who need to package a sub-task's output for human review when an automated agent's confidence falls below a defined threshold. The job-to-be-done is converting a messy, partial, or low-confidence agent result into a structured review request that a human operator can quickly understand, decide on, and act upon without reading raw agent logs or replaying the entire task context. The ideal user is an orchestration engineer or product manager embedding a human approval checkpoint into an otherwise autonomous multi-agent workflow.

Use this prompt when your system has already determined that an agent's output requires human judgment—typically because a confidence score is below a calibrated threshold, the task touches a high-risk domain, or a policy rule mandates human approval. The prompt requires the original task description, the agent's output, a structured confidence breakdown, and the specific decisions the human must make. Do not use this prompt for real-time, low-latency user-facing chat where a human review step would break the interaction model. It is designed for asynchronous review queues, internal operations tools, and compliance workflows where a reviewer picks up a task from a queue, reviews the packaged evidence, and provides a structured approval, rejection, or modification.

Before implementing this prompt, ensure you have a well-defined confidence scoring mechanism and a clear policy for when human review is triggered. The prompt is not a substitute for good agent evaluation—it assumes the decision to escalate has already been made. The output should feed directly into a review UI or ticket system, so design the output schema to match your downstream tooling. Avoid using this prompt for tasks where the human reviewer would need to redo the agent's work from scratch; if the agent's output is too incomplete to serve as a useful starting point, the system should retry, re-decompose, or fail gracefully rather than waste a reviewer's time.

This prompt template is designed to be called by an orchestrator agent immediately after a sub-task completes with a confidence score below the acceptable threshold. Its job is not to re-execute the task, but to package the existing agent output, the original task context, and the specific points of uncertainty into a structured review request. The goal is to minimize the cognitive load on the human reviewer, allowing them to make a fast, informed decision without needing to replay the entire agent trace. The output of this prompt should be a machine-readable payload that can be routed to a review queue, rendered in a UI, and tracked for decision-time analytics.

codeCopy
You are a handoff structuring agent. Your task is to prepare a sub-task result for human review. You do not re-execute the task. You package the existing output, highlight uncertainty, and define the exact decisions the reviewer must make.

## INPUT
- Original Task: [ORIGINAL_TASK_DESCRIPTION]
- Agent Role: [AGENT_ROLE_AND_CAPABILITIES]
- Agent Output: [AGENT_OUTPUT_PAYLOAD]
- Confidence Breakdown: [CONFIDENCE_SCORES_PER_FIELD_OR_SECTION]
- Failure Flags: [LIST_OF_VALIDATION_FAILURES_OR_RISK_FLAGS]
- Source Evidence: [RELEVANT_SOURCE_SNIPPETS_OR_REFERENCES]

## CONSTRAINTS
- Do not alter, improve, or re-execute the agent's output. Package it as-is.
- Highlight specific fields, claims, or decisions where confidence is below [CONFIDENCE_THRESHOLD].
- If the agent output contains contradictory statements, flag them for the reviewer.
- Do not make a recommendation. Present the options and evidence neutrally.
- The review request must be self-contained. The reviewer should not need to read the original conversation.

## OUTPUT SCHEMA
Return a single JSON object with the following structure:
{
  "review_id": "string, unique identifier for this review request",
  "summary_for_reviewer": "string, a 2-3 sentence plain-language summary of what the agent was asked to do and what it produced",
  "original_task": "string, the original task description verbatim",
  "agent_output": { },
  "review_items": [
    {
      "item_id": "string",
      "field_or_claim": "string, the specific output field or claim under review",
      "agent_value": "string, the value the agent produced",
      "confidence": "number between 0 and 1",
      "failure_reason": "string, why confidence is below threshold or validation failed",
      "relevant_evidence": "string, source evidence the reviewer should check",
      "decision_required": "string, a clear question the reviewer must answer (e.g., 'Is this extracted date correct?', 'Should this claim be included?')",
      "decision_options": ["string", "string"]
    }
  ],
  "approval_actions": [
    {
      "action_id": "string",
      "action_label": "string, e.g., 'Approve All', 'Reject Item 3', 'Override with Value'",
      "action_type": "approve | reject | override | escalate",
      "target_item_ids": ["string"]
    }
  ],
  "review_metadata": {
    "priority": "low | medium | high | critical",
    "sla_minutes": "number, suggested time-to-decision",
    "escalation_contact": "string, who to escalate to if the reviewer cannot decide"
  }
}

To adapt this template for your system, start by replacing the [CONFIDENCE_THRESHOLD] placeholder with your organization's specific numeric threshold, typically between 0.7 and 0.9 depending on risk tolerance. The [ORIGINAL_TASK_DESCRIPTION] and [AGENT_OUTPUT_PAYLOAD] should be injected directly from your orchestrator's execution context. For the [CONFIDENCE_SCORES_PER_FIELD_OR_SECTION] placeholder, provide a structured breakdown—ideally a JSON object mapping each output field to its confidence score—rather than a single aggregate number. This granularity is what allows the prompt to generate specific, actionable review_items instead of a vague request to "check everything." If your agent system does not natively produce per-field confidence scores, you should run a separate evaluation pass before invoking this handoff prompt. The [LIST_OF_VALIDATION_FAILURES_OR_RISK_FLAGS] should include specific validator error messages, not just pass/fail booleans. Before deploying, test this prompt with at least five handoff scenarios where you know the ground truth, and measure whether the generated review_items correctly identify all fields that require human attention without flooding the reviewer with false positives.

This prompt is not a standalone chat interaction—it is a structured handoff contract that sits between an automated agent and a human review queue. The implementation harness must treat the prompt output as a machine-readable payload that triggers downstream actions: routing to the correct reviewer, rendering a review interface, capturing decisions, and logging the outcome. The prompt template expects [AGENT_OUTPUT], [CONFIDENCE_BREAKDOWN], [ORIGINAL_TASK], and [RISK_LEVEL] as inputs, and it produces a structured review request with specific decision points and approval actions. Your application code is responsible for supplying those inputs from the agent's execution context and for consuming the structured output to drive the review workflow.

Validation and retry logic is critical because a malformed handoff request can strand a task in an unreviewable state. After the model returns a response, validate that the output contains all required fields: review_summary, decisions_required (as a non-empty array), confidence_breakdown, approval_actions, and reviewer_instructions. Each decision in decisions_required must include decision_id, question, options, and agent_recommendation. If validation fails, retry once with the validation errors appended to the prompt as additional [CONSTRAINTS]. If the second attempt also fails, escalate to a fallback queue with the raw agent output and a flag indicating the handoff structuring failure. Log every validation attempt and its outcome for later prompt debugging.

Routing and review interface integration depends on the risk_level and confidence_breakdown fields in the structured output. Use risk_level to determine review SLA: high routes to an immediate review queue with paging, medium goes to the standard queue, and low can be batched. The decisions_required array should be rendered as a form where the human reviewer selects from the provided options for each decision. The approval_actions field should be rendered as buttons (Approve, Reject, Request Rework) that map to API calls updating the task state. Decision-time tracking is a stated requirement of this prompt: instrument your review interface to record the time between when the review request is presented and when each decision is submitted. Store this alongside the reviewer_id and decision_id for later analysis of review bottlenecks.

Model choice and context considerations: This prompt benefits from models with strong instruction-following and structured output capabilities. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are all suitable. Avoid smaller or older models that may drop required fields or hallucinate decision options. The prompt is designed to be stateless—each call is independent—so caching is not applicable. However, if you are processing high volumes of handoffs, consider batching multiple handoff structuring requests in a single API call where the model's context window permits, using a clear separator between requests. Human review is mandatory for all outputs of this prompt; the prompt structures the review request but does not make the decision. Never auto-approve based on agent confidence alone.

What to avoid: Do not use this prompt to bypass human review by setting artificially high confidence thresholds in the upstream agent. Do not skip validation of the structured output before presenting it to a reviewer—an unvalidated handoff can misrepresent the agent's uncertainty or omit critical decisions. Do not log the full prompt and response without redacting any PII that may have entered through the [ORIGINAL_TASK] or [AGENT_OUTPUT] fields. Finally, treat the approval_actions as auditable events: every approval, rejection, or rework request should be written to an immutable log with the reviewer's identity, timestamp, and the full handoff payload for governance and incident review.