LLM Agent Planning: Does Hierarchical Decomposition Improve Web Task Success?

LLM-based web agents are expected to complete multi-step tasks such as filling forms, navigating menus, and completing purchases. Existing evaluations of these agents focus primarily on end-to-end success, offering limited insight into where failures arise [1]. This matters because a single success or failure number cannot tell a builder whether a task failed due to bad planning, bad execution, or a failure to notice and correct mistakes. A team deciding whether to invest engineering effort in a hierarchical planner needs to know whether that layer is actually where failures concentrate, or whether the effort would be better spent elsewhere.

One analysis frames LLM-based web agents as needing three core capabilities: high-level planning, low-level execution, and replanning [1]. It analyzes web agents across these same three layers: high-level planning, low-level execution, and replanning [1]. This framework is useful because it separates deciding what to do from doing it correctly and from noticing something went wrong and adjusting. The research question above, does hierarchical decomposition beat flat planning, sits inside this framework: decomposition is a way of structuring the planning layer, but the analysis suggests the planning layer may not be where most failures happen.

Several other systems described below build agents that decompose tasks, observations, or plans in different ways, and report improvements against their own prior baselines. None of these systems set out to test decomposition against a flat-planning control condition; they compare a new decomposed method against a prior method or prior state of the art. That distinction is central to reading the numbers correctly in this note, and it explains why the direct answer above is cautious rather than definitive.

Because the field currently measures success mainly at the end-to-end level, any claim that decomposition itself, isolated from other changes such as new prompts, new retrieval, or new tools, causes a given improvement is an inference from indirect evidence, not a demonstrated fact. This note keeps that distinction visible throughout, marking which numbers come from which comparison and refusing to merge them.

The claims describe several different things under the umbrella of decomposition, and they are not the same mechanism. CoAct transfers the hierarchical planning and collaboration patterns in human society to LLM systems [2], and does so through a global planning agent and a local execution agent [2]. This is decomposition of roles: one agent plans, another executes, and the two coordinate rather than a single model doing both jobs.

WebAgent instead plans ahead by decomposing instructions into canonical sub-instructions [5]. This is decomposition of the instruction itself into smaller, standardized steps, rather than a split between separate planning and execution agents. The instruction is broken down before any agent role distinction is introduced, so the decomposition happens earlier in the pipeline than in CoAct's role-based approach.

RaDA disentangles planning into two stages: Retrieval-augmented Task Decomposition and Retrieval-augmented Action Generation [8], and it does not require manual exemplars [8]. This is decomposition of the planning process into two sequential stages, each aided by retrieval, so the decomposition is internal to a single planning pipeline rather than split across separate agents or expressed as canonical sub-instructions.

Region4Web reorganizes the AXTree into functional regions through hierarchical decomposition and semantic abstraction [3]. This is decomposition of the observation space, not of the plan or the agent roles; it changes what the agent sees, not how it plans. Structured Planning Domain Definition Language (PDDL) plans produce more concise and goal-directed strategies than natural language (NL) plans [1], which is a different kind of structuring again, using a formal planning language rather than free text, rather than splitting a task, a role, or an observation into parts.

Because these are four or five distinct mechanisms, role-splitting, instruction-splitting, stage-splitting, observation-splitting, and language-formalization, reported gains from one cannot be assumed to transfer to another, and none of the claims test them against each other directly. A reader who wants to know whether decomposition works must first ask which of these mechanisms is meant, since the claims never treat them as interchangeable and never report a shared benchmark across all of them.

Region4Web reorganizes the AXTree into functional regions through hierarchical decomposition and semantic abstraction [3]. PageDigest, built on this reorganization, delivers region-level observation to the actor agent as a compact per-page digest that persists across steps [3]. This is a case where decomposition is applied to what the agent perceives on a page, rather than to the plan the agent forms or the roles agents play. It is a different point of intervention in the pipeline from CoAct's role split, WebAgent's instruction split, or RaDA's stage split, and it is worth treating separately because it targets the input side of the agent rather than the reasoning or execution side.

PageDigest substantially reduces observation length while improving overall task success rate across diverse backbone LLMs and established agent methods on WebArena [3]. This single claim reports two effects together: a shorter observation and a higher success rate, measured across multiple backbone LLMs and multiple existing agent methods, all on WebArena. No exact percentage figures are given in the claim, so the size of the improvement and the size of the length reduction cannot be quoted precisely here; only the direction and the benchmark are known from the claim as stated.

This result broadens the picture of where decomposition can help: it is not only about splitting plans or roles, but about splitting and compressing what the agent observes at each step, which can matter as much as how it reasons about the next action. Since the claim describes the effect as holding across diverse backbone LLMs and across established agent methods, it suggests the observation-level decomposition is not tied to one specific model or one specific planning method, though the claim does not name which backbones or which established methods were tested, so the breadth of that generality cannot be verified beyond what is stated.

Because this decomposition happens at the observation layer, it is logically separable from the planning-layer question this note is centered on. A builder could, in principle, combine PageDigest's observation reorganization with either a flat planner or a hierarchical planner, and the claims do not report which combination was actually tested, or whether the improvement depends on pairing it with a particular kind of planner.

The hierarchical planning perspective in claim source [1] singles out low-level execution as the dominant bottleneck in current LLM web agents [1]. This is stated after distinguishing three layers, planning, execution, replanning, and it means that even when the plan itself is sound, agents still fail more often while carrying out individual steps than while deciding what those steps should be. This is a central fact for the research question, because it implies that changes made only to the planning layer, including hierarchical decomposition of that layer, may not address the layer where most failures occur.

The same source argues that improving perceptual grounding and adaptive control, not only high-level reasoning, is critical for achieving human-level reliability [1]. This connects directly to the execution-bottleneck finding: if execution is where most failures happen, then better grounding, correctly identifying what is on the page, and better control, correctly acting on it, address the actual bottleneck, whereas refining the high-level plan does not. Grounding and control sit inside the execution layer of the three-layer framework, so this statement reinforces rather than adds a new claim to the bottleneck finding.

Read together, these two findings put weight on the idea that hierarchical decomposition of the planning layer, by itself, may not be the lever that most improves success rate, because the planning layer is not where most of the failures the source identifies occur. This does not mean decomposition is useless; it means the source claims do not show that decomposition targets the dominant failure mode they identify.

None of the decomposition systems described elsewhere in this note directly measure whether their gains come from better execution, better planning, or better replanning; they report only overall success-rate changes. This is an evidentiary gap rather than a contradiction: it is possible that CoAct, WebAgent, RaDA, SkillWeaver, or Region4Web improve success partly by improving execution or replanning as a side effect of their design, but the claims as given do not decompose their reported numbers into these components, so no such attribution can be made here.

CoAct achieves superior performance over baseline methods on long-horizon web tasks on the WebArena benchmark [2]; the claim does not give a numeric margin, so only the direction of the result, better than baseline methods, and the task type, long-horizon web tasks, and the benchmark, WebArena, are known. WebAgent's modular recipe improves success on real websites by over 50% [5], and separately, HTML-T5, part of the same WebAgent work, achieves 18.7% higher success rate than the prior method on the MiniWoB web automation benchmark [5], and achieves state-of-the-art performance on Mind2Web [5]. These are three separate numbers from three separate benchmarks, real websites, MiniWoB, Mind2Web, inside the same paper; they should not be added together or treated as one unified pipeline gain, since each figure describes a different task setting and a different comparison baseline. The over 50% figure is a real-website result tied to the modular recipe specifically, the 18.7% figure is a MiniWoB result tied to HTML-T5 specifically compared against a named prior method, and the Mind2Web result is stated only as state-of-the-art, without a numeric margin given.

SkillWeaver reports relative success rate improvements of 31.8% on WebArena [6] and 39.8% on real-world websites [6], and reports that APIs synthesized by strong agents enhance weaker agents, yielding improvements of up to 54.3% on WebArena [6]. These three SkillWeaver numbers come from the same framework but from three different comparisons: its own baseline on WebArena, its own baseline on real websites, and a cross-agent transfer setting also on WebArena where a weaker agent benefits from APIs made by a stronger agent. The 54.3% figure is described as an upper bound, up to 54.3%, so it should not be read as a typical or average improvement; it is a maximum observed under the cross-agent transfer condition.

AdaPlanner outperforms state-of-the-art baselines by 4.11% on MiniWoB++ [7], and does so by allowing the LLM agent to refine its self-generated plan adaptively in response to environmental feedback [7], a replanning mechanism, not a decomposition mechanism as this note has been using the term. RaDA finds consistent improvements over previous SOTA in CompWoB and Mind2Web [8], again without a stated numeric margin, only the direction, consistent improvement, and the two benchmarks, CompWoB and Mind2Web, are given.

None of these six results share a common benchmark and baseline with each other in a way that would let a reader build a ranking across CoAct, WebAgent, SkillWeaver, AdaPlanner, and RaDA from these claims alone. WebArena appears in CoAct, SkillWeaver, and Region4Web results, which is the closest overlap among the cited work, but even within WebArena the baselines being compared against differ between these three systems, so even the shared-benchmark numbers cannot be directly ranked against each other without knowing whether they used the same baseline agent, the same backbone model, and the same task subset.

For a builder choosing among these systems, the concrete inputs differ by method, and each requires a different piece of supporting infrastructure. CoAct requires two agent roles operating together: a global planning agent and a local execution agent [2], following the transfer of hierarchical planning and collaboration patterns from human society [2]. This means a builder needs an orchestration layer that passes tasks from the planner to the executor and returns execution results back to the planner, since the claims describe a two-agent collaboration rather than a single monolithic agent.

WebAgent requires an instruction-decomposition step that produces canonical sub-instructions before execution begins [5]; a builder needs whatever mapping or prompting mechanism produces these canonical forms, and this step sits upstream of whichever execution module carries out each sub-instruction. Because the claim states this decomposition happens by planning ahead, the sub-instructions are generated before execution starts rather than being produced one at a time as execution proceeds.

RaDA requires a retrieval component feeding both stages, Retrieval-augmented Task Decomposition and Retrieval-augmented Action Generation [8], and specifically does not require the builder to hand-write exemplars [8], which lowers setup cost compared with methods needing curated few-shot examples. A builder implementing RaDA needs a retrieval index or corpus that both stages can query, since retrieval is described as augmenting both the decomposition stage and the action-generation stage, not just one of them.

SkillWeaver requires a mechanism for the agent to autonomously synthesize reusable skills as APIs [6], since it is described as a skill-centric framework enabling agents to self-improve this way [6]; a builder needs storage for these synthesized APIs and a way to make them callable by both the strong agent that made them and weaker agents that reuse them [6], since the cross-agent transfer result depends on APIs made by one agent being usable by another. Region4Web and PageDigest require access to the AXTree of each page so it can be reorganized into functional regions [3], and a mechanism to persist the resulting per-page digest across steps for the actor agent [3], meaning the builder needs a persistence layer that carries the digest forward from one step to the next rather than recomputing it fresh at every step.

None of the claims specify exact model sizes, token costs, or wall-clock latency for any of these systems, so these must be measured directly if a builder implements any of them. This is a genuine gap in the source material for anyone doing cost planning: a builder cannot budget API spend or expected response time from the claims alone and must instrument their own implementation to obtain these figures.

The three core capabilities identified for LLM-based web agents, high-level planning, low-level execution, and replanning [1], provide a checklist a builder can use when assembling any of the systems above: each system implements planning in some form, but a builder should check separately whether the system as described also addresses execution quality and replanning, since the claims do not state that any of CoAct, WebAgent, RaDA, or Region4Web explicitly improves the execution or replanning layers as defined in [1], only that AdaPlanner explicitly targets replanning through adaptive feedback [7].

No claim in this set reports a controlled experiment that varies only the presence or absence of hierarchical decomposition while holding the benchmark, model, and baseline fixed. Every reported improvement compares a new decomposition-based method against a different prior method or prior state of the art, so the size of the improvement reflects both the decomposition change and whatever else differs between the new and old system, such as new retrieval components, new prompting, or new tool access.

The claim that low-level execution remains the dominant bottleneck in LLM web agents [1] suggests that gains attributed to better planning decomposition may partly or wholly reflect improvements elsewhere in the pipeline, such as execution or replanning; the source claims do not decompose SkillWeaver's, WebAgent's, or CoAct's reported gains into planning-layer versus execution-layer contributions. Similarly, improving perceptual grounding and adaptive control is described as critical to reliability [1], but none of the decomposition-focused papers in this set report whether their systems changed grounding or control at all, so it remains unknown from these claims whether any of the reported success-rate gains touched the layer identified as the dominant bottleneck.

Existing evaluations focus primarily on end-to-end success, offering limited insight into where failures arise [1], which is exactly the gap that prevents drawing a firm conclusion about hierarchical decomposition specifically. This gap also means that even within a single paper's own reported numbers, such as SkillWeaver's 31.8% and 39.8% improvements [6], there is no breakdown available in the claims that would say whether the improvement came from better task decomposition, better skill synthesis, or some other part of the system.

Another open question is whether the different decomposition mechanisms described in this note, role-splitting in CoAct, instruction-splitting in WebAgent, stage-splitting in RaDA, and observation-splitting in Region4Web, would produce similar or different gains if tested on the same benchmark with the same backbone model. The claims give no basis for predicting this, since each mechanism is reported only within its own paper's experimental setup.

SkillWeaver is a skill-centric framework enabling agents to self-improve by autonomously synthesizing reusable skills as APIs [6], and this raises a further open question not answered by the other claims: whether autonomously synthesized skills interact well or poorly with hierarchical decomposition of the planning layer, since skill synthesis and plan decomposition are two different design choices that could in principle be combined, but no claim reports such a combination being tested.

Until a study varies decomposition alone against a matched flat-planning baseline on the same benchmark with the same model, the honest answer to the research question remains: decomposition-based systems often improve on their own prior baselines, but this is not the same as showing decomposition itself, isolated from other design choices, raises success rate. Readers should treat every percentage figure in this note as tied to its own paper's baseline and benchmark, not as a general measure of how much hierarchical decomposition helps.

A competent engineer wanting to test whether hierarchical decomposition helps web task success, rather than simply reuse a paper's reported number, should build a controlled comparison rather than a single system. The following procedure follows the methods described in the cited sources without inventing new mechanisms, and it is organised so that each step produces a measurement that can be checked against a clearly stated baseline.

1. Pick one benchmark used in the claims, for example WebArena, MiniWoB or MiniWoB++, Mind2Web, or CompWoB, and one backbone LLM, and hold both fixed for the entire comparison. This is necessary because none of the cited results share a common benchmark and baseline across papers, so any new comparison must fix these itself.
2. Build a flat-planning baseline agent: a single agent that receives the task instruction and produces actions directly, without an explicit decomposition step, following the framing that current evaluations mostly measure only end-to-end success [1]. This baseline gives the engineer a reference point that none of the cited papers directly provide in a form comparable across systems.
3. Build one decomposed variant at a time, matching the mechanism to one cited method: (a) a global and local role split as in CoAct, with a global planning agent and a local execution agent [2]; (b) instruction decomposition into canonical sub-instructions as in WebAgent [5]; (c) a two-stage planner as in RaDA, with Retrieval-augmented Task Decomposition followed by Retrieval-augmented Action Generation [8], and without hand-written exemplars [8]; or (d) observation-space decomposition as in Region4Web and PageDigest, reorganizing the AXTree into functional regions and passing a persistent per-page digest to the actor agent [3].
4. Keep the action-execution code identical between the flat baseline and every decomposed variant, so that any success-rate difference can be attributed to the decomposition step rather than to execution differences. This matters directly because low-level execution is identified as the dominant bottleneck [1], so any uncontrolled difference in execution code would confound the comparison.
5. Run both the baseline and each variant on the same benchmark's task set, using the same evaluation criteria the benchmark defines for success.
6. Record not only end-to-end success rate but also, where possible, separate execution-step errors from planning errors, addressing the gap that existing evaluations offer limited insight into where failures arise [1]. This step directly answers the open question left by the source material: whether a decomposition variant's gain, if any, comes from the planning layer or from some other layer.
7. Compare each decomposed variant's success rate against the flat baseline's success rate on the same task set; report the difference as a controlled result, distinct from the cited papers' own baseline comparisons such as CoAct's comparison against baseline methods [2] or SkillWeaver's comparison against its own prior version [6].
8. If replanning is added, treat it as a separate condition from decomposition; note that AdaPlanner's mechanism, adaptively refining a self-generated plan from environmental feedback [7], is a replanning capability, not a decomposition of the initial plan, so it should not be relabeled as decomposition evidence in the final report.
9. If skill synthesis is added, treat it as a separate condition again; SkillWeaver's mechanism of autonomously synthesizing reusable skills as APIs [6] is a self-improvement capability, distinct from how the initial plan is structured, and its cross-agent transfer effect, improvements of up to 54.3% on WebArena when weaker agents use APIs made by strong agents [6], should be tested independently of any decomposition variant.

Common failure points to watch for: conflating a decomposition change with a simultaneous model or prompt change, which is exactly what makes the published numbers in the measured-results section incomparable across papers; attributing a success-rate gain to planning when the source material argues execution is the dominant bottleneck [1]; and reusing a benchmark's published baseline number instead of re-running the flat-planning baseline under identical conditions, since small differences in task subset or backbone model can shift a baseline's success rate independent of any decomposition change.

for variant in [flat_baseline, coact_style, webagent_style, rada_style, region4web_style]:
    run(variant, benchmark, backbone_llm)
    record(success_rate, execution_error_count, planning_error_count)
compare(variant.success_rate, flat_baseline.success_rate)