Dependency-Aware Task Decomposition Prompt

This prompt is for agent architects and workflow engine developers who need to convert a complex objective into a structured, executable task graph with explicit prerequisite relationships. Use it when your agent orchestrator requires a valid topological ordering of subtasks, parallel execution groups, and a clear dependency map before execution begins. The output is a directed acyclic graph (DAG) of subtasks, not a flat list. This prompt belongs in the planning phase of an agent loop, after goal clarification but before tool selection and execution. It assumes you have already defined the objective and available tool set.

Do not use this prompt for simple linear workflows where ordering is obvious; a basic step-by-step decomposition prompt is cheaper and faster for those cases. This prompt is also inappropriate when the objective is too ambiguous to decompose meaningfully—run a goal clarification prompt first. The prompt requires a well-scoped objective, a known tool inventory, and any domain constraints as inputs. If your agent operates in a high-risk domain like healthcare or finance, you must pair this prompt with a human-in-the-loop approval gate before executing any irreversible actions identified in the task graph.

Before integrating this prompt, ensure your harness can validate the output for cycles, missing dependencies, and tasks that depend on outputs from later steps. The prompt produces a machine-readable structure, so your orchestration layer should parse and verify the DAG before execution. For production systems, log the generated task graph alongside the execution trace to enable post-hoc debugging when plans fail. If your workflow requires dynamic replanning, use this prompt as the initial plan generator and pair it with a separate replanning prompt that can update the graph when tool failures or unexpected outputs invalidate the original structure.

This prompt template is designed for agent orchestrators and planning modules that need more than a flat list of subtasks. It instructs the model to produce a directed acyclic graph (DAG) of tasks, where each task declares its prerequisites and its membership in a parallel execution group. The output is structured JSON that your execution harness can directly consume to schedule work, detect cycles, and identify tasks that are safe to run concurrently. Before using this prompt, ensure your model supports structured JSON output and has a context window large enough to accommodate your full tool list plus the expected output size. For high-risk or irreversible actions, always gate execution behind human approval steps and validate the plan's topological ordering before any tool is invoked.

textCopy
You are a planning agent that decomposes complex objectives into a dependency-aware task graph. Your output must be valid JSON conforming to the schema below.

OBJECTIVE:
[OBJECTIVE]

AVAILABLE TOOLS:
[TOOLS]

CONSTRAINTS:
[CONSTRAINTS]

OUTPUT SCHEMA:
{
  "goal_summary": "A one-sentence restatement of the clarified objective.",
  "assumptions": ["List any assumptions you made during decomposition."],
  "tasks": [
    {
      "task_id": "string, unique identifier",
      "description": "string, what this task does",
      "tool": "string or null, the tool required from AVAILABLE TOOLS",
      "depends_on": ["list of task_ids that must complete before this task starts"],
      "parallel_group": "string or null, tasks with the same non-null value can execute concurrently",
      "completion_criteria": "string, verifiable condition that defines task success",
      "output_schema": "string or null, expected shape of the task output"
    }
  ],
  "parallel_groups": [
    {
      "group_id": "string",
      "task_ids": ["list of task_ids in this group"],
      "shared_resources": ["list any mutable resources shared across these tasks"]
    }
  ]
}

RULES:
1. Every task must have a unique task_id.
2. The depends_on field must reference only valid task_ids defined in the tasks array.
3. The dependency graph must be acyclic. No circular dependencies.
4. Tasks in the same parallel_group must not depend on each other.
5. If a task requires a tool not in AVAILABLE TOOLS, flag it in the assumptions array and do not assign a tool.
6. For high-risk or irreversible actions, set the completion_criteria to include a human approval gate.
7. Every task must have at least one completion_criteria.
8. If the objective is ambiguous, add clarification questions to the assumptions array.

After pasting this template, replace each square-bracket placeholder with your specific context. [OBJECTIVE] should contain the user's goal or the system's high-level instruction, stated as clearly as possible. [TOOLS] should be a structured list of available functions, APIs, or capabilities, each with a name, description, and parameter schema. If your tool definitions are long, consider placing them in system context rather than inline to preserve prompt real estate. [CONSTRAINTS] should capture hard limits such as time budgets, forbidden actions, required approval gates, data residency rules, or output format requirements. The output schema is embedded directly in the prompt to guide structured generation; if your model provider offers a native JSON mode or function-calling interface, you can move the schema to the API parameter and simplify the prompt body. Always test the prompt with objectives of varying complexity to ensure the model does not produce tasks with hallucinated tools or circular dependencies.

This prompt is designed to be called after goal clarification and before any execution step in an agent orchestrator. The orchestrator should parse the JSON output into a directed acyclic graph (DAG) structure where each node is a task with a unique task_id, a depends_on list, and a tool assignment. Before a single task executes, run a validation pipeline that checks four invariants: cycle detection, missing dependency references, tool existence against the [AVAILABLE_TOOLS] registry, and orphan detection. These checks prevent the most common and costly failure modes—deadlocked agents, hallucinated tool calls, and tasks that never get scheduled.

Implement cycle detection using either depth-first search with a visited-and-recursion-stack approach or Kahn's algorithm for topological sorting. If a cycle is found, capture the offending task IDs and inject the specific error message into the [CONSTRAINTS] field of a single retry attempt. For missing dependencies, iterate through every depends_on value and confirm it references an existing task_id in the plan; if a reference is dangling, include the missing ID in the retry constraint. Tool existence checks should compare every tool field against a canonical list of available tool names—this is where most hallucinated capabilities surface. Orphan detection ensures every task either appears as a dependency of at least one other task or is the designated final task; isolated tasks often indicate incomplete decomposition or forgotten objectives. If any validation check fails after one retry, escalate to a human operator with the full prompt, response, and validation failure details rather than looping indefinitely.

For production observability, log the complete prompt payload, the raw model response, the parsed task graph, and the results of each validation check. This trace is essential for debugging planning failures, tuning the prompt, and demonstrating governance to reviewers. In long-running workflows, store the validated task graph as the execution contract and monitor for runtime deviations—such as a task producing unexpected output that invalidates downstream assumptions—that should trigger a replanning cycle. Wire the validated graph into your execution engine with explicit state transitions: pending, ready (all dependencies satisfied), in_progress, completed, and failed. Use the dependency edges to compute parallel execution groups by identifying all tasks whose dependencies are satisfied at each step. Avoid the temptation to skip validation in low-risk demos; the same cycle and hallucination bugs that break production systems appear in development and erode trust in the planning module before it ever ships.