| license | BSL-1.1 |
| name | dag-orchestrator |
| description | The intelligence layer of WinDAGs. Decomposes natural language tasks into Hierarchical Task DAGs (HTDAGs), matches subtasks to skills, executes waves in parallel, and dynamically expands nodes when complexity exceeds executor capability. Use for 'orchestrate', 'execute DAG', 'parallel agents', 'decompose task', 'coordinate skills'. NOT for single-skill tasks or simple linear workflows.
|
| allowed-tools | ["Read","Write","Edit","Bash","Task","TodoWrite","Grep","Glob"] |
| category | Agent & Orchestration |
| tags | ["dag","orchestration","task-decomposition","parallel-execution","htdag","adaptive-planning"] |
| io-contract | {"kind":"structured","inputSchema":"./schemas/input.json","outputSchema":"./schemas/output.json"} |
| metadata | {"recognition-cues":[],"expectancies":[],"decision-cues":[],"adaptive-workarounds":[],"execution-pattern":"sequential","needs-cdm":true} |
DAG Orchestrator
The beating heart of WinDAGs. Transforms arbitrary natural language tasks into parallelized agent graphs that execute in waves, adapting dynamically to task complexity and executor capabilities.
Decision Points
1. Initial Decomposition Strategy
Task Complexity Assessment:
├─ Single verb, single output file? → Use single-skill task
├─ 2-3 clear sequential steps? → Use linear workflow
├─ Multiple independent components? → Use parallel DAG
├─ Requires research phase? → Use phase orchestration
└─ Unclear requirements? → Start shallow, expand on failure
2. AND vs OR Composition Logic
Subtask Relationship Analysis:
├─ All must succeed for parent success? → AND composition
├─ Any success satisfies parent goal? → OR composition
├─ Primary approach with fallbacks? → Mixed (AND primary, OR fallbacks)
└─ Exploration of multiple options? → OR with confidence weighting
3. Max Depth Calibration
Task Complexity Heuristics:
├─ Simple CRUD operations? → max_depth = 2
├─ Feature development? → max_depth = 3
├─ System architecture? → max_depth = 4
├─ Research + implementation? → max_depth = 5
└─ If >5 levels needed → Use phase orchestration instead
4. Parallelization Safety Check
File Conflict Analysis:
├─ Predicted file overlap? → Force sequential execution
├─ Singleton operations (build/test)? → Isolate in separate wave
├─ Independent file modifications? → Safe to parallelize
└─ Database/config changes? → Serialize critical sections
5. Failure Recovery Strategy
Executor Failure Response:
├─ depth < max_depth? → Decompose failed node into sub-DAG
├─ depth >= max_depth? → Mark dependents as skipped, continue independents
├─ Critical path failure? → Halt DAG, report blocking issue
└─ Low confidence result? → Flag for review, continue with warnings
Failure Modes
Schema Bloat
Symptoms: DAG has >15 nodes in single level, execution takes >10 minutes
Detection: if nodeCount > 15 || estimatedTime > 600s
Fix: Group related subtasks into composite nodes, increase abstraction level
Circular Dependencies
Symptoms: Topological sort fails, "cyclic dependency" error in wave computation
Detection: if waves.length === 0 && nodes.length > 0
Fix: Identify cycle using DFS, break with intermediate artifact or merge conflicting nodes
Premature Parallelization
Symptoms: File conflicts, race conditions, inconsistent final state
:
: Add explicit dependencies, use sequential waves for conflicting operations
