Complex Task Decomposition Prompt Template

This prompt is designed for agent framework developers and orchestration engineers who need to break a single, complex user request into a dependency-ordered list of executable sub-tasks. The primary job-to-be-done is transforming an ambiguous or multi-faceted objective into a structured execution plan where each sub-task has a clear owner, input/output contract, and completion criteria. The ideal user is building or operating a multi-agent system and needs a reliable, machine-readable decomposition that can be passed to a task orchestrator or a pool of specialized agents.

Use this prompt when the incoming request is too large for a single agent to handle reliably, requires multiple distinct capabilities, or has internal dependencies that must be respected. It is appropriate for requests that involve research-then-write workflows, data collection followed by analysis, or any scenario where parallel execution of independent sub-tasks can reduce latency. The prompt expects a well-defined [USER_REQUEST] and, optionally, a [CAPABILITY_REGISTRY] describing available agents and their skills. It works best when you can provide concrete [CONSTRAINTS] such as latency budgets, context window limits, or required approval gates.

Do not use this prompt for simple, single-step requests that a single agent can complete in one turn. Avoid it when the user request is already a well-scoped task with no internal dependencies, or when the overhead of decomposition and handoff exceeds the execution time of the task itself. This prompt is also not a planning prompt for autonomous agents that must discover their own capabilities at runtime—it assumes you have a known agent pool. If the request involves high-stakes actions such as financial transactions, clinical decisions, or legal filings, the decomposition output must include explicit human approval gates and cannot be executed autonomously without review. For those scenarios, pair this prompt with the Human-in-the-Loop Handoff Structuring Prompt and ensure every sub-task carries a [RISK_LEVEL] marker that triggers escalation when confidence is low.

This section provides a copy-ready prompt template that you can drop into your agent orchestration layer. The template is designed to take a complex user request, a set of available agent capabilities, and any known constraints, and produce a dependency-ordered task list. Each sub-task includes an input/output contract, an agent role assignment, and completion criteria. The template uses square-bracket placeholders for all dynamic inputs so you can wire it directly into your prompt assembly pipeline without manual editing.

textCopy
You are a task decomposition planner for a multi-agent system. Your job is to break a complex user request into a set of executable sub-tasks that can be assigned to specialized agents.

## INPUT
User Request: [USER_REQUEST]

Available Agents and Capabilities:
[AGENT_CAPABILITIES]

Known Constraints:
[CONSTRAINTS]

Risk Level: [RISK_LEVEL]

## INSTRUCTIONS
1. Analyze the user request and identify all distinct work units required to fulfill it.
2. For each work unit, define a sub-task with a clear objective, required inputs, expected outputs, and completion criteria.
3. Assign each sub-task to the most appropriate agent from the available pool. If no agent is capable, flag the sub-task for human escalation.
4. Identify dependencies between sub-tasks. A sub-task cannot start until all its dependencies are completed.
5. Identify sub-tasks that can execute in parallel without data conflicts.
6. For each sub-task, estimate whether it is likely to succeed given the assigned agent's capabilities. Flag low-confidence assignments.
7. Produce the final plan as a dependency-ordered list.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "plan_id": "string",
  "original_request_summary": "string",
  "sub_tasks": [
    {
      "task_id": "string",
      "objective": "string",
      "assigned_agent": "string",
      "confidence_score": 0.0-1.0,
      "confidence_rationale": "string",
      "required_inputs": ["string"],
      "expected_output": {
        "schema": "string describing the output shape",
        "required_fields": ["string"],
        "validation_rules": ["string"]
      },
      "completion_criteria": ["string"],
      "depends_on": ["task_id"],
      "parallelizable_with": ["task_id"],
      "escalation_trigger": "string or null",
      "estimated_effort": "low | medium | high"
    }
  ],
  "execution_order": ["task_id"],
  "unassigned_work": [
    {
      "description": "string",
      "reason": "string",
      "recommended_action": "escalate_to_human | request_new_agent | defer"
    }
  ],
  "warnings": ["string"]
}

## RULES
- Every sub-task must have at least one completion criterion.
- Dependencies must reference valid task_ids within the plan.
- Do not create circular dependencies.
- If the risk level is "high", flag any sub-task with confidence_score below 0.8 for human review.
- If no agent can perform a required work unit, list it in unassigned_work rather than forcing a bad assignment.
- Keep objectives specific and measurable. Avoid vague language like "handle the thing."

To adapt this template, replace each square-bracket placeholder with data from your orchestration layer. [USER_REQUEST] should contain the full user input, not a summary. [AGENT_CAPABILITIES] should list each available agent by name with a short capability description and any known limitations. [CONSTRAINTS] can include latency budgets, context window limits, cost caps, or policy restrictions. [RISK_LEVEL] should be one of low, medium, or high and controls whether low-confidence assignments trigger automatic human review. After copying the template, test it against at least three diverse user requests and validate that the output JSON parses correctly, contains no circular dependencies, and assigns every required work unit to either an agent or the unassigned_work list.

This prompt is not a one-off chat interaction; it is a critical planning step inside an agent orchestrator. The orchestrator calls this prompt before any sub-agent is dispatched. The output is a machine-readable task plan that the orchestrator parses, validates, and uses to drive execution. Treat the prompt's output as a control artifact—if the plan is malformed, the entire multi-agent pipeline must halt or fall back to a simpler execution path. Wire this prompt as a synchronous pre-execution gate, not an asynchronous advisory call.

The implementation harness requires three layers: input assembly, output validation, and execution dispatch. For input assembly, collect the user's original request, available agent capability descriptions, current system state, and any hard constraints (budget, latency, required approvals). Pack these into the [USER_REQUEST], [AGENT_POOL], [CONSTRAINTS], and [CONTEXT] placeholders. After the model responds, parse the JSON output and run a structural validator that checks for: (1) valid JSON syntax, (2) a non-empty sub_tasks array, (3) each sub-task having a unique task_id, a non-empty agent_role, and a defined input_contract and output_contract, (4) all depends_on values referencing existing task_id values, and (5) no circular dependencies in the dependency graph. If validation fails, retry the prompt once with the validation errors appended to the [CONSTRAINTS] field. If the second attempt fails, log the failure, notify a human operator, and route the request to a simpler single-agent fallback.

For production reliability, wrap the prompt call in a retry policy with exponential backoff (initial delay 1s, max 3 attempts for transient model errors). Log every decomposition attempt with a trace ID that links the user request, the raw prompt, the model response, validation results, and the final accepted plan. This trace is essential for debugging when downstream agents produce conflicting or incomplete work. When the plan passes validation, the orchestrator should serialize it into an execution graph and begin dispatching sub-tasks according to the dependency order. Monitor for runtime failures where a sub-task's actual output does not match its declared output_contract—this indicates a decomposition error that should be fed back into the prompt's eval dataset for future regression testing. Do not use this prompt for trivial single-step requests; implement a lightweight classifier upstream that bypasses decomposition entirely when the user's intent is clearly a single-turn query or a direct tool call.