Review Queue Routing Prompt for Multi-Team Operations

This prompt is designed for platform engineers building triage systems that route AI-generated work items, flagged content, or automated decisions into human review queues across multiple departments. The core job-to-be-done is taking a review item and a team directory as input, then producing a routing decision with a primary team assignment, a clear rationale, and a list of required stakeholders. Use this prompt when your review pipeline spans security, compliance, support, engineering, and product teams, and a wrong routing decision means a critical item sits unseen in the wrong queue while SLA timers burn down. The ideal user is an infrastructure or platform engineer who owns the triage layer connecting AI outputs to human operators, and who needs routing logic that can adapt to organizational changes without redeploying application code.

The prompt requires two concrete inputs to function: a structured review item containing the content, metadata, and any AI-generated decisions or flags, and a team directory that maps team names to responsibilities, expertise, and escalation paths. The output is a routing decision object with a primary team assignment, a routing rationale that explains why that team was chosen over alternatives, and a list of required stakeholders who must be informed or must approve before the item is closed. This is not a simple keyword classifier. The prompt reasons about cross-team dependencies, regulatory obligations, and the nature of the work item to make a contextual routing decision. For example, a flagged financial transaction might route to compliance as primary with legal and security as required stakeholders, while a model confidence failure on a customer-facing response might route to support with product engineering informed.

Do not use this prompt for single-team routing where a simple keyword classifier or rule-based dispatcher would suffice. If your organization has one review queue and routing is deterministic based on item type, this prompt adds latency and cost without benefit. Do not use this prompt for real-time blocking decisions where latency is measured in milliseconds rather than seconds. A model call for routing adds 500ms to several seconds of overhead, which is unacceptable in a synchronous request path where a user is waiting. In those cases, use a pre-computed routing table or a fast classifier model. Do not use this prompt when the team directory changes faster than you can update the prompt context. If teams reorganize weekly, the prompt will produce stale routing decisions. Instead, invest in a team discovery service that the application layer queries before assembling the prompt. Finally, do not use this prompt as a replacement for an incident management platform. It routes items to queues; it does not page on-call engineers, enforce escalation policies, or track acknowledgment. Those capabilities belong in the application harness, not the prompt.

This prompt template is designed to be pasted directly into your system instructions or as a user message template in your triage application. It takes a structured review item and a map of available teams as input, and it produces a routing decision that includes the assigned team, a clear rationale, and a list of required stakeholders. The prompt is built to enforce structured JSON output, making it directly consumable by downstream orchestration logic or a human review queue dashboard.

textCopy
You are a review queue router for a multi-team operations platform. Your task is to analyze a review item and assign it to the most appropriate team based on the item's content, required action, and domain.

INPUT:
- Review Item: [REVIEW_ITEM_JSON]
- Available Teams: [TEAM_MAP_JSON]

INSTRUCTIONS:
1. Analyze the review item's `title`, `description`, `action_required`, and `tags`.
2. Compare the item's needs against the `capabilities` and `domain` of each team in the Available Teams map.
3. Select the single most appropriate team. If no team is a clear fit, assign to a designated `fallback_team` if one is defined in the team map; otherwise, assign to `"unrouted"`.
4. Identify any other teams or roles that must be informed or must approve the action, based on cross-team dependencies, compliance requirements, or the `blast_radius` of the action.
5. Construct a concise routing rationale that explains *why* this team was chosen over others.

CONSTRAINTS:
- Do not invent teams. Only use teams from the provided [TEAM_MAP_JSON].
- If the item is marked with `risk_level: "critical"`, the `"security"` team must be included as a required stakeholder.
- If the item involves a `"data_deletion"` action, the `"compliance"` team must be included as a required stakeholder.

OUTPUT_SCHEMA:
{
  "assigned_team": "string",
  "routing_rationale": "string",
  "required_stakeholders": ["string"],
  "confidence": "high" | "medium" | "low"
}

To adapt this prompt, replace [REVIEW_ITEM_JSON] with a JSON object representing the item to be routed, including fields like id, title, description, action_required, tags, and risk_level. Replace [TEAM_MAP_JSON] with a JSON object where keys are team names and values are objects describing their capabilities and domain. Before deploying, test this prompt with items that sit at the boundary between two teams to ensure the routing rationale is logical and not brittle. For high-stakes environments, always log the confidence score and route "low" confidence decisions to a human triage queue for a second look.

Integrating the Review Queue Routing Prompt into a multi-team operations platform requires treating it as a deterministic component within a broader orchestration layer, not a standalone chatbot. The prompt expects a structured [INPUT] containing the review item's full context, evidence, and any prior classification attempts. The application layer is responsible for assembling this payload from upstream systems—ticketing tools, monitoring alerts, or internal review queues—and injecting it into the prompt template before calling the model. The output must be validated against the [OUTPUT_SCHEMA] before any routing action is taken; a malformed JSON response or a team assignment that doesn't match the [TEAM_CATALOG] should trigger a retry or fallback, never a silent misroute.

Start with a strict output contract. Define the expected JSON schema in your application code and validate the model's response field-by-field: routing_decision.team must be a non-empty string present in your authorized team list; routing_decision.confidence must be a float between 0.0 and 1.0; rationale must be a non-empty string; and required_stakeholders must be an array of objects with role and reason fields. If validation fails, implement a retry loop with a maximum of two additional attempts, each time feeding the validation error message back into the prompt as a correction instruction. After three total failures, escalate the item to a default human-staffed triage queue with the full context and error log attached. Log every routing decision—including retries and validation failures—to your observability platform with the prompt version, model ID, latency, and the final routing outcome for later audit and eval analysis.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o or Claude 3.5 Sonnet, and set temperature to 0 or a very low value (e.g., 0.1) to minimize variance in team assignment. If your platform supports it, use the model's native JSON mode or function-calling interface to enforce schema compliance at the API level, reducing the likelihood of parse errors. For high-throughput queues, consider caching the system instruction prefix and batching non-urgent items to control cost and latency. Implement a human review checkpoint for any routing decision where the model's confidence falls below a configurable threshold (e.g., 0.8) or where the cross_team_dependency flag is set to true. These items should land in a dedicated 'routing review' queue where a human operator can confirm or override the assignment before the item reaches the target team.

Finally, build eval harnesses that run offline against a golden dataset of pre-routed items. Measure misrouting frequency—how often the model assigns an item to a team different from the human-labeled ground truth—and cross-team dependency detection recall. Track these metrics per prompt version and per team to catch regressions when you update the [TEAM_CATALOG] or routing rules. Avoid wiring the prompt directly to automated actions like ticket reassignment or pager notifications without a human-in-the-loop confirmation step for any item flagged as high-risk or low-confidence. The prompt is a decision-support tool; the application harness is what enforces safety.