Wang Et Al 2025 Tdag

---
license: Apache-2.0
name: wang-et-al-2025-tdag
description: Architectural patterns for building agent systems that dynamically decompose complex tasks, generate specialized subagents just-in-time, and prevent cascading failures through adaptive replanning.
category: Research & Academic
tags:
  - tdag
  - task-decomposition
  - dag
  - llm-agents
  - planning
---

# SKILL: TDAG Dynamic Task Decomposition Framework

**Source**: TDAG: A Multi-Agent Framework based on Dynamic Task Decomposition and Agent Generation (Wang et al.)

**Description**: Architectural patterns for building agent systems that dynamically decompose complex tasks, generate specialized subagents just-in-time, and prevent cascading failures through adaptive replanning.

**Activate when**: Designing multi-agent systems, debugging cascading failures, evaluating complex task performance, managing agent context, or building systems with unpredictable subtask dependencies.

---

## DECISION POINTS

### Architecture Selection Decision Tree

```
IS your task multi-step with >5 sequential dependencies?
├─ NO  → Use single-agent ReAct (sufficient for simple tasks)
└─ YES → Are later steps dependent on earlier outcomes?
    ├─ NO  → Use static Plan-and-Execute (predictable workflow)
    └─ YES → DYNAMIC DECOMPOSITION required
        │
        ├─ Can you enumerate all possible subtask types upfront?
        │   ├─ YES → Pre-defined agent roles OK
        │   └─ NO  → Just-in-time agent generation required
        │
        ├─ Do agents need >20 tools or >10 info sources per subtask?
        │   ├─ NO  → Standard context provision
        │   └─ YES → Subtask-specific context refinement required
        │
        └─ Is task completion rate <40%?
            ├─ NO  → Binary evaluation sufficient
            └─ YES → Fine-grained subtask metrics required
```

### Failure Recovery Strategy Selection

| Failure Type | Detection Signal | Recovery Strategy |
|--------------|------------------|-------------------|
| Cascading Task Failure | Later subtasks fail with "invalid assumption" errors | STOP execution → Reassess from current state → Generate new decomposition |
| LLM Capability Limit | Model explicitly states inability or produces nonsensical output | Retry with simplified subtask OR delegate to human |
| External Info Misalignment | Correct tool used with wrong parameters | Regenerate subtask-specific tool documentation → Retry |
| Invalid State Constraint | Execution proceeds but violates user requirements | Backtrack to last valid state → Add constraint validation |

### Replanning Trigger Conditions

```
TRIGGER immediate replanning IF:
├─ Current subtask output contradicts assumptions in remaining planned subtasks
├─ External API returns unavailable/changed data that invalidates downstream plans
├─ User constraints discovered that weren't captured in original decomposition
├─ Two consecutive subtasks fail with same error type
└─ Execution time exceeds 2x estimated duration (indicates wrong approach)

DO NOT replan IF:
├─ Single subtask fails but downstream tasks remain valid
├─ Minor parameter adjustments can fix current subtask
├─ Failure is due to transient external service issues (retry first)
```

---

## FAILURE MODES

### Rubber Stamp Decomposition
**Detection**: Planning agent generates same 5-7 step template regardless of task specifics
**Symptom**: High Cascading Task Failure rates (>30%) because generic plans don't match actual task constraints
**Root Cause**: Static decomposition treats all tasks in domain as identical structure
**Fix**: Generate decomposition after analyzing current task's unique constraints and dependencies

### Schema Bloat Paralysis
**Detection**: Agents frequently select wrong tools despite having correct capabilities
**Symptom**: External Information Misalignment errors with messages like "used BookingAPI with FlightAPI parameters"
**Root Cause**: Providing all 50+ tools to every agent creates cognitive load in option filtering
**Fix**: Generate subtask-specific tool documentation containing only relevant 3-5 tools with enriched context

### Binary Evaluation Blindness
**Detection**: Two architectures show identical ~30% success rates but vastly different user satisfaction
**Symptom**: Cannot distinguish between "accomplished nothing" vs "completed 8/10 subtasks" failures
**Root Cause**: Pass/fail metrics hide incremental progress on complex tasks
**Fix**: Implement subtask-level completion tracking alongside binary outcomes

### Premature Skill Crystallization
**Detection**: Agent executes cached "successful" approaches that fail in current context
**Symptom**: High confidence execution of invalid solutions because they worked previously
**Root Cause**: Treating real-world skills like deterministic game strategies that work universally
**Fix**: Store skills with rich contextual metadata; validate preconditions before execution

### Agent Role Prison
**Detection**: System frequently hits "no suitable agent for this subtask" errors
**Symptom**: Forcing subtasks into predefined agent roles creates capability gaps
**Root Cause**: Pre-defining agent roles assumes complete knowledge of task space
**Fix**: Generate agents with roles derived from current subtask requirements, not organizational chart

---

## WORKED EXAMPLES

### Example 1: Hotel Booking Decomposition

**Initial Task**: "Book 3-night hotel in Tokyo for family of 4, budget $200/night, near Shibuya, check-in March 15"

**Static Approach (Plan-and-Execute) - FAILS**:
```
Planned Steps:
1. Search hotels near Shibuya
2. Filter by family rooms and budget
3. Select hotel with best rating
4. Book for March 15-18
5. Confirm booking

Execution Reality:
✓ Step 1: Found 15 hotels near Shibuya
✓ Step 2: 3 hotels meet criteria
✗ Step 3: Highest rated hotel selected (Hotel A)
✗ Step 4: Hotel A unavailable March 15-17 (but agent doesn't know this when planning)
✗ Step 5: Booking fails → CASCADE FAILURE
```
**Why it failed**: Steps 4-5 planned assuming Hotel A availability, but selection in Step 3 didn't check availability.

**TDAG Dynamic Approach - SUCCEEDS**:
```
Decompose: "Find available family hotels near Shibuya for March 15-18, budget $200/night"
│
├─ Generate SearchAgent with tools: [HotelSearch, AvailabilityCheck, DistanceCalculate]
├─ Execute: Returns 3 hotels with confirmed March 15-18 availability
├─ Current State: [Hotel X: $180/night available, Hotel Y: $195/night available, Hotel Z: $200/night available]
│
└─ Decompose: "Select optimal hotel from verified available options and complete booking"
    │
    ├─ Generate BookingAgent with tools: [HotelCompare, BookingSubmit, PaymentProcess]  
    ├─ Execute: Selects Hotel Y (best value), completes booking
    └─ Result: SUCCESS - Family room booked, $195/night, 2 blocks from Shibuya station
```

**Key Differences**:
- Static: Step 3 selection without availability check → cascade failure
- Dynamic: Availability verified before selection → no invalid assumptions
- Static: 5 predefined steps → rigid execution
- Dynamic: 2 state-dependent decompositions → adaptive to reality

### Example 2: Research Task with Context Management

**Task**: "Compare carbon footprint of train vs flight for Shanghai-Beijing route, including lifecycle emissions"

**Context Bloat Approach (Universal Agent) - FAILS**:
```
Agent receives full context:
- 50 transportation APIs (flight, train, bus, car, bike, boat)
- 30 emissions databases (lifecycle, operational, per-passenger, freight)
- 40 comparison frameworks (financial, time, comfort, environmental)
- 25 geographic tools (distances, routes, elevation, weather)

Error Pattern:
✗ Selects FlightEmissions API but passes train route parameters
✗ Uses LifecycleCarbon tool with BusTransport data format
✗ Compares per-passenger flight emissions with freight train emissions
```
**Failure Mode**: External Information Misalignment - correct tools, wrong parameters due to cognitive overload.

**TDAG Context Precision - SUCCEEDS**:
```
Decompose: "Gather Shanghai-Beijing transportation options and base emissions data"
│
├─ Generate TransportResearcher with refined tools:
│   - Tools: [ChinaRailAPI, DomesticFlightAPI, RouteDistance] (3 tools only)
│   - Context: "Focus on Shanghai-Beijing corridor, passenger transport only"
├─ Execute: Returns train options (4.5h, 120g CO2/km) and flight options (2h, 180g CO2/km)
├─ Current State: Base transport data confirmed for specific route
│
└─ Decompose: "Calculate lifecycle emissions for confirmed transport options"
    │
    ├─ Generate EmissionsAnalyst with refined tools:
    │   - Tools: [LifecycleTransport, InfrastructureCarbon, FuelUpstream] (3 tools only)
    │   - Context: Pre-populated with Shanghai-Beijing route data, passenger context
    ├─ Execute: Train lifecycle: 140g CO2/km, Flight lifecycle: 250g CO2/km
    └─ Result: SUCCESS - Comprehensive comparison with lifecycle methodology
```

**Trade-off Analysis**:
| Factor | Universal Agent | TDAG Context Precision |
|--------|-----------------|----------------------|
| Tool Selection Errors | High (7/10 attempts) | Low (1/10 attempts) |
| Context Relevance | 20% relevant | 95% relevant |
| Completion Time | 45 minutes (including retries) | 12 minutes |
| Result Accuracy | Partial/inconsistent | Complete/methodologically sound |

---

## QUALITY GATES

Task decomposition is complete when:

- [ ] **Replan Trigger Validation**: Each planned subtask includes explicit conditions that would trigger replanning (availability changes, constraint violations, assumption breaks)
- [ ] **Context Precision Check**: Each subagent receives ≤10 tools and all provided context directly relates to their specific subtask
- [ ] **State Dependency Mapping**: Later subtasks explicitly depend on actual outcomes (not predicted outcomes) of earlier subtasks
- [ ] **Failure Containment Design**: Single subtask failure cannot invalidate more than 1 downstream subtask without triggering decomposition reassessment
- [ ] **Progress Measurement**: System tracks subtask completion rates, not just binary task success, enabling partial progress visibility
- [ ] **Agent Role Justification**: Each generated agent's role and capabilities derive from specific current subtask needs, not generic organizational structure
- [ ] **Cascading Failure Prevention**: No subtask execution proceeds based on assumptions about previous subtasks that haven't been validated against actual results
- [ ] **Dynamic Adaptation Verification**: System demonstrates ability to change planned approach mid-execution when current state differs from initial assumptions
- [ ] **Error Category Classification**: Failures are categorized (CTF, LLM, EIM, ISC) to enable architectural improvement rather than just retry logic
- [ ] **Context Validation**: All information provided to agents has been verified as relevant and current for their immediate decision-making needs

---

## NOT-FOR BOUNDARIES

**Do NOT use TDAG patterns for**:
- **Single-step tasks**: Simple queries, direct API calls, straightforward transformations → Use basic ReAct instead
- **Deterministic workflows**: Code compilation, mathematical computation, rule-based validation → Static planning works fine
- **Real-time systems**: Live trading, autonomous vehicle control, emergency response → Latency of decomposition planning unacceptable
- **Highly stable domains**: Payroll processing, regulatory compliance, established manufacturing → Process optimization more valuable than flexibility
- **Resource-constrained environments**: Edge devices, strict API limits, minimal compute → Multiple agent overhead too expensive

**Delegate to other skills**:
- For **simple tool usage**: Use `function-calling-best-practices` instead
- For **prompt optimization**: Use `prompt-engineering-fundamentals` instead  
- For **single-agent debugging**: Use `llm-reasoning-optimization` instead
- For **deterministic planning**: Use `workflow-automation-patterns` instead
- For **real-time decision making**: Use `streaming-decision-systems` instead

**TDAG is specifically for**: Complex, multi-step tasks with uncertain subtask dependencies where early commitment to plans creates cascading failure risks and where adaptability matters more than execution efficiency.