Dependency-Aware Workflow Sequencing Prompt

This prompt is for platform engineers orchestrating multi-step AI pipelines where tasks have upstream dependencies that must be satisfied before execution. Use it when you have a set of tasks, a defined set of workflow stages, and a dependency graph that dictates execution order. The prompt produces a sequenced dispatch plan that respects dependencies, completion status, and resource availability. It is designed for systems where a downstream orchestrator reads the plan and executes tasks in the specified order.

Do not use this prompt for simple linear pipelines, single-step task assignment, or real-time request routing where dependency resolution is not required. This prompt assumes you have already classified the task and identified the relevant workflow stages; it focuses exclusively on sequencing logic. The ideal user is an AI infrastructure engineer who has already built classification and routing middleware and now needs to determine in what order tasks should execute across a multi-stage pipeline. Required context includes a complete task list with unique identifiers, a dependency map expressed as task_id -> [prerequisite_task_ids], the current completion status of all tasks, and any resource constraints or stage capacity limits.

Before using this prompt, ensure your upstream classification and routing systems have already assigned each task to a workflow stage. This prompt does not classify tasks or select which workflow they belong to—it only sequences them. If you need to route tasks to queues based on intent, priority, or confidence scores, use the Intent-to-Queue Dispatch, Priority-to-Queue Mapping, or Confidence-Gated Dispatch prompts first. After sequencing, wire the output into your orchestrator's execution loop and monitor for deadlocks, dependency cycles, and starvation patterns described in the evaluation section.

This prompt template is designed for platform engineers orchestrating multi-step AI pipelines. It takes a set of tasks with declared dependencies, current completion status, and resource availability, then produces a sequenced dispatch plan. The model must reason about partial ordering, detect cycles, and avoid scheduling tasks whose upstream dependencies are incomplete or blocked. Use this as the core instruction block inside your workflow engine, replacing each square-bracket placeholder with pipeline-specific data before sending it to the model.

textCopy
You are a workflow sequencing engine. Your job is to produce a valid, deadlock-free task dispatch plan given a set of tasks, their dependencies, current completion status, and available resources.

## INPUT
[INPUT]

## CONSTRAINTS
- A task MUST NOT be scheduled unless all its upstream dependencies are marked COMPLETE.
- A task marked COMPLETE or BLOCKED must not be rescheduled.
- Respect the maximum parallel task limit: [MAX_PARALLEL_TASKS].
- If a cycle is detected, flag it and stop sequencing. Do not produce a partial plan.
- If resource availability is insufficient for any ready task, flag the resource gap.

## OUTPUT SCHEMA
Return valid JSON with this structure:
{
  "plan_valid": true | false,
  "cycle_detected": true | false,
  "resource_gaps": ["string"],
  "sequenced_steps": [
    {
      "step": number,
      "task_id": "string",
      "depends_on": ["string"],
      "status": "READY" | "SCHEDULED" | "DEFERRED",
      "reason": "string"
    }
  ],
  "unblocked_tasks": ["string"],
  "blocked_tasks": ["string"]
}

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

If RISK_LEVEL is HIGH, include a human-review flag for any plan that defers more than [DEFERRAL_THRESHOLD] tasks.

To adapt this template, replace [INPUT] with your serialized task graph including task IDs, dependency lists, and status fields. [MAX_PARALLEL_TASKS] should reflect your actual worker pool size. [EXAMPLES] should include at least one normal case and one edge case with a dependency cycle so the model learns to detect and report it. [RISK_LEVEL] and [DEFERRAL_THRESHOLD] control whether the output includes a human-review flag—set RISK_LEVEL to HIGH for production pipelines where incorrect sequencing could cause data corruption or SLA violations. After receiving the model output, validate the JSON structure, confirm that no scheduled task has an incomplete upstream dependency, and check for false-positive cycle detection before dispatching tasks to your execution layer.

This prompt is designed to be a critical component within a multi-step AI pipeline orchestrator, not a standalone chat interface. The orchestrator is responsible for maintaining the source of truth for task states, dependency graphs, and resource availability. Before calling the LLM, the application must assemble a structured [TASK_MANIFEST] and [DEPENDENCY_GRAPH] from its internal state store. The prompt's output, a sequenced dispatch plan, is then parsed and used to update the orchestrator's scheduling queue. Directly exposing this prompt to end-users is an anti-pattern; it should be a silent, internal API call within your workflow engine.

The implementation harness must enforce a strict contract around the prompt's input and output. The [TASK_MANIFEST] should be a JSON array of task objects, each with a unique task_id, a status (e.g., PENDING, IN_PROGRESS, COMPLETED, FAILED), and an estimated_duration_seconds integer. The [DEPENDENCY_GRAPH] should be a JSON array of edges, each with a predecessor_id and successor_id. The application layer must validate these structures before prompt assembly. After receiving the model's response, the harness must parse the JSON output and run a Dependency Satisfaction Validator. This validator checks that for every dispatched task, all its upstream dependencies have a COMPLETED status in the current state store. Any dispatch plan that violates this constraint must be rejected, and the orchestrator should either retry the prompt with a specific error message or fall back to a deterministic scheduling algorithm.

For production resilience, implement a retry policy with a maximum of 2 attempts for malformed JSON or failed dependency validation. On the first failure, append the validation error to the prompt's [CONSTRAINTS] field and retry. If the second attempt also fails, log the full prompt, response, and validation errors to your observability platform and escalate to a human operator via a dead-letter queue. To prevent silent failures, integrate a Deadlock Detection Eval that runs asynchronously on the generated plan. This eval simulates the execution of the plan against the current state to detect circular waits where no tasks are eligible for dispatch. If a deadlock is detected, the orchestrator must halt the pipeline and alert the engineering team, as this indicates a critical flaw in either the dependency graph definition or the prompt's reasoning.

Model choice involves a trade-off between reasoning capability and latency. A capable mid-tier model is often sufficient for straightforward dependency trees, but complex graphs with nested dependencies and resource constraints may require a frontier model with advanced reasoning. To manage cost and latency, implement a Complexity Gate in the harness. Before calling the LLM, analyze the [DEPENDENCY_GRAPH] to count the number of nodes and the maximum depth of the dependency tree. Route simple graphs (e.g., fewer than 10 nodes, depth < 3) to a faster, cheaper model, and reserve the most capable model for complex sequencing problems. This routing decision should be logged as a trace attribute for cost attribution.