Task Decomposition LLM Wiki

Task Decomposition

Break a complex objective into smaller work units that can be sequenced, assigned, executed, inspected, and recombined.

• Good task units have inputs, bounded operations, outputs, owners, acceptance signals, and dependencies.
• Use it when one prompt or one worker cannot reliably handle the whole objective.

Goal Decomposition

Split a desired end state into intermediate subgoals that preserve intent while making search, planning, or learning more tractable.

• Emphasizes states, constraints, milestones, and policies.
• Subgoals must compose into the original objective, not merely look locally useful.

Hierarchical Planning

Refine high-level intent into nested tasks, subgoals, methods, or policies. It bridges strategy and execution.

• Each layer needs assumptions, expected outputs, completion evidence, and an integration owner.
• Weak child-parent interfaces are the common failure point.

Multi-Agent Decomposition

Assign decomposed work to separate agents, roles, models, tools, or humans while coordinating dependencies and integration.

• Delegation needs objective, non-goals, inputs, output format, evidence, dependencies, and checks.
• The reducer evaluates evidence and resolves conflicts; it does not simply concatenate worker outputs.

Prompt Chaining

A sequential pattern where one prompt output becomes the next prompt input. Good for controlled transformations and staged checks.

• Works well for extraction, normalization, validation, critique, and revision.
• Becomes fragile when intermediate outputs are ambiguous or unchecked.

Cost-Aware Decomposition

Choose decomposition depth by balancing accuracy, latency, token cost, tool overhead, coordination work, and verification effort.

• Use deeper structure when errors are expensive or dependencies matter.
• Use lighter structure when the task is small, reversible, low risk, or mostly linear.

Verification and Governance

The checks, audit trail, schemas, and acceptance criteria that keep decomposed work aligned with the original objective.

• If a boundary has no verification signal, it is not yet a safe decomposition boundary.
• Validation belongs in the design, not only at the end.

Subgoal Graph

Represent intermediate states, dependencies, preconditions, and merge points when a linear list hides too much structure.

• Useful when some subgoals can run in parallel or merge later.
• A subgoal graph can generate tasks, but subgoals are not automatically tasks.

LLM Wiki Pattern

A maintained, linked Markdown corpus designed for both human reading and future LLM ingestion.

• Separate provenance from synthesis.
• Use stable slugs, backlinks, source cards, and structured data for regeneration.

Task Decomposition vs Goal Decomposition

Task decomposition asks what work units must be executed. Goal decomposition asks what intermediate states must become true.

Strategy Taxonomy

Choose the lightest strategy that exposes real dependencies, verification points, and integration risks.

• Linear chain: simple, but error-prone when outputs are unchecked.
• DAG: better for dependency management and parallelism.
• Hierarchy: useful for multiple abstraction levels.
• Subgoal graph: useful when state dependencies matter.

LLM Wiki vs RAG

A wiki stores curated, persistent synthesis. RAG assembles relevant source text at retrieval time. They can work together.

• Wiki risk: stale or over-compressed synthesis.
• RAG risk: retrieval misses, noisy chunks, context fragmentation.