hypertree-planning

license	Apache-2.0
name	hypertree-planning
description	Hypertree decomposition approach to planning problems for reduced computational complexity
category	Research & Academic
tags	["hypertree","planning","decomposition","constraint-solving","width"]
io-contract	{"kind":"none"}
metadata	{"recognition-cues":[],"expectancies":[],"decision-cues":[],"adaptive-workarounds":[],"execution-pattern":"sequential","needs-cdm":true}

SKILL.md: HyperTree Planning

license: Apache-2.0

Metadata

• Name: hypertree-planning
• Source: "HyperTree Planning: Enhancing LLM Reasoning via Hierarchical Thinking" (Gui et al., 2024)
• Domain: Complex reasoning, multi-step planning, agent architecture
• Triggers:
  • Planning tasks with 50+ reasoning steps
  • Problems requiring multiple independent constraints
  • Multi-domain coordination (e.g., travel planning, logistics)
  • Failures in chain-of-thought or tree-based approaches
  • Agent systems struggling with task decomposition
  • Questions about "how to break this down" or "what's the structure?"

When to Use This Skill

Load this skill when facing:

1. Structural Complexity: The problem requires coordinating multiple independent sub-tasks (e.g., travel itinerary = transportation + accommodation + dining + attractions)

2. Reasoning Chain Length: Linear approaches fail because sequential reasoning exceeds ~30 steps, leading to error accumulation or context loss

3. Constraint Diversity: Multiple distinct constraints that should be handled separately rather than in one monolithic chain (budget, time, preferences, regulations)

4. Planning vs. Execution Gap: Need to separate "what structure should I use?" from "what are the details?" to avoid premature commitment

5. Generalization Failures: Example-based approaches fail because examples don't match current problem structure, or you need a principle-based decomposition strategy

Anti-indicator: Simple sequential tasks, single-constraint optimization, or problems where exploration of alternatives (not decomposition) is the bottleneck.

Core Mental Models

1. Hierarchical Decomposition as Cognitive Architecture

The Insight: Complex reasoning fails not from insufficient search but from structural mismatch between problem complexity and reasoning organization.

• Chain-of-Thought: Sequential reasoning that treats all steps as one monolithic chain → becomes unwieldy when constraints diversify or reasoning exceeds ~30 steps
• Tree-of-Thought: Parallel exploration of competing alternatives for the same task → doesn't reduce reasoning depth, just explores more paths at the same level
• HyperTree: Multi-level divide-and-conquer where each node can spawn multiple independent branches that themselves decompose → reduces effective reasoning depth while maintaining separation of concerns

Key Principle: A hypertree's edges connect to sets of nodes (hyperlinks), not single nodes. This represents true hierarchical thinking: "To plan travel [parent], I independently handle {transportation, lodging, dining, attractions} [child set], each of which further decomposes."

Practical Impact: On tasks with 60+ step chains (TravelPlanner), HyperTree shows 2.8× improvement vs. 1.3-1.8× on simpler 30-step tasks. The benefit scales with structural complexity, not just problem difficulty.

2. Rules as Generalized Decomposition Knowledge

The Problem with Examples: In-context learning relies on example-query structure matching. When your planning problem doesn't resemble the examples, performance degrades catastrophically.

The Alternative: Abstract decomposition rules that define task-general patterns:

[Plan] -> {[Transportation], [Accommodation], [Attractions], [Dining]}
[Transportation] -> {{specific segments based on cities}}
[segment] -> {[Self-driving], [Taxi], [Flight]}

Why This Matters:

• Rules generalize across problem instances (no example-query mismatch)
• Rules encode domain knowledge about task structure (not specific solutions)
• Rules enable automatic outline construction without human intervention per instance
• Rules separate "how to decompose" from "what the answer is"

The Trade-off: Rules require upfront task analysis to identify decomposition patterns, but eliminate ongoing need for curated examples and enable true zero-shot structural reasoning.

3. Planning Outline as Executable Structure

The Two-Phase Architecture:

1. Structure Phase: Generate planning outline (hypertree skeleton) that encodes decomposition strategy
2. Content Phase: Fill in details at leaf nodes guided by the outline structure

Why Separation Matters:

• Prevents premature detail commitment (deciding on specific flights before determining which cities to visit)
• Provides coordination mechanism (outline ensures all sub-tasks get addressed)
• Enables iterative refinement (can revise structure before expensive detail work)
• Mirrors human planning cognition (decide "what needs handling" before "how to handle it")

Empirical Validation: Removing hierarchical division drops success from 20.0% to 6.1% (3.3× degradation), while removing selection/decision modules has smaller impact. The structure carries most of the reasoning power.

4. Cognitive Cost of Reasoning Chain Length

The Core Finding: Error accumulation in sequential reasoning is the primary failure mode, not suboptimal path selection.

The Math: If each reasoning step has error rate ε, a chain of length n has cumulative error ~1-(1-ε)^n. At n=60 with ε=0.02, cumulative error ≈70%.

The Hierarchical Solution: Decompose 60-step chain into 3 levels with branching factor 4 → max depth becomes log₄(60)≈3 levels. Each branch independently solves a simpler problem.

Design Implication: When reasoning chains exceed 30-40 steps, invest in structural decomposition before trying better search/selection. The benefit compounds exponentially with chain length.

5. Coordination Without Central Control

Traditional Multi-Agent Problem: Centralized coordination (controller agent) creates bottlenecks and single points of failure. Decentralized coordination requires complex communication protocols.

HyperTree Solution: The decomposition rules and outline structure provide implicit coordination:

• Each sub-task branch knows its scope (defined by parent decomposition)
• Independence between branches encoded in hypertree structure
• No explicit message-passing needed
• Leaf nodes naturally integrate results when structure merges back up

The Principle: Coordination emerges from shared structural understanding, not from explicit control or communication. The outline is simultaneously a reasoning scaffold and a coordination protocol.

Decision Frameworks

When facing a complex planning task:

IF reasoning chain length > 30-40 steps
THEN consider hierarchical decomposition before investing in better search/selection

IF problem involves multiple independent constraints or domains
THEN use hypertree structure to separate concerns into parallel branches

IF examples don't match current problem structure
THEN shift from example-based ICL to rule-based decomposition

IF premature detail commitment causes backtracking
THEN separate outline generation (structure) from plan execution (content)

IF multi-agent system has coordination bottlenecks
THEN use shared decomposition rules as implicit coordination mechanism

When designing decomposition rules:

IF sub-tasks can be solved independently
THEN decompose into parallel branches (hyperlink structure)

IF sub-task requires sequential dependencies
THEN use nested decomposition within that branch (don't force parallelism)

IF task is knowledge-intensive
THEN combine outline generation with iterative refinement at leaf nodes

IF task has variable structure across instances
THEN make rules parameterized (e.g., "decompose by cities" where city list varies)

When diagnosing reasoning failures:

IF failure occurs late in reasoning chain
THEN likely error accumulation → reduce effective depth via decomposition

IF constraints conflict or get ignored
THEN likely monolithic reasoning → separate constraints into independent branches

IF system generates plans that ignore some requirements
THEN outline may be incomplete → revise decomposition rules to ensure coverage

IF performance degrades on novel problem instances
THEN likely example-query mismatch → shift to rule-based generalization

Reference Documentation

File	When to Load
hierarchical-thinking-through-hypertree-structures.md	Need deep understanding of hypertree formalism, construction algorithms, or theoretical foundations. Covers: hypergraph theory, top-down construction, self-guided planning process, comparison to chains/trees.
decomposition-rules-as-generalized-knowledge.md	Designing decomposition rules for new domains, troubleshooting rule-based systems, or understanding generalization mechanisms. Covers: rule structure, example vs. rule trade-offs, automatic outline construction, zero-shot transfer.
cognitive-cost-of-reasoning-chain-length.md	Analyzing why sequential reasoning fails, calculating error accumulation, or justifying hierarchical approaches. Covers: mathematical analysis of chain length, empirical correlation with failure rates, depth reduction via decomposition.
coordination-without-central-control.md	Building multi-agent systems, addressing coordination bottlenecks, or designing emergent orchestration. Covers: implicit coordination via structure, comparison to traditional multi-agent architectures, shared decomposition knowledge.
failure-modes-in-complex-reasoning-systems.md	Debugging reasoning failures, conducting ablation studies, or understanding performance degradation. Covers: taxonomy of failure modes, ablation results, impact of removing components, task-specific failure patterns.
the-gap-between-planning-and-execution.md	Designing two-phase architectures, avoiding premature commitment, or separating structure from content. Covers: outline vs. execution distinction, iterative refinement process, cognitive architecture implications.
adaptation-through-rule-generalization.md	Enabling agent adaptation, addressing generalization challenges, or moving beyond example-driven learning. Covers: rule-based generalization mechanisms, cross-domain transfer, meta-learning implications.

Anti-Patterns

1. Premature Detail Commitment

Manifestation: Selecting specific solutions (e.g., which flight to book) before establishing overall structure (e.g., which cities to visit)
Why It Fails: Creates cascading revisions when structure changes, wastes computation on details that may become irrelevant
The Fix: Always generate outline first, then fill in leaf node details

2. Forced Sequential Reasoning

Manifestation: Treating all steps as one long chain when sub-tasks are actually independent
Why It Fails: Error accumulation compounds, context window fills with irrelevant details, loses track of constraints
The Fix: Identify independent sub-tasks and decompose into parallel branches

3. Example Dependency

Manifestation: Curating extensive example sets and expecting generalization to structurally different problems
Why It Fails: Example-query mismatch causes catastrophic performance drops, examples encode specific solutions not general patterns
The Fix: Extract abstract decomposition rules from examples, use rules as primary reasoning mechanism

4. Treating Trees as Hypertrees

Manifestation: Using tree exploration (ToT, MCTS) but connecting edges to single child nodes, not sets
Why It Fails: Doesn't enable true hierarchical decomposition, explores competing alternatives instead of independent sub-tasks
The Fix: Use hyperlinks that connect parent to sets of children, representing parallel independent branches

5. Neglecting Outline Iteration

Manifestation: Generating outline once and rigidly executing it, even when knowledge discovery reveals structural issues
Why It Fails: Real planning requires feedback between structure and content discovery (learning about constraints may require re-decomposition)
The Fix: Enable iterative refinement of outline, especially for knowledge-intensive tasks

6. Over-Centralized Multi-Agent Coordination

Manifestation: Creating "manager" agents that bottleneck all coordination through explicit control
Why It Fails: Single point of failure, communication overhead, manager must understand all sub-task details
The Fix: Use shared decomposition structure as implicit coordination mechanism

7. Ignoring Chain Length as Diagnostic

Manifestation: Treating all reasoning failures as "need better model" or "need more search"
Why It Fails: Misses that failures cluster at reasoning chains >30-40 steps, indicating structural issue not capability issue
The Fix: Measure reasoning chain length, use as indicator for when hierarchical decomposition is needed

Shibboleths: Distinguishing Deep Understanding from Surface Knowledge

Someone who truly understands HyperTree Planning will:

1. Recognize hypertree structure in natural planning: When hearing about complex projects, they spontaneously identify hyperlinks ("handling those three constraints independently") vs. sequential steps vs. alternatives.

2. Distinguish decomposition from exploration: They understand that tree-of-thought explores competing alternatives for the same task, while hypertrees decompose into independent sub-tasks—and can articulate why this difference matters for reasoning depth.

3. Calculate cognitive cost: When analyzing reasoning failures, they estimate chain length and error accumulation, recognizing that a 60-step chain with 2% per-step error rate yields ~70% cumulative failure.

4. Design rules, not examples: When adapting to new domains, their first instinct is "what are the decomposition patterns?" not "what are good examples?" They can articulate the generalization advantage of rules.

5. Separate structure from content: They naturally distinguish "what's the outline?" from "what are the details?" and understand when to iterate on structure vs. when to execute on fixed structure.

6. See coordination as emergent: In multi-agent contexts, they design shared decomposition knowledge rather than communication protocols, understanding that structure encodes coordination.

7. Identify structural mismatch: When debugging, they ask "does the reasoning structure match the problem structure?" rather than immediately trying more search or better prompts.

Surface-level understanding reveals itself through:

• Treating HTP as "just another search algorithm" (missing the structural decomposition insight)
• Describing it as "better tree-of-thought" (conflating exploration with decomposition)
• Focusing on the specific TravelPlanner results (missing the general principle about chain length and structure)
• Proposing to add HTP as one more tool in an ensemble (missing that it's an architectural principle, not a technique)
• Discussing "prompts for decomposition" without understanding rule-based generalization
• Treating outline generation as optional pre-processing rather than fundamental cognitive architecture

The deepest understanding shows in:

Seeing cross-domain implications: Recognizing that the principle applies beyond LLM planning—to organizational design (hierarchical teams), software architecture (microservices), project management (work breakdown structures), and cognitive science (hierarchical motor control). The insight is about how complex systems manage complexity through structural decomposition, not just about how to make LLMs plan better.

Understanding the fundamental trade-off: Hierarchical decomposition assumes sub-tasks can be made independent. When they're inherently coupled (e.g., combinatorial optimization where every decision affects every other), forcing hierarchical structure can be counterproductive. True mastery means knowing when decomposition works and when you need different approaches (constraint satisfaction, global optimization, etc.).