Parallel Subtask Identification Prompt for Agent Workflows

This prompt is designed for orchestrator systems that have already decomposed a complex objective into a structured set of subtasks with defined inputs, outputs, and dependencies. Its job is to analyze that task graph and identify safe parallel execution groups. The ideal user is an AI engineer or agent architect who needs to reduce the wall-clock time of a workflow by running independent tasks concurrently, but who must avoid the race conditions and state corruption that come from naive parallelism. You should use this prompt when you have a dependency-aware task list and need a machine-readable plan for parallel execution, or when you are validating that a manually written parallel plan does not contain hidden conflicts.

The prompt requires a specific input shape: a list of subtasks where each task has a unique identifier, a description, and an explicit list of prerequisite task IDs. It outputs parallel execution groups—sets of task IDs that can run at the same time—along with safety annotations that flag shared-resource conflicts, such as two tasks writing to the same file or mutating the same database record. A concrete implementation should feed this prompt a validated task graph, parse the JSON output, and then use the groups to drive a concurrent executor. The harness must validate that no task appears in a group before its dependencies are completed in prior groups, and that tasks flagged with resource conflicts are either serialized or protected with application-level locks.

Do not use this prompt for initial task decomposition. It assumes the subtask list already exists. If you need to generate the subtask list from a high-level goal, start with the Dependency-Aware Task Decomposition Prompt in this content group. Also, avoid using this prompt for workflows where execution order is strictly linear by design, or where the overhead of managing concurrency outweighs the latency gains. For high-risk workflows—such as those mutating production infrastructure, financial ledgers, or patient records—always require a human to review the parallel execution plan before it is enacted, and ensure your harness logs the full task graph and parallel groups for auditability.

This prompt template is designed for an orchestrator agent that has already decomposed a complex objective into a set of subtasks. Its job is to analyze those subtasks for parallelism opportunities, marking each task as parallel-safe or sequential, and grouping them into execution waves. The output is a structured JSON object that a workflow engine can consume directly to minimize end-to-end latency without introducing race conditions.

textCopy
You are a task parallelism analyzer for an agent workflow engine. Your job is to examine a list of planned subtasks and determine which ones can execute concurrently without causing race conditions, data corruption, or dependency violations.

## INPUT

[PLAN_OBJECTIVE]

[SUBTASK_LIST]

[SHARED_RESOURCES]

## INSTRUCTIONS

1. For each subtask in [SUBTASK_LIST], identify:
   - The resources it reads from (immutable inputs).
   - The resources it writes to (mutable outputs).
   - Any explicit dependencies declared in the task definition.

2. Two subtasks can run in parallel ONLY if:
   - Neither writes to a resource the other reads or writes.
   - They have no transitive dependency relationship.
   - They do not share a mutable external system (e.g., a database table, a file, an API with rate limits) unless the operations are proven idempotent or commutative.

3. Group subtasks into execution waves, where all tasks in a wave can start simultaneously. A new wave begins only after all tasks in the previous wave are guaranteed to complete.

4. For any pair of tasks that appear parallel-safe but share a resource, add a `conflict_warning` explaining the risk and recommending a mitigation (e.g., a lock, a serialization gate, or a merge strategy).

## OUTPUT_SCHEMA

Return a valid JSON object with this structure:
{
  "objective": "string summarizing the plan",
  "parallelism_summary": {
    "total_subtasks": <int>,
    "parallel_safe_count": <int>,
    "sequential_only_count": <int>,
    "estimated_waves": <int>
  },
  "waves": [
    {
      "wave_id": <int>,
      "subtask_ids": ["<string>", ...],
      "execution_strategy": "parallel" | "sequential",
      "depends_on_waves": [<int>, ...]
    }
  ],
  "conflict_warnings": [
    {
      "subtask_a": "<string>",
      "subtask_b": "<string>",
      "shared_resource": "<string>",
      "risk_description": "<string>",
      "recommended_mitigation": "<string>"
    }
  ],
  "sequential_tasks": [
    {
      "subtask_id": "<string>",
      "reason": "<string explaining why it cannot be parallelized>"
    }
  ]
}

## CONSTRAINTS

- Do not invent dependencies that are not declared in [SUBTASK_LIST].
- If a task's resource access pattern is ambiguous, mark it as sequential and add a conflict_warning.
- If [SHARED_RESOURCES] specifies rate limits or mutability constraints, enforce them strictly.
- Do not parallelize tasks that modify the same database table, file, or API endpoint without a proven safe concurrency model.
- Prefer safety over maximum parallelism. A false parallel is worse than a missed parallel.

## EXAMPLES

[EXAMPLES]

## RISK_LEVEL

[RISK_LEVEL]

To adapt this template, replace the square-bracket placeholders with your specific context. [PLAN_OBJECTIVE] should be a one-line description of the overall goal. [SUBTASK_LIST] must be a structured array of task objects, each containing at minimum an id, a description, declared dependencies, and resource_access (reads/writes). [SHARED_RESOURCES] should enumerate mutable systems, rate limits, and concurrency constraints. [EXAMPLES] should include at least one correct parallel-safe grouping and one example of a false parallel that must be caught. [RISK_LEVEL] should be set to high if the workflow modifies production data, triggers financial transactions, or controls physical systems—in those cases, always route the output to a human reviewer before execution. For lower-risk workflows, you can feed the validated JSON directly into your execution engine, but ensure you have a validator that checks for cycles, missing dependencies, and conflicting resource access before any task is dispatched.

Integrating the parallel subtask identification prompt into an agent orchestrator requires treating the prompt output as a machine-readable plan, not just advisory text. The orchestrator should parse the JSON task groups, validate the parallel-safe markers against a known resource model, and then dispatch tasks to worker agents or tool executors. The primary integration points are: (1) a pre-execution validation step that rejects false parallelism, (2) a resource-locking mechanism that enforces the shared-resource conflict warnings the prompt produces, and (3) a monitoring layer that detects runtime race conditions the prompt may have missed. Without these harness components, a well-formed prompt output can still cause data corruption when two tasks write to the same file, database row, or API resource simultaneously.

Start by defining a resource registry that tracks mutable state your agents can access—file paths, database tables, API endpoints with side effects, in-memory caches, and configuration stores. Before dispatching any parallel group, the harness must intersect each task's declared resource access list (read/write) with every other task in the same group. If two tasks claim write access to the same resource, the harness should either serialize them, promote the conflict to a human reviewer, or reject the plan and request a revised decomposition. For high-risk workflows such as database migrations, infrastructure changes, or financial transactions, add a mandatory human approval gate that presents the parallel execution plan with resource conflict annotations before any task begins execution. Log every dispatch decision—which tasks ran in parallel, which were serialized due to conflicts, and which resource locks were acquired—so that post-execution audits can reconstruct the actual execution order.

Model choice matters here. Use a model with strong structured output support and a context window large enough to hold the full task list plus resource metadata. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are all suitable; avoid smaller models that may drop resource annotations or produce invalid JSON under task-list pressure. Set response_format to JSON mode or use function calling with a strict schema to enforce the output structure. Implement a retry loop with a maximum of 3 attempts: if the output fails JSON schema validation, return the validator error message to the model and request a corrected decomposition. If the output passes schema validation but contains resource conflicts the harness detects, do not retry automatically—log the conflict and either serialize the affected tasks or escalate. For orchestrators using tool-calling agents, expose a submit_parallel_plan tool that accepts the task groups and resource annotations, then runs the harness-side conflict checks before acknowledging the plan. This keeps the model's output contract tight and the safety checks in application code where they belong.

Testing this harness requires both unit-level schema validation and integration-level race condition detection. Build a test suite with known conflict scenarios: two tasks writing to the same key, a read task depending on a write task's output but placed in the same parallel group, and a task that accesses a resource not declared in the resource registry. For each scenario, assert that the harness either serializes the conflicting tasks or rejects the plan. In staging, run the full orchestrator against a sandboxed environment with instrumented resource access to catch race conditions the prompt's static analysis missed. Monitor production deployments for task groups where actual execution time exceeds the predicted parallel execution time by more than 2x—this often signals hidden resource contention or a missed dependency. Wire these signals into your observability dashboard alongside prompt version, model version, and plan rejection rate so you can correlate decomposition quality changes with prompt or model updates.