AI Automation / Task Orchestration
Identify which tasks can run simultaneously vs. sequentially — optimizes total workflow time.
Why This Prompt Exists
Sequential execution is simple but slow. Parallel execution is fast but complex. Most workflows run sequentially because designers don’t know what can be parallelized.
You get:
- workflows that take 10 minutes when they could take 2 minutes
- idle resources while waiting for unrelated tasks to finish
- no visibility into parallelization opportunities
- parallelization attempted incorrectly (race conditions, data conflicts)
- no way to estimate time savings from parallelization
But parallelization opportunities follow patterns:
- independent tasks: no data dependencies between them
- different data sources: each reads/writes different systems
- batch processing: same operation on many items (parallelize per item)
- fan-out: one task triggers multiple independent follow-ups
- fan-in: multiple independent tasks feed into one aggregator
Without parallelization, workflows are unnecessarily slow.
This prompt identifies parallel execution opportunities.
The Prompt
Assume the role of a workflow performance engineer who identifies parallelization opportunities.
Your task is to recommend which tasks can run in parallel.
Generate:
1. CURRENT SEQUENTIAL FLOW
- Task order (as currently designed)
- Estimated duration per task
2. PARALLELIZATION OPPORTUNITIES
| Task Group | Tasks | Why They Can Run in Parallel | Estimated Time Saved |
|------------|-------|------------------------------|---------------------|
| Group 1 | [Task A, Task B, Task C] | No data dependencies | [X seconds] |
| Group 2 | [Task D, Task E] | Read different systems | [X seconds] |
3. DEPENDENCY CHECK
- Verify that parallel tasks don't share:
* Write conflicts (both write to same record)
* Read-after-write (one reads what another writes)
* Resource limits (both hit same API rate limit)
4. PARALLEL EXECUTION BLUEPRINT
Sequential:
Task A (2s) → Task B (3s) → Task C (1s) → Task D (2s) = 8s
Parallel optimized:
Task A (2s) → [Task B (3s) + Task C (1s) + Task D (2s)] in parallel = 5s
Total time saved: 3s (37.5% faster)
5. RESOURCE CONSTRAINT CHECK
- Will parallel execution exceed API rate limits?
- Will it exhaust connection pools?
- Will it hit database lock limits?
6. IMPLEMENTATION RECOMMENDATIONS
- Which orchestrator features to use (e.g., parallel node in n8n, Promise.all in code)
- How to handle partial failures (one parallel task fails, others continue?)
INPUTS:
Current sequential task list (with durations if known):
[E.G., "1. Fetch CRM data (2s). 2. Fetch support tickets (3s). 3. Calculate SLA (1s). 4. Send report (2s)." ]
Data dependencies (from TO-01):
[E.G., "Task 3 needs Task 1 and Task 2. Task 4 needs Task 3. Tasks 1 and 2 have no dependencies on each other."]
API rate limits (if known):
[E.G., "CRM API: 10 requests/second. Support API: 5 requests/second."]
Infrastructure constraints:
[E.G., "Single database connection pool (max 10)"]
RULES:
- Tasks can run in parallel only if they have no data dependencies
- Tasks that write to the same database record cannot run in parallel (write conflicts)
- Tasks that hit the same API may need rate limit management in parallel
- Fan-out (one task → many parallel tasks) is common and safe
- Fan-in (many tasks → one aggregator) requires waiting for all to complete
- Partial failure handling: decide if failed parallel task fails the whole group
How To Use It
- Start with dependency map from TO-01 — tasks without dependencies are parallel candidates.
- Check for write conflicts: two tasks writing to the same record cannot run in parallel.
- Check API rate limits: parallel execution may exceed limits (add delays or queue).
- Fan-out patterns are safe (one task → many independent tasks).
- Fan-in patterns require waiting for all parallel tasks to complete.
Example Input
Current sequential task list:
“1. Fetch customer data from CRM (2s). 2. Fetch support tickets from Zendesk (3s). 3. Calculate customer health score (1s). 4. Send summary email (2s). 5. Update analytics dashboard (1s).”
Data dependencies:
“Task 3 needs Task 1 and Task 2. Task 4 needs Task 3. Task 5 needs Task 3. Tasks 1 and 2 are independent. Tasks 4 and 5 are independent (both need Task 3, not each other).”
API rate limits:
“CRM: 10 req/s, Zendesk: 5 req/s”
Why It Works
Most workflow designers default to sequential execution — it’s simpler — but leaves massive performance gains on the table.
This framework improves outcomes by forcing:
- parallelization opportunity identification (what can run together?)
- dependency verification (are they truly independent?)
- time savings calculation (quantify the benefit)
- resource constraint checking (won’t break rate limits)
- implementation guidance (how to actually parallelize)
Failure modes this prevents:
- Write conflicts — two tasks updating same record (data corruption)
- Read-after-write — one task reads what another is writing (stale data)
- Rate limit exhaustion — parallel calls exceed API limits (429 errors)
- Connection pool exhaustion — too many parallel database connections
This improves on: Sequential-only workflow design. Parallel execution can cut runtime by 50-80% with no hardware changes.
Related to: TO-01 (Dependencies) — prerequisite; TO-04 (Recovery) — handling parallel task failures.
Build Better AI Systems
Subscribe for advanced prompt engineering, AI coding tools, debugging frameworks, and practical strategies for developers and engineers.