Human Approval Queue Status Prompt

This prompt is designed for human-in-the-loop system designers and agent operators who need to programmatically verify the health of a human approval queue before an agent submits work for review. The core job-to-be-done is a precondition check within the agent's planning phase: confirming that the queue is staffed, responsive, and not at risk of breaching service-level agreements (SLAs) before the agent commits to a blocking wait for human sign-off. The ideal user is an engineering lead or platform engineer embedding this check into an agent harness where the cost of submitting to a dead, overloaded, or unmonitored queue is high—such as in regulated financial transactions, clinical documentation workflows, or time-sensitive security incident responses.

To use this prompt effectively, you must provide it with structured, up-to-date telemetry from your actual ticketing or approval system. The prompt acts as a reasoning and summarization layer, not a source of truth. Required context includes: the target queue name, the number of pending items, the current on-call schedule, the defined SLA thresholds, and the estimated effort for the agent's own review request. The prompt interprets this data to produce a queue health report covering estimated wait time, on-call coverage, escalation path readiness, and SLA breach risk. It is a decision-support tool that answers the question: 'Is it safe to submit this for human review right now, or should the agent wait, escalate, or take an alternative path?'

Do not use this prompt as a substitute for direct queue telemetry or as a real-time monitoring dashboard. It cannot detect that an on-call engineer is present but unresponsive, and it will confidently produce a report even if the input data is stale or incomplete. The prompt's value is in interpreting the numbers you already have, not in fabricating them. For high-risk workflows, always pair this prompt's output with a programmatic check: if the underlying telemetry source is unreachable or the data is older than a defined freshness threshold, the agent should abort the precondition check and escalate to a human operator directly, rather than relying on a stale or hallucinated health report.

After reading this section, you should understand the precise operational gap this prompt fills. Next, review the Prompt Template section to copy and adapt the exact instructions, and then the Implementation Harness section to learn how to wire it into your agent's planning phase with validation, retries, and logging.

This prompt template is designed to be injected into your agent's pre-execution validation step, specifically before any action that requires human sign-off. It forces the model to assess the operational readiness of your approval infrastructure—queues, on-call schedules, escalation paths, and SLA status—rather than blindly submitting a review and hoping for a timely response. The output is a structured health report that your agent harness can parse to decide whether to proceed, wait, or escalate.

textCopy
You are an operational readiness validator for a human-in-the-loop agent system. Your task is to assess the current health of the human approval queue before the agent submits a review request.

## Input Data
- Queue Name: [QUEUE_NAME]
- Current Queue Depth: [QUEUE_DEPTH]
- Active Reviewers On-Call: [ACTIVE_REVIEWERS]
- Reviewer Availability Schedule (next 4 hours): [SCHEDULE_DATA]
- Pending Approvals Older Than SLA: [PENDING_SLA_BREACHES]
- Escalation Path: [ESCALATION_PATH]
- Current Time: [CURRENT_TIME]

## Output Schema
Return a valid JSON object with the following structure:
{
  "queue_status": "healthy" | "degraded" | "unavailable",
  "estimated_wait_minutes": <integer>,
  "on_call_coverage": "sufficient" | "insufficient" | "none",
  "escalation_ready": true | false,
  "sla_breach_risk": "none" | "low" | "medium" | "high" | "critical",
  "recommendation": "proceed" | "wait_and_retry" | "escalate" | "abort",
  "findings": [
    {
      "severity": "info" | "warning" | "critical",
      "message": "<string describing the finding>"
    }
  ]
}

## Evaluation Rules
1. If ACTIVE_REVIEWERS is 0, queue_status is "unavailable" and recommendation is "escalate".
2. If QUEUE_DEPTH > 10 and ACTIVE_REVIEWERS < 2, queue_status is "degraded" and sla_breach_risk is at least "medium".
3. If PENDING_SLA_BREACHES > 0, sla_breach_risk is at least "high" and recommendation cannot be "proceed".
4. If ESCALATION_PATH is empty or "none", escalation_ready is false.
5. estimated_wait_minutes should be calculated as (QUEUE_DEPTH / ACTIVE_REVIEWERS) * [AVERAGE_REVIEW_TIME_MINUTES], defaulting to 15 if AVERAGE_REVIEW_TIME_MINUTES is not provided.
6. If the current time falls outside the SCHEDULE_DATA coverage window, on_call_coverage is "insufficient" or "none".

## Constraints
- Do not fabricate reviewer names, queue depths, or schedule data. Use only the provided inputs.
- If any input field is null or missing, flag it as a "critical" finding and set recommendation to "abort".
- Never recommend "proceed" if sla_breach_risk is "high" or "critical".

To adapt this template, replace each square-bracket placeholder with live data from your ticketing system (e.g., Jira, ServiceNow), on-call management tool (e.g., PagerDuty, Opsgenie), and approval queue backend. The [AVERAGE_REVIEW_TIME_MINUTES] variable inside the evaluation rules should be pulled from your historical SLA data or set as a constant in your harness. If your system lacks a formal SLA breach tracker, derive [PENDING_SLA_BREACHES] by querying for tickets in the queue older than your defined threshold. The output JSON should be validated against the schema before your agent's routing logic consumes it; reject any response that fails to parse or contains a recommendation that contradicts the sla_breach_risk level.

This prompt is designed to be called as a precondition gate before an agent submits any item to a human review queue. In a typical harness, the agent's planning module invokes this check after determining that a step requires human approval but before constructing the review request payload. The prompt consumes structured context about the target queue (name, SLA window, current time) and returns a machine-readable health report. The harness should parse the JSON output and branch on the queue_available and sla_breach_risk fields: if the queue is unavailable or SLA breach risk is high, the agent must not submit the review request and should instead follow the escalation path specified in the output.

Validation and retry logic is critical because a false available status can cause review requests to land in unmonitored queues. The harness should validate the output schema strictly: confirm that estimated_wait_minutes is a non-negative number, on_call_coverage is a boolean, and escalation_ready is a boolean. If the model returns malformed JSON or missing required fields, retry once with a repair prompt that includes the raw output and the expected schema. If the retry also fails, treat the queue as unavailable and escalate. For high-risk workflows (e.g., financial approvals, clinical sign-offs), add a human-in-the-loop confirmation step: display the queue health report to an operator and require explicit acknowledgment before the agent proceeds. Log every queue health check with the full prompt, response, validation result, and branching decision for auditability.

Model choice and latency considerations matter here because this is a blocking precondition. Use a fast, cost-efficient model (e.g., GPT-4o-mini, Claude Haiku) since the task is structured classification and extraction, not complex reasoning. Set a strict timeout (2-3 seconds) on the inference call. If the model does not respond within the timeout, treat the queue as unavailable and follow the escalation path. For environments with multiple approval queues, batch queue health checks into a single prompt call by providing an array of queue contexts and requesting a health report per queue, rather than making sequential calls. Do not cache queue health results for longer than the shortest SLA window in your system; stale health data is the most common failure mode in production, leading agents to submit reviews to queues that became unstaffed between checks.