Sub-Task Dependency Mapping Prompt Template

This prompt is for orchestration engineers who have already decomposed a complex task into a list of sub-tasks, each with clearly defined inputs and outputs. The job-to-be-done is to define the execution order by producing a directed acyclic graph (DAG). This graph must map data dependencies, identify opportunities for parallel execution, and flag blocking conditions where one task cannot start until another completes. The ideal user is an AI platform engineer or workflow builder who needs a machine-readable execution plan to prevent race conditions, missing inputs, and circular waits before dispatching work to agents.

Use this prompt when you have a complete sub-task list with explicit input/output contracts but need to determine the safe execution sequence. It is appropriate when the sub-tasks are well-scoped and you need to optimize for parallelism while avoiding dependency violations. Do not use this prompt to decompose a high-level goal into sub-tasks—that is the job of a task decomposition prompt. Do not use it to assign sub-tasks to specific agents or to define the schemas for sub-task inputs and outputs. This prompt assumes those steps are already complete. It also does not handle runtime re-planning if a sub-task fails mid-execution; that requires a dynamic re-decomposition prompt.

Before invoking this prompt, ensure you have a structured list of sub-tasks where each entry includes a unique identifier, a description, a list of required inputs with their data types, and a list of produced outputs. The prompt will fail silently or produce an invalid DAG if inputs and outputs are ambiguously named or if a sub-task's dependencies are not traceable to another sub-task's outputs. After receiving the DAG, validate it programmatically by checking for cycles, orphaned tasks with no path to completion, and missing inputs that are not produced by any upstream task. For high-stakes workflows, log the generated DAG for human review before handing it to an agent orchestrator.

This template is designed to be dropped directly into an agent orchestrator or a planning step within a multi-agent framework. It takes a flat list of sub-tasks, each with defined inputs and outputs, and produces a directed acyclic graph (DAG) that enforces execution order. The prompt is structured to prevent cycles, identify orphaned tasks, and highlight parallelization opportunities before any agent is dispatched.

codeCopy
You are a workflow orchestration engine. Your task is to analyze a list of sub-tasks and produce a strict dependency map.

### INPUT
[SUB_TASK_LIST]

### CONSTRAINTS
- Produce a valid Directed Acyclic Graph (DAG). No cycles are permitted.
- A dependency exists only if Task B explicitly requires an output artifact produced by Task A.
- Do not infer dependencies based on topic similarity alone; rely strictly on matching output types to input requirements.
- Identify tasks with no dependencies (entry points) and tasks on which no other task depends (exit points).
- Flag any task that requires an input not produced by any other task in the list as an [ORPHANED_TASK].
- Flag any output artifact that is produced but never consumed as [UNUSED_OUTPUT].

### OUTPUT_SCHEMA
Return a single JSON object matching this structure:
{
  "dag": {
    "nodes": [
      {
        "task_id": "string",
        "description": "string",
        "input_artifacts": ["string"],
        "output_artifacts": ["string"],
        "status": "READY" | "BLOCKED"
      }
    ],
    "edges": [
      {
        "from_task_id": "string",
        "to_task_id": "string",
        "artifact": "string"
      }
    ]
  },
  "parallel_groups": [["task_id"], ["task_id"]],
  "validation_warnings": [
    {
      "type": "ORPHANED_TASK" | "UNUSED_OUTPUT" | "MISSING_INPUT",
      "task_id": "string",
      "detail": "string"
    }
  ]
}

### RISK_LEVEL
[HIGH_RISK_MODE]

To adapt this template, replace [SUB_TASK_LIST] with your structured array of tasks, ensuring each task object includes explicit input_artifacts and output_artifacts fields. The [HIGH_RISK_MODE] placeholder should be set to true if the workflow involves destructive actions, financial transactions, or unskippable compliance steps; when active, the orchestrator should block execution until all ORPHANED_TASK and MISSING_INPUT warnings are resolved by a human. After receiving the DAG, validate it programmatically by running a cycle-detection algorithm (e.g., depth-first search) on the returned edges before using the parallel_groups to dispatch work. If the model returns a cycle despite the constraints, reject the output and retry with a lower temperature setting or a stronger explicit penalty in the system prompt.

The sub-task dependency mapping prompt is not a standalone utility; it is the planning stage of a multi-agent orchestration pipeline. The prompt consumes a list of decomposed sub-tasks and produces a directed acyclic graph (DAG) with explicit data dependencies, parallelization groups, and blocking conditions. The output must be machine-readable so the orchestrator can execute the graph without re-parsing natural language. Treat the prompt output as a build artifact that is validated, versioned, and fed directly into a DAG executor such as LangGraph, Temporal, Prefect, or a custom state machine.

Validation before execution is mandatory. Before any agent is dispatched, run the output through a DAG validator that checks for: (1) cycles—any circular dependency must reject the plan and trigger a re-prompt with the cycle explicitly called out; (2) missing inputs—every sub-task's depends_on field must reference only sub-tasks present in the decomposition; (3) orphaned tasks—every sub-task must either be a terminal node or feed into at least one downstream task; (4) schema compliance—the output must match the expected JSON schema with task_id, depends_on, output_schema, parallel_group, and blocking_conditions fields. If validation fails, retry the prompt with the specific validation error injected into [CONSTRAINTS] as a correction directive. Do not proceed to execution with an invalid DAG.

Wiring into an orchestration engine follows a three-stage pattern. First, call the dependency mapping prompt with the decomposed task list and any resource constraints. Second, validate the DAG output using a deterministic validator (not an LLM). Third, translate the validated DAG into your orchestrator's execution model: map parallel_group values to concurrent execution slots, wire depends_on into task futures or promises, and attach blocking_conditions as pre-execution guards. For example, in a LangGraph implementation, each sub-task becomes a node, depends_on defines edges, and parallel_group nodes share a concurrency key. Log the full DAG, validation results, and any re-prompt events for debugging and audit trails.

Failure modes to instrument: The most common production failure is a dependency that the orchestrator cannot resolve because a sub-task output shape doesn't match what a downstream task expects. Mitigate this by pairing the dependency mapping prompt with the Input/Output Contract Definition Prompt—validate that every output_schema in the DAG satisfies the input_schema of its dependents before execution. A second failure mode is stale plans: if a sub-task fails mid-graph and requires re-decomposition, do not reuse the original DAG. Instead, call the Dynamic Re-Decomposition Prompt and regenerate the dependency map from the failure point forward, preserving completed sub-task outputs as fixed inputs. Finally, always set a global timeout on the full graph execution and define escalation behavior if the DAG cannot complete within the latency budget.

Model choice and cost considerations: Dependency mapping is a reasoning-heavy task that benefits from frontier models with strong structured output capabilities. Use a model that supports strict JSON mode or tool calling to enforce the DAG schema. Cache the prompt prefix containing the decomposition format and output schema to reduce per-call latency and cost. For high-throughput systems, consider routing simple linear dependency chains to a smaller model and reserving the full prompt for complex graphs with parallelization opportunities. Always log the model version, prompt hash, and validation pass/fail status to track plan quality over time.