What is hierarchical task decomposition and what failure mode does flat planning expose?
Define hierarchical task decomposition in the context of an LLM agent. What problem does it solve that flat (non-hierarchical) planning cannot handle well?
Hierarchical decomposition splits a goal into a recursive sub-goal tree so each tier reasons at one abstraction level. Flat planning forces strategy and tool syntax into one confused context.
Imagine planning a big dinner party alone. If you try to hold the whole thing in your head at once, the guest list, the menu, the shopping, and the exact stove temperature all blur together. You forget why you were chopping onions in the first place. It is easier to think in layers. First decide the theme. Then pick the dishes. Only then worry about which knife to grab. An agent does the same. A flat plan asks the model to handle the grand strategy and the tiny details at the same time, and it gets confused. A hierarchical plan lets a planner think about the big picture and hand each piece down to a helper. The helper handles the small details without ever losing track of the overall goal.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Hierarchical task decomposition is the practice of converting a high-level goal into a recursive tree of sub-goals. Each node can be split further until the leaves are concrete tool calls. The root is the overall objective. The leaves are the actions that touch the world. Between them sit intermediate sub-goals that exist purely to organize reasoning.
The core promise is that the agent reasons at one abstraction level per tier. Strategy lives at the root, tactics in the middle, operations at the leaves. This mirrors how a well-structured program keeps low-level detail out of a high-level function. The idea is old. Hierarchical task networks formalized it decades before LLMs existed. What changed is the implementation. Instead of a formal planner with hand-written operators, a language model proposes the split. The engineering lives in prompts and context management rather than in search algorithms.
The hard part is not the definition, which is easy, but the engineering. It covers how dependencies between sub-goals are modeled, who performs the decomposition, and when the plan should be revised. It also covers why an error at the top of the tree is so much more damaging than an error at a leaf. Decomposition is a design space with explicit tradeoffs, not a single technique that is always on.
The task tree and its abstraction tiers
A decomposition is a tree, not a flat list. The root is the user's goal. Internal nodes are sub-goals. Leaves are tool calls that actually execute. Recursion is the defining property. Any node too coarse to execute directly is split into children, and the process repeats until every leaf is concrete enough to run.
The tiers carry distinct kinds of reasoning. Strategic reasoning at the root asks what should be accomplished and in what broad order. Tactical reasoning in the middle asks how to approach a given sub-goal. Operational reasoning at the leaves asks which exact tool to call and with which arguments.
Keeping these separate is the main purpose. A planner thinking about strategy should not be distracted by argument formatting. An executor formatting a tool call should not have to re-derive the project strategy. This separation of concerns is the agent analogue of function decomposition. There, a high-level function delegates detail to helpers rather than inlining everything into one block.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- Devin and similar coding agents decompose a feature request into a plan, then into per-file edits, then into individual tool calls. They expand lower tiers only as earlier steps complete.
- Claude Opus 4.7 in agentic coding mode writes a high-level plan first, executes sub-steps, and revises the plan when a test failure invalidates an earlier assumption.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow do you decide between static decomposition up front and interleaved decomposition that expands nodes on demand?
Weigh predictability against adaptivity. Static plans are cheap and auditable but brittle to surprises. Interleaved plans expand a node only when reached, adapting to observations at the cost of more planning calls. Use static when the path is knowable, interleaved when leaves return information that reshapes the tree.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Describing decomposition as a flat checklist of steps. The point is recursion into abstraction tiers, not a longer to-do list. A bad top-level split caps every result below it.
60 second bullets to scan on the way to the call.
Define decomposition as a recursive sub-goal tree, not a flat step list.
Name the strategic, tactical, and operational tiers and what each one decides.
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.