Sub-Agent Selection Criteria Prompt Template

This prompt is a core component of an orchestrator's control loop, not a general-purpose chatbot interface. Its job-to-be-done is to make a defensible, auditable routing decision when a new task arrives. The ideal user is an AI architect or platform engineer building a compound AI system where work must be dispatched across a pool of specialized sub-agents. The prompt requires three structured inputs to function: a machine-readable agent registry detailing each agent's capabilities, current load, and past performance; a well-formed task description with explicit constraints; and the operational parameters like latency budgets and cost limits that govern the dispatch decision. Without these, the selection logic degrades into guesswork.

Do not use this prompt for direct task execution, user-facing chat, or single-agent workflows. It is a decision-support tool whose output—a ranked agent selection with rejection reasons—must feed into downstream dispatch logic, handoff protocols, and audit trails. The prompt is designed to enforce explicit reasoning: it requires the model to document why non-selected agents were rejected, apply tie-breaking rules when capability matches are equivalent, and consider dynamic factors like agent load and recent failure rates. For high-stakes dispatch decisions, the output should be logged immutably and, where the cost of misrouting is severe, subjected to a secondary validation check or human approval before the handoff executes.

After integrating this prompt, your next step is to wire its structured output into your orchestrator's dispatch function. The ranked list should drive agent selection, the rejection reasons should populate your observability dashboards, and the tie-breaking logic should be periodically reviewed against production outcomes to detect drift in agent performance. Avoid the common failure mode of treating this as a static routing table; agent capabilities and loads change, and a prompt that worked last month may silently route tasks to overloaded or degraded agents if the registry input is stale.

This prompt template implements a deterministic orchestrator that selects a sub-agent from a registry without executing the task itself. It is designed for compound AI systems where a dispatcher must evaluate multiple candidates against capability, latency, cost, and performance constraints before routing work. The template enforces explicit selection rules, documents why agents were rejected, and escalates to a human operator when no agent meets the minimum threshold—making the decision auditable and debuggable in production.

textCopy
You are an orchestrator selecting the best sub-agent for a task. Your output will be consumed by a dispatch system. Do not execute the task yourself.

## Agent Registry
[AGENT_REGISTRY]

## Task
[TASK_DESCRIPTION]

## Operational Constraints
- Latency budget: [LATENCY_BUDGET_MS] ms
- Cost budget: [COST_BUDGET_USD] USD
- Required output format: [OUTPUT_FORMAT]
- Priority: [PRIORITY_LEVEL]

## Selection Rules
1. Filter agents whose declared capabilities match all required capabilities for the task.
2. Exclude agents whose current load exceeds [MAX_LOAD_PERCENT]% or whose status is not 'available'.
3. Score remaining agents on: capability match (0-100), estimated latency fit (0-100), cost fit (0-100), and past success rate for similar tasks (0-100).
4. Apply weights: capability match 40%, latency fit 25%, cost fit 20%, past performance 15%.
5. Rank agents by weighted score descending.
6. If the top two agents are within [TIE_THRESHOLD] points, apply tie-breaker: prefer the agent with lower current load, then lower estimated cost.
7. If no agent meets the minimum score of [MINIMUM_SCORE], recommend escalation to a human operator.

## Output Format
Return a JSON object with this exact structure:
{
  "selected_agent": {
    "agent_id": "string",
    "agent_name": "string",
    "weighted_score": number,
    "selection_reason": "string"
  },
  "ranking": [
    {
      "rank": number,
      "agent_id": "string",
      "agent_name": "string",
      "weighted_score": number,
      "capability_score": number,
      "latency_score": number,
      "cost_score": number,
      "performance_score": number
    }
  ],
  "rejected_agents": [
    {
      "agent_id": "string",
      "agent_name": "string",
      "rejection_reason": "string"
    }
  ],
  "escalation_required": boolean,
  "escalation_reason": "string | null"
}

To adapt this template, replace each square-bracket placeholder with concrete values from your agent infrastructure. The [AGENT_REGISTRY] should contain a structured list of agents with their agent_id, agent_name, declared_capabilities, current_load_percent, status, estimated_latency_ms, estimated_cost_usd, and past_success_rate. The [TASK_DESCRIPTION] must include enough detail for capability matching—vague task descriptions produce unreliable selections. Tune the weights in rule 4 to match your operational priorities: latency-sensitive systems should increase the latency weight, while cost-constrained deployments should emphasize cost fit. The [TIE_THRESHOLD] and [MINIMUM_SCORE] values should be calibrated against historical selection quality; start with a threshold of 5 points and a minimum score of 60, then adjust based on production outcomes.

Before deploying this prompt, validate that the output JSON matches the declared schema exactly—any deviation will break the downstream dispatch system. Add a post-processing validator that checks for required fields, numeric ranges on scores, and the presence of escalation_reason when escalation_required is true. For high-stakes routing decisions, log the full ranking and rejection reasons alongside the selected agent so operators can audit selection quality over time. If the orchestrator consistently escalates or selects the same agent regardless of task, review whether the agent registry contains accurate capability declarations and whether the scoring weights reflect real-world performance rather than optimistic estimates.

Wire this prompt into your orchestrator's agent selection function. The orchestrator should call this prompt before every dispatch decision. Pass the agent registry as a JSON array of capability manifests. Each manifest must include agent_id, agent_name, capabilities (array of strings), current_load_percent, status, estimated_latency_ms, estimated_cost_usd, and past_success_rate. The task description should be a structured object with required_capabilities, input_data_summary, and any special instructions. Parse the JSON output and validate it against the expected schema before using the selected_agent field to route the task.

Log the full ranking and rejected_agents list to your audit system for post-incident review. If escalation_required is true, route to your human review queue with the escalation_reason attached. Set a timeout on the model call; if it fails, fall back to a static routing rule or escalate. Validate that the selected agent's agent_id exists in your current registry and that its status is active before dispatch. Reject selections where the agent is overloaded (current_load_percent > 90) or where estimated_latency_ms exceeds your task's latency budget. For high-risk tasks, require a second validation pass or a human approval step before the dispatch executes.

Choose a model with strong JSON output reliability for this prompt. GPT-4o and Claude 3.5 Sonnet work well with the structured output schema. Avoid smaller models that may drop fields or hallucinate agent IDs. If you use a model that doesn't support strict JSON mode, add a post-processing step that extracts and repairs the JSON payload before validation. Cache the agent registry manifest between calls to reduce token usage, but refresh it when agent status or load changes. If your registry exceeds 20 agents, consider pre-filtering by capability match before passing the full list to the prompt to stay within context limits.