Task Decomposer

Breaks natural-language problems into sub-tasks suitable for DAG nodes. The first step of the meta-DAG: before you can build or execute a DAG, you need to understand what the pieces are.

When to Use

✅ Use for:

• Breaking a vague problem into concrete sub-tasks

• Identifying phases, dependencies, and parallelization opportunities

• Determining which sub-tasks are concrete vs. vague (pluripotent)

• Selecting the appropriate domain meta-skill for decomposition

❌ NOT for:

• Building the DAG structure from sub-tasks (use dag-planner )

• Executing the tasks (use dag-runtime )

• Assigning skills to tasks (use dag-skills-matcher )

Decomposition Process

flowchart TD P[Problem description] --> M{Domain meta-skill available?} M -->|Yes| L[Load meta-skill phase pattern] M -->|No| R{Research needed?} R -->|Yes| RA[Research standard decomposition] R -->|No| Z[Zero-shot decomposition]

L --> D[Apply phase pattern to problem] RA --> D Z --> D

D --> C[Identify concrete sub-tasks] D --> V[Identify vague/pluripotent sub-tasks] D --> DEP[Map dependencies between sub-tasks] D --> PAR[Identify parallelization opportunities]

C --> O[Ordered sub-task list with metadata] V --> O DEP --> O PAR --> O

Step 1: Domain Detection

Classify the problem into a domain to select the right meta-skill:

Domain Signals Meta-Skill

"build", "implement", "code", "app", "website" software-project-decomposition

"research", "analyze", "report", "synthesize" research-synthesis-decomposition

"design", "UI", "wireframe", "prototype" product-design-decomposition

"strategy", "market", "business", "revenue" business-strategy-decomposition

"data", "model", "train", "predict" ml-project-decomposition

If no meta-skill matches, fall back to zero-shot decomposition.

Step 2: Phase Identification

Apply the meta-skill's phase pattern. Not all phases apply to every problem.

Decision: For each phase in the pattern, ask: "Does this problem need this phase?"

• Yes, and I can specify it now → Concrete sub-task

• Yes, but I can't specify it until prior phases complete → Vague/pluripotent node

• No → Skip this phase

Step 3: Sub-Task Specification

For each concrete sub-task:

sub_task: id: unique-name description: "What this sub-task produces (1-2 sentences)" type: concrete | vague depends_on: [upstream-sub-task-ids] parallelizable_with: [sibling-sub-task-ids] estimated_complexity: simple | moderate | complex suggested_model_tier: 1 | 2 | 3 suggested_skills: [skill-names if known] output_description: "What the output looks like"

For each vague/pluripotent sub-task:

sub_task: id: unique-name description: "What this phase will address (1-2 sentences)" type: vague depends_on: [upstream-sub-task-ids] potential_paths: - "Path A: [exciting possibility 1]" - "Path B: [exciting possibility 2]" - "Path C: [exciting possibility 3]" expansion_trigger: on_upstream_complete

Step 4: Dependency Mapping

For each pair of sub-tasks, determine:

• Data dependency: Does B need A's output? → Edge from A to B

• Knowledge dependency: Does B need to know what A discovered? → Edge from A to B

• No dependency: A and B are independent → Parallelizable

Step 5: Output

Produce a structured decomposition:

decomposition: problem: "original problem description" domain: "detected domain" meta_skill_used: "meta-skill name or 'zero-shot'" phases: - phase: 1 sub_tasks: [concrete tasks for this phase] - phase: 2 sub_tasks: [mix of concrete and vague tasks] total_concrete: 5 total_vague: 3 estimated_waves: 4 estimated_cost: "$0.08 - $0.25"

Decomposition Heuristics

Granularity

• Too fine: "Step 1: Open the file. Step 2: Read line 1." → Merge into one node

• Too coarse: "Step 1: Build the entire app." → Split into design, implement, test, deploy

• Right: Each sub-task is completable by one agent with 1-3 skills in one LLM call

Dependency Minimization

Fewer dependencies = more parallelism = faster execution. Prefer:

• Independent parallel tracks over long sequential chains

• Fan-out patterns (one source, many consumers) over daisy chains

• Late merging (combine results at the end, not incrementally)

Vagueness is OK

Don't force specificity where it doesn't exist yet. A vague node saying "Build the solution (details TBD after design phase)" is more honest and more useful than a fake-specific node that will be wrong.

Anti-Patterns

Premature Specificity

Wrong: Specifying exact implementation details for phases that depend on undone research. Right: Mark dependent phases as vague/pluripotent. Show potential paths.

Sequential Everything

Wrong: A linear chain of 10 tasks with no parallelism. Right: Look for independent tracks. Research and content writing can often happen in parallel.

Missing the Meta-Skill

Wrong: Decomposing a bridge design project like a software project. Right: Detect the domain, load the appropriate meta-skill, follow its phase pattern.