Cost-Aware Task Routing Prompt for Agent Delegation

This prompt is for platform operators and orchestration engineers who need to assign sub-tasks to a pool of specialized agents while balancing quality requirements against compute cost, latency budgets, and model tier constraints. The job-to-be-done is producing a cost-optimized assignment plan that justifies trade-offs and enforces budget guardrails—not just picking the cheapest or most capable agent. Use this when you have a decomposed task list, a known agent pool with priced capabilities, and a hard budget or latency ceiling that must be respected.

Do not use this prompt when the agent pool is homogeneous, when cost is irrelevant, or when every task must hit a fixed quality bar regardless of price. It is also inappropriate for single-agent workflows, tasks without clear input/output contracts, or situations where the orchestrator lacks visibility into agent pricing and current load. This prompt assumes you have already decomposed the work and defined sub-task contracts; it does not perform decomposition or capability discovery itself. If you need to discover agent capabilities dynamically, pair this with an agent capability discovery prompt before routing.

The ideal reader is an infrastructure or platform engineer wiring this into an agent orchestration layer. You should have access to a capability registry with per-agent pricing tiers, latency estimates, and quality benchmarks. Before using this prompt in production, validate the cost estimation accuracy against actual execution metrics and monitor for quality regression when cheaper agents are selected. If the task involves regulated data, safety-critical actions, or irreversible side effects, require human approval on the routing plan before dispatch.

This template is designed to be dropped into an agent orchestrator that has already decomposed a complex task into sub-tasks. It takes a list of sub-tasks, a pool of available agents with their capabilities and cost profiles, and a set of budget constraints, then produces a cost-optimized assignment plan. The prompt forces the model to justify trade-offs explicitly rather than defaulting to the most capable agent for every task, which is the most common failure mode in production routing systems.

textCopy
You are a cost-aware task router for a multi-agent system. Your job is to assign sub-tasks to agents while minimizing total compute cost, respecting latency budgets, and maintaining quality thresholds.

## AVAILABLE AGENTS
[AGENT_POOL]
<!-- Format: agent_id, capabilities, model_tier, cost_per_1k_tokens, avg_latency_ms, max_context_tokens, current_load_pct -->

## SUB-TASKS TO ASSIGN
[SUB_TASKS]
<!-- Format: task_id, description, required_capabilities, min_quality_tier, max_latency_ms, input_tokens_estimate, output_tokens_estimate, dependency_task_ids -->

## BUDGET CONSTRAINTS
- Total compute budget: [TOTAL_BUDGET_TOKENS]
- Per-task latency ceiling: [PER_TASK_LATENCY_MS]
- Minimum quality tier per task: [MIN_QUALITY_TIER]
- Parallel execution budget: [MAX_PARALLEL_AGENTS]

## ROUTING RULES
1. Assign each sub-task to exactly one agent.
2. An agent can handle multiple tasks if load permits, but do not exceed 80% utilization.
3. Prefer lower-cost agents when quality requirements allow it.
4. If a task's dependency has not completed, the assigned agent must wait. Account for dependency chains in latency estimates.
5. If no agent meets both quality and latency requirements, flag the task for escalation.
6. If total estimated cost exceeds the budget, identify which tasks can be downgraded to a lower tier with acceptable quality loss.

## OUTPUT SCHEMA
Return a JSON object with this structure:
{
  "assignments": [
    {
      "task_id": "string",
      "assigned_agent_id": "string",
      "estimated_cost_tokens": number,
      "estimated_latency_ms": number,
      "quality_tier": "string",
      "trade_off_justification": "string",
      "escalation_required": boolean,
      "escalation_reason": "string | null"
    }
  ],
  "total_estimated_cost_tokens": number,
  "budget_utilization_pct": number,
  "escalations": ["task_id"],
  "downgrade_recommendations": [
    {
      "task_id": "string",
      "current_tier": "string",
      "recommended_tier": "string",
      "quality_impact": "string",
      "cost_savings_tokens": number
    }
  ],
  "parallel_execution_groups": [["task_id"]],
  "critical_path_latency_ms": number,
  "unassignable_tasks": [
    {
      "task_id": "string",
      "blocking_constraint": "string"
    }
  ]
}

## CONSTRAINTS
- Do not assign tasks to agents that lack required capabilities.
- Do not exceed per-task latency ceilings on the critical path.
- If budget is insufficient even after downgrades, flag the shortfall explicitly.
- Justify every assignment where a cheaper agent was available but not chosen.
- For escalation flags, specify whether the issue is capability gap, latency violation, or quality risk.

Adapt this template by replacing the agent pool and sub-task formats with your actual internal schemas. If your system uses MCP servers or tool-based agent discovery, replace the static [AGENT_POOL] with a dynamically populated capability registry. The output schema should match whatever your orchestrator expects—if your orchestrator consumes protobuf or a different JSON shape, adjust the schema block accordingly. The routing rules section is where most teams need customization: add rules for data residency, compliance boundaries, or organizational policies that constrain which agents can handle which data. Test this prompt with edge cases where no agent meets all constraints, where the budget is unrealistically tight, and where dependency chains create latency cascades. These edge cases reveal whether the model will silently produce invalid assignments or correctly escalate.

The cost-aware routing prompt is not a standalone decision engine. It should sit inside an orchestration layer that enforces the budget constraints the prompt recommends, validates the assignment plan before dispatching agents, and logs every routing decision for cost attribution and quality regression analysis. The prompt produces a plan; the harness makes it executable, auditable, and safe.

Start by wrapping the prompt call in a pre-flight validation gate. Before the prompt runs, the harness should inject the current [BUDGET_REMAINING], [LATENCY_BUDGET_MS], and [AVAILABLE_MODEL_TIERS] from live infrastructure state—not stale config. After the prompt returns its assignment plan, run a schema validator that checks every sub-task assignment has a non-null agent_id, a model_tier that exists in the available pool, and an estimated_cost that sums to less than the remaining budget. Reject plans that exceed budget or reference unavailable models. If validation fails, either re-prompt with the specific violation as a [CONSTRAINT] update or escalate to a human operator with the failed plan and budget snapshot.

Cost estimation accuracy is the most common failure mode. The prompt's cost estimates are approximate; the harness must track actual token consumption and latency per sub-task and compare them against the prompt's estimates. Store these deltas in a structured log: {routing_id, sub_task_id, estimated_cost, actual_cost, estimated_latency_ms, actual_latency_ms, model_tier}. When actual costs consistently exceed estimates by more than 20%, trigger a quality regression alert and consider switching to a conservative cost-estimation model or adding a fixed overhead multiplier to the prompt's [CONSTRAINTS]. For high-stakes workflows, implement a hard budget kill switch: if cumulative actual spend reaches 90% of the allocated budget mid-execution, pause the remaining sub-tasks and escalate rather than silently overrunning.

Model choice matters here. The routing prompt itself should run on a fast, cheap model (e.g., GPT-4o-mini, Claude Haiku) because it's a classification-and-planning task that doesn't require deep reasoning. Reserve expensive models for the sub-tasks that the prompt routes to them. If the routing prompt produces inconsistent plans across repeated calls with the same inputs, upgrade it to a more capable model or add few-shot examples of correct routing decisions. Log routing plan hashes to detect non-determinism.

Retries and fallbacks need careful design. If a sub-task agent fails, do not blindly re-call the routing prompt for the entire plan. Instead, implement a targeted re-routing path: extract the failed sub-task's [INPUT] and [CONSTRAINTS], append the failure reason, and call a lightweight re-assignment prompt that selects a fallback agent or model tier for that single sub-task. Preserve the rest of the plan. If the fallback also fails, escalate the entire task to a human with the full execution trace, not just the final error. Avoid the trap of infinite retry loops by setting a hard limit of one re-assignment attempt per sub-task.

Observability is non-negotiable. Every routing decision should produce a structured audit record containing: the original task, the decomposed sub-tasks, the assigned agents and model tiers, the estimated and actual costs, the latency budget consumed, any validation failures, and the final outcome per sub-task. Use these records to build a dashboard that tracks cost-per-task, budget utilization rate, estimation accuracy, and escalation frequency. This data is essential for tuning the prompt's [CONSTRAINTS] and proving to stakeholders that the cost-aware routing is actually saving money without degrading quality.