Approval Queue Routing Prompt for Agent Workflows

This prompt is for operations teams and platform engineers who need an agent to decide which human approval queue should receive a pending action. It is not a prompt for generating the approval request itself. Use it when your agent has already determined that an action requires human sign-off and now must route that request to the correct team, shift, or escalation path. The prompt ingests action metadata, team on-call schedules, SLA windows, and current queue depth to produce a deterministic routing decision with a fallback escalation target. It is designed to be called as a structured tool within an agent workflow, not as a free-text chatbot interaction.

This prompt is appropriate when you have multiple approval queues with distinct ownership, such as separate teams for database changes, infrastructure modifications, and customer-facing actions. It handles load balancing across shifts, escalation when a primary queue is unresponsive, and duplicate suppression to prevent the same action from appearing in multiple queues. The prompt requires structured inputs including action type, severity classification, affected resources, team ownership mappings, on-call schedules, and current queue depths. Without this context, the routing decision will be unreliable. The output is a machine-readable routing decision with a primary queue, escalation queue, and a unique correlation ID for audit trail linkage.

Do not use this prompt when you have a single approval queue or when the agent itself should decide whether approval is needed. This prompt assumes the approval decision has already been made upstream. It is also not suitable for generating the content of the approval request—that should be handled by a separate prompt focused on risk description and justification. Before deploying, validate the routing logic against your actual on-call schedules and test edge cases such as overlapping shifts, holiday schedules, and queue saturation. For regulated environments, ensure the routing decision is logged immutably and that the correlation ID is propagated through all downstream systems to maintain an unbroken audit trail from action request to human sign-off.

This template is designed to be pasted directly into your agent's tool-calling layer. It instructs the model to act as an approval router, consuming structured data about a pending action and the current operational state of your queues. The model's job is not to approve or deny the action, but to determine the single correct routing destination, handling load balancing, escalation on timeout, and duplicate suppression. Replace every square-bracket placeholder with live data from your queue management system, on-call provider (e.g., PagerDuty, Opsgenie), and action classifier before sending the prompt.

textCopy
You are an Approval Queue Router for an agent workflow system. Your sole task is to determine the correct routing destination for a pending approval request. You do not approve or deny the action itself.

You will receive a pending action and a snapshot of the current state of all approval queues. Use this information to output a single routing decision.

## INPUT
- Pending Action: [ACTION_DETAILS_JSON]
- Queue State Snapshot: [QUEUE_STATE_JSON]
- On-Call Schedules: [ONCALL_SCHEDULES_JSON]

## ROUTING RULES
Apply these rules in order. The first matching rule determines the queue.
1. **Exact Team Ownership:** If the action's `owner_team` matches a queue's `team_id` and that queue's `status` is `active`, route to that queue.
2. **Severity-Based Routing:** If no team match, route based on the action's `severity` to the queue with the matching `severity_level` and `status` `active`.
3. **Load Balancing:** If multiple active queues match the team or severity, select the queue with the lowest `active_request_count`.
4. **Escalation on Timeout:** If the selected queue's `oldest_pending_minutes` exceeds its `escalation_threshold_minutes`, do not route there. Instead, route to its `escalation_queue_id`. If the escalation queue is also timed out, route to the `default_escalation_queue_id`.
5. **Duplicate Suppression:** If the `action_id` is found in any queue's `recent_action_ids` list, output a `duplicate` status and do not route.
6. **Fallback:** If no rule matches, route to the `global_fallback_queue_id`.

## OUTPUT_SCHEMA
You must output a single, valid JSON object with no other text.
{
  "status": "routed" | "duplicate" | "no_available_queue",
  "action_id": "string",
  "target_queue_id": "string | null",
  "routing_reason": "string",
  "escalation_applied": boolean
}

## CONSTRAINTS
- Do not invent queue IDs. Only use IDs present in the Queue State Snapshot.
- If `status` is `duplicate`, `target_queue_id` must be `null`.
- The `routing_reason` must cite the specific rule number (1-6) that was applied.

To adapt this prompt, start by mapping your internal data models to the [ACTION_DETAILS_JSON] and [QUEUE_STATE_JSON] placeholders. The action details must include, at minimum, an action_id, owner_team, and severity field. The queue state should be a real-time snapshot of every active queue's ID, team ownership, current load, and escalation thresholds. For high-risk actions, such as those involving financial transactions or PII, ensure the severity field in the action details is calibrated to force human review by routing to a queue that has no auto-approval policy. Before deploying, run a suite of evals that includes a test case for each routing rule, a case for a timed-out queue, and a case with a duplicate action_id to verify the suppression logic works end-to-end.

The Approval Queue Routing Prompt is not a standalone artifact; it is a decision node inside a larger agent execution loop. The prompt should be invoked immediately after a tool action is classified as requiring human approval, but before any approval request is dispatched. The model receives the action context, the available queues, and the current operational state, and it returns a structured routing decision. This decision must be validated against the actual queue registry before any message is sent, because the model can hallucinate queue names, assignees, or SLA targets that do not exist in the live system.

Wire the prompt into your agent harness with a strict contract: the input must include a resolved [ACTION_TYPE], [SEVERITY_SCORE], [TEAM_OWNERSHIP_MAP], [ON_CALL_SCHEDULE], and [QUEUE_REGISTRY] with current load metrics. The output must conform to a schema that includes target_queue_id, escalation_queue_id, routing_reason, priority_override, and duplicate_check_hash. After the model returns, run a validator that confirms the target_queue_id exists in the live queue registry, the assignee is currently on-call if the schedule requires it, and the duplicate_check_hash does not match any pending or recently resolved approval in the last N minutes. If validation fails, do not retry the prompt blindly. Log the mismatch, append the validator error to the context, and re-invoke the prompt with the corrected registry state. After two consecutive validation failures, escalate to a human operator with the full trace.

For high-risk domains—financial transactions, production configuration changes, or regulated data access—add a synchronous human review step after routing but before dispatch. The routing prompt should produce a preview of the approval request that a human can confirm or redirect. Log every routing decision with the model version, input context hash, output payload, validator results, and final dispatch action. This audit trail is critical for compliance reviews and for debugging routing drift as queues, teams, and schedules evolve. Avoid treating the routing prompt as a fire-and-forget step; it is a gated decision that must survive queue outages, stale on-call data, and model confidence degradation.