Plan-and-Act: Improving Planning of Agents for Long-Horizon Tasks
Authors: Lutfi Eren Erdogan
Nicholas Lee
Sehoon Kim
Suhong Moon
Hiroki Furuta
Gopala Anumanchipalli
Kurt Keutzer
Amir Gholami
Venue: ICML 2025 poster (2025)
Keywords: LLM
Agents
Web Agents
Planning
Primary area: deep_learning->large_language_models
TL;DR: We introduce Plan-and-Act, a framework that enables accurate and reliable long-horizon task solving with explicit planning. We additionally introduce  synthetic data generation method for training the planner.

Abstract: Large language models (LLMs) have shown remarkable advancements in enabling language agents to tackle simple tasks. However, applying them for complex, multi-step, long-horizon tasks remains a challenge. Recent work have found success by separating high-level planning from low-level execution, which enables the model to effectively balance high-level planning objectives and low-level execution details. However, generating accurate plans remains difficult since LLMs are not inherently trained for this task. To address this, we propose Plan-and-Act, a novel framework that incorporates explicit planning into LLM-based agents and introduces a scalable method to enhance plan generation through a novel synthetic data generation method. Plan-and-Act consists of a Planner model which generates structured, high-level plans to achieve user goals, and an Executor model that translates these plans into environment-specific actions. To train the Planner effectively, we introduce a synthetic data generation method that annotates ground-truth trajectories with feasible plans, augmented with diverse and extensive examples to enhance generalization. We evaluate Plan-and-Act using web navigation as a representative long-horizon planning environment, demonstrating a state-of-the-art 57.58% success rate on the WebArena-Lite benchmark as well as a text-only state-of-the-art 81.36% success rate on WebVoyager.

PLAN-AND-ACT: Improving Planning of Agents for Long-Horieg Tasks
Lutfi Eren Erdogan" Nicholas Lee"
Sehoon Kim Suhong Moon
Hiroki Furuta"
Gopala Anumanchipalli
Kurt Keutzer!
Amir Gholami 13
Abstract
Large language models (LLMs) have shown re- markable advancements in enabling language agents to tackle simple tasks. However, applying them for complex, multi-step, long-horizon tasks remains challenge. Recent work have found success by separating high-level planning from low-level execution, which enables the model to effectively balance high-level planning objec- tives and low-level execution details. However, generating accurate plans remains difficult since LLMS not inherently trained for this task. To address this, we propose PLAN-AND-ACT. novel framework that incorporates explicit plan- ning into LLM-basee agents and introduces a scal- able method to enhance plan generation through a novel synthetic data generation method. PLAN- AND-ACT consists of PLANNER model which generates structured, high-level plans achieve user goals, and an EXECUTOR model that trans- lates these plans into environment-speecfee actions. To train the PLANNER effectively, we introduce a synthetic data generation method that annotates ground-truth -ruth trajectories with feasible plans, aug- mented with diverse and extensive examples to enhance generalization. We evaluate PLAN-AND- ACT using web navigation representative long-horizon planning environment, demonstrat- ing state-of-the-art 57.58% % success rate on the AeeArenaeLite benchmark as well as text-only state-of- state-of-the-an the-art 81.36% success rate on WebVoy- ager.
Environment
Action
Planner LLM
Executor
Query
Generated Plan
LLM
Exit
Figure I. An illustration of PLAN-AND-ACT System Diagram. First, the PLANNER LLM processes the initial user query and generates initial step by step plan (Section 3.1). This then passed to the EXECUTOR LLM which uses the plan and generates an actions to interact with its Environment. The environment feed- back is then fed back to both the EXECUTOR so it can generate subsequent actions and/or to the PLANNER in case a new plan needs to be generated. Existing methods have shown this separa- tion high-level planning and low-level execution can improve accuracy. However, major challenge is that LLMs are not gener- ally trained to generate such plan/low-leve action, problem that we focus solving in this paper.
that can interact with environments through sequences of actions. These agents are designed to tackle complex, multi- step, long-horizon tasks by leveraging the model's s reasoning and decision-making capabilities. At the heart building such effective agents lies fundamental challenge: planning, Even for seemingly simple tasks, agent must understand the goal, break down into manageable steps, and adapt those steps circumstances change. However, despite these ad advancements, plamning remains a significant challenge for several reasons. First, agents often struggle to break down high-level user goals (like "book me a flight to New York") into specific, actionable steps (like "open the airline web- site", "enter travel dates". etc.). Second, tasks grow longer and more complex, maintaining coherent strategy becomes increasingly difficult agents lose track of what they' ve accomplished and what remains to be done. Third, real-world environments are dynamic and unpredictable, requiring agents to constantly revise their plans. These chal- lenges are further amplified by the scareity of high-quality
1. Introduction
Large language models (LLMs) have significantly advanced in capability, enabling their application as language agents
"Equal contribution 'UC Berkeley 2 Universsity Tokyo $ICSI. Correspondence to: Amir Gholami <amirgh @ berghheeerrreeec>>..>>..
Proceedings of the 42nd International Conference on Machine Learning, Vancouver, Canada. PMLR 267, 2025. Copyright 2025 by the author(s).

---

PLAN-AND-ACT: Improving Planning of Agents for Long- Long-Horizon Tasks
Plan 1
User Query
## Step Navigate to the "Contributors" section
Action
"rallow the top contributor of this GitH project"
Planner
Executor
Click on "Contriluuorr" 1ink
dolaction=" CCick"" elmment="13"
Identify contributor follow then
Observation
top contributor
Replan
Action 2
Planner
Step "Jotn
Executor
12ohn
do (actioon"Click,, element="2")
Figure 2. PLAN-AND-ACT System Diagram. Given the initial user query, the PLANNEE (Section 3.1) breaks it down into high-level plan, which is given to the EXECUTOR (Section 3.2) which uses the plan to guide its actions. Once the action has been taken and the HTML changes, the PLANNER dynamically generates plan that incorporates the changes in the environment (Section 3.3).
training data that demonstrate effective planning strategies.
that we introduce a scalable method that allows finetuning the PLANNER and EXECUTOR components. In particular, our contributions follows:
Previous approaches improve agent performance for long- range tasks such web navigation (Qi et al., 2024; Yang et al., 2024a; Gur et al., 2023; Zhang et al., 2024b) and device control (Erdogan et al., 2024; Pawlowski et al., 2024) have shown promise. However, most rely on a single model to directly translate user requests into actions. This creates difficult balancing act the model must simultaneously reason about the high-level strategy while managing the low-level execution details (Yang et al., 2024a). Under this load, models often lose sight of their ultimate objectives and struggle to maintain consistent behavior (Sridhar et al., 2023). Recent work has explored the use of Reinforcement Learning (RL) (Sutton, 2018) to improve performance (Bai al., 2024: Qi et al., 2024), but these methods can be unstable and highly sensitive hyperparameters and reward design (Rafailov et al., 2024; Furuta et al., 2024).
We propose PLAN-AND-ACT, a framework that improves planning for long-horizon tasks through explicit separa- tion of planning and execution. As shown Figure our architecture consists of PLANNER that breaks down requests into structured plans, and EXECUTOR that implements these plans through enviromment actions (Section 3).
To train the PLANNER model effectively, introduce synthetic data generation pipeline to generate planner data with and without access to extra ground truth data. First, we use an LLM to analyze successful action trajectories (sequences actions like clicking, typing, etc.) and gener- ate the corresponding high-level plans through grounded plan generation, ensuring these plans are grounded in actual executable actions (Section 4.2). Second, we syn- thetically augment dataset by using these initial plans as seed data to generate additional diverse planning exam- ples (Section 4.3). This comprehensive approach enables us to create high-quality training data despite the scarcity of real-world planning examples.
To equip LLMs to effectively plan for long- horizoo tasks more reliably, we introduce PLAN-AND-ACT ACT, a framework that incorporates explicit planning into LLM-based agents. Unlike traditional approaches like ReAct based methods (Qi al., 2024; Gur et al., 2023; Yang et al., 2024b) that rely on single model to directly map user queries sequence of actions, PLAN-AND- ACT adopts framework similar to LLMCompiler (Kim et al., 2023b) which consists of two modules: a PLANNER and an EXECUTOR (Figure 1). The PLANNER model generates a sequence of plans that outline the high-level steps required to achieve the goal, while the Executor translates these steps into environment-speen specific actions. Furthermore, framework provides effective and scalable solution for generating training data to train the PLANNER without requiring manual annotation or sandbox environment. The difference with LLMCompiler is
To demonstrate the efficacy of our approach on long- horizon tasks, we evaluate PLAN-AND-ACH in the WebArena-Lite (Liu et al., 2024) environment for web navigation, achieving SOTA result of 53.94% (Table 1).
2

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
2. Related Work
generate trajectories from an LLM and filter for failed in- stances. Patel et al. (2024) combined real and synthetic data, while Yang et al. (2024b) supplemented training with multiple trajectories on failed tasks. Both NNetscape Nav- igator (Murty et al., 2024) and WebRI. (Qi et al., 2024) employed eestructiin-generation techniques- the former retroactively labeled explored website trajectories, while the latter used Self-Instruu style prompts to generate queries for trajectory collection, with failed trajectories seeding further targeted data generation.
2.1. Language Agents as Web Agents
As LLM agents become more widespread, they have been increasingly applied as web agents to traverse and operate web pages (Gur et al., 2022; Kim et al., 2023a) through GUI interaction (Pawlowski al., 2024; Rawles al., 2024; Zhang et al., 2023; Xie et al., 2024; Zhang et al., 2024a) or API interaction (Song et al., 2024), which has spurred new datasets (Shi et al., 2017: Deng et al., 2024; Rawles et al., 2024) and benchmarks (Yao et al., 2022a; Zhou et al., 2023; Koh et al., 2024; Liu et al., 2024).
3. System Architecture
Several works employ hierarchical planning frameworks similar to PLAN-AND-ACT but rely on prompting closed- source models like GPT-4o. AgentOccam (Yang et al., 2024a) incorporates planning into the action space with tree-like planning, WebPilot (Zhang et al., 2024b) uses six different agents, AdaPlanner (Sun et al., 2023) employs In- Plan and Out-of-Plan Refiners for replanning, and ADaPT (Prasad et al., 2023) uses recursive decomposition. In con- trast, PLAN-AND-ACT provides simpler two-agent frame- work with a systematic approach to generating high-quality training data for open-source LLMs.
As discussed in previous work (Sridhar et al., 2023; Yang et al., 2024a), at the heart of effective agents lies the chal- lenge of balancing high-level reasoning with low-level exe- cution. When a single model must simultaneously perform long horizon planning and then also execute multiple low- level actions for each part of the plan, it faces difficult cognitive load that often leads to suboptimal decisions or inconsistent behavior. This challenge becomes especially acute for long- tasks, where the agent must maintain coherent strategy across many steps while adapting to changes in the environment.
Training data generation approaches for Web Agents include DigiRL (Bai et al., 2024), WebRL (Qi et al., 2024), Auto bGLM (Lai et al., 2024), and NNetNav (Murty et al., 2024), which focus on collecting diverse trajectories but lack plan- ning data generation. Unlike these methods that rely external simulators, our approach can generate synthetic planning data without a simulator (Section 4.3).
To address this fundamental challenge, our framework sepa- rates these responsibilities into two specialized components: a PLANNER that focuses on strategic decision-making and an EXECUTOR that specializes in implementing those de- cisions (Figure 2). This separation allows each component to excel at its core task. The PLANNER reason about high-level strategy without getting bogged down in imple- mentation details, while the EXECUTOR can focus on trans- lating abstract plans into concrete actions (Kim et al., 2023b; Wang et al., 2023).
Some robotics research (Song et al., 2023; Nayak et al., 2024; Kannan et al., 2024) uses hierarchical LLM Agents for task decomposition and planning, sharing similarities with our work. Other approaches include pretraining L.MSs on HTML (Gur al., 2023), leveraging vision capabilities of VLMs (Furuta et al., 2023), or adopting RL to improve performance through interaction (Qi et al., 2024; Bai et al., 2024; Yang et al., 2024b).
While our framework is adaptable to various structured decision-makee making environments, we focus on web agents due to the web's dynamic and complex nature, which in- volves diverse actions and long-horizon tasks. For web tasks, the PLANNER takes user query (like "Follow the top contributor of this GitHub project") and breaks it down into clear, manageable steps (such as "Navigate to the Con- tributors section" followed by "Identify and follow the top contributor"). The EXECUTOR then takes these steps and translates them into precise actions in the web environment, like clicking specific links typing in search boxes. The observation space that we will use for this task is HTMI as the text-representatioon of the environment.
2.2. Synthetic Data Generation
Synthetic generation has gained popularity since pioneering work like Self-Instruct (Wang et al., 2022) and Alpaca (Taori et al., 2023), with many recent papers using synthetic data to enhance LLM performance (Xu et al., 2023; Lee al., 2024; Erdogan al., 2024; Wang et al., 2024a; Gunasekar et al., 2023; Moon et al., 2024).
For web agents specifically, researchers commonly col- lect training trajectories in reusable environments (Zhou et al., 2023; Koh et al., 2024; Liu et al., 2024) through on- policy methods (Qi et al., 2024; Yang et al., 2024b; Patel et al., 2024; Ou et al., 2024). These approaches typically
3.1. PLANNER
The PLANNER takes the user query and breaks it down into structured plan that dictates the essential high level steps required to accomplish the task. This plan is used to as a
3

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
guide for the EXECUTOR runtime, providing clear road-
how the EXECUTOR can complete the user query.
map while allowing some flexibility for the EXECUTOR. By handling most of the reasoning and task decomposition, the PLANNER streamlines decision making and task execution.
Conveniently, dynamic replanning allows the planner to re- tain key information within the evolving plan. For instance, consider the example in Figure 2. The original plan did not know who the top contributor was, so it could only contain the step Identify the top contributor and follow them. After the contributor was identified upon execution of the action clicking " "Contributors" link, the PLANNER incorporates this information into the remaining plan. Since the plan car- ries forward the relevant context, this approach also allows us to address challenges related to memory for long-horizon tasks without requiring an explicit memory module ( (Yang et al., 2024a; Zhang et al., 2024b). More detailed examples of dynamic replanning can be found at Appendix A.5.
Consider the example in Figure 2, which shows an example of this module in action, in the context of a web task. We have the original user query Follow the top contributor of this GitHub project and the goal is for our WebAgent to execute this task on GitHub. The PLANNER processes this user query and breaks down the task into step-by-step plan, consisting of (i) Navigating to the Contributors section and (ii) Identifying and Following the top contributor.
3.2. EXECUTOR
The EXECUTOR is an LLM Agent that takes the plan from the PLANNER (Section 3.1) and runs it in the environment. is responsible for calling tools, retrieving data, or making changes in the environment required by the plan.
This approach aligns with our architectural philosophy where the PLANNER serves as the "control room" for rea- soning and decision-making while the EXECUTOR focuses solely on translating plans into environment-specific actions.
For example, in the web task shown in Figure 2, once the PLANNER generates a plan for the query Follow the top con- tributor of this GitHfub project, the EXECUTOR only needs to translate the step Navigate to the "Contributors" section into a click action on the HTML. As we can see, EXECUTOR takes HTML as an input and outputs a grounded concrete action in the environment. Importantly, after executing an ac- tion, the EXECUTOR performs garbage collection, removing unnecessary data such as redundant HTML before executing the next action. More explicit examples of the PLANNNRR- EXECUTOR trajectories can be found in Appendix A.4.
3.4. Chain of Thought Reasoning
Currently, the PLANNER and EXECUTOR generate plans and actions directly. However, recent advances in chain-of-thoughh (CoT) prompting and inference-time seal- ing (Kojima et al., 2022; Wei et al., 2022; Guo et al., 2025) have shown that eliciting intermediate, step-by-step ratio- nales can substantially improve performance. Thus, before having the PLANNER and EXECUTOR generate the plan and action respectively, we also have them generate CoTT reasoning trace in order to improve performance. You can find the CoT experiment results in Section A.
3.3. Dynamic Replanning
4. Synthetic Data Generation
A key limitation of the previous approach is that the initial plan is static throughout execution, which makes it vul- nerable to unexpected variations in the environment. For instance, in the web-navigation example, static plans are unequipped to handle dynamic content interpretation, such as analyzing search results or transaction histories. The EXECUTOR can fail to correctly process content that is un- known priori at planning time. Furthermore, static plans can have issues with unexpected failures, such as searching a keyword returning nothing. If the plans are static, the EXECUTOR may blindly follow the steps in the original plan rather than trying a different approach. As shown in previous work in task decomposition (Kim et al., 2023b), static planning can have fundamental drawbacks even in straightforward tasks.
To motivate the need for creating synthetic data, we first evaluated the performance of existing off-the-sheli' LLMs on WebArena-Lite which involves challenging user queries and reported the results in Table 1. We observe a baseline performance of 9.85%, which increases to 14.21% with PLAN-AND-ACT. While this is a noticeable improvement, the result is far from satisfactory.
There are several contributing factors this low perfor- mance. Most notably, LLMs are not trained to perform this form of long horizon planning, especially for web tasks. This affects both the PLANNER and EXECUTOR. The PLAN- NER cannot generate accurate plans if the LLM has not seen these websites in its pretraining and the trajectories that are needed to accomplish the query. The EXECUTOR has also most likely not been trained on getting a user query along with the HTML of a page and output web action. Overall, we cannot expect an off off-the-shelf I.I.M to have this capa- bility if it has not been trained on planning/executing tasks during pretraining such as in a specialized domain, such as
To address this limitation, we introduce dynamic replanning, where the PIAANNER updates the plan after each EXECUTOR step rather than relying solely on the initial plan. After each iteration, the PLANNER takes in the current state as well as the previous plans and actions and generates a new plan for
4

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizan Tasks
Sec 4.1: Synthetic Usery Query and Action Trajectory Generation
Synthetic Action Trojectories
Synthetic User Queries
sesactiinn "Seano"', arquaent: "yytand""
delaction
Find top 3 contributors to the "pytorch" rapo
argunente Vantralutors", clement='e")
#sjactian Cllskk,, argumente "Sort",
Synthetic Query Generator
Teacher LLM
Create an issue under the "fastap1" nepo to report a bug about resporse validation
argunent "rastapp"
Training Data
"ellcction""Cio"" arjuente""sssess senenter122)
tschetionn arganents"S elarattu
Sec 4.2: Grounded Synthetic Plan Generation
Synthetic Action Trajectory
Synthetic Plan
aaatiioo""Saaaee argurent= "pytorch"" mmeette"33)
step: Nevigate "pytorch"
argunent=""oom "ontrriuutors elemint='8")
2. dotact tore"Selecc""
Teacher LLM
Actions: [1)
Step
Step: Select rontrol section top contritutors
4. defaccioon""Liic" argunent="Sortt e (larent="33")
Actions:
Sec 4.3: Synthetic Plan Expansion
Synthetic Query + Plan
contributors of
comit number "Lanux"
#2 Step 1 Step: Navigate
repo
Teacher LLM
*e Stap 2
Step: Open the Contributors section
Seed Synthetic Plans
Step number
results
a0 Stop 4 Step:
results only
Figure 3. Synthetic Data Generation Pipeline. In the Action Trajectory Generation stage (Section 4.1). user queries from the training data are given a Teacher LLM,, which outputs synthetic user queries. From there, demonstrator actor LLM attempts to execute the query the webpage. After the trajectory is finished, an ORM L.M is used filter for successful trajectories. In the Grounded Plan Generation stage (Section 4.2), Teacher I.I. takes the trajectory and creates synthetic high-level plan and grounds each step with explicit actions in the trajectory. In the Synthetic Plan Expansion stage (Section 4.3), the plans from the training data sampled and given to the Teacher LLM, which generates new synthetic plans.
web navigation.
sponding plan breakdown. The EXECUTOR needs data that includes HTML input for each of the plan steps along with the desired web action as its output. However, such data not available. Manually collecting this data is an option but is both costly and time-consuming as the human annotator needs to write down plan of action followed by execution corresponding each of the steps.
Importantly this issue cannot be solved with prompting alone. While performing prompt engineering and including in-context examples can help with simple tasks, the LLM struggles when given non-trivial queries evident the low baseline accuracy.
Given that prompting alone cannot solve this issue, we have to perform finetuning of the I.LM to improve the per- formance of the PLANNER and EXECUTOR. However, in order to finetune the model, we need to ensure we have sufficient amount of data for finetuning, particular, the PLANNER requires data that has user query and its corre-
Here we propose an alternative approach that allows scal- able method to collect and generate high-quality synthetic training data. Our method leverages an LLM-based anno- tation pipeline that processes existing action trajectories to generate the corresponding structured plans, which depicted in Figure 3.
5

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
4.1. Action Trajectory Generation
action trajectories of the webagent is transformed into set of high-level actions that we want the PLANNER to output. This approach is similar to (Murty et al., 2024), although our method generates high-level plans while their technique generates synthetic user queries from the trajectories.
The simplest way collect more data for the EXECUTOR is to collect more trajectories from the environment, tech- nique that has been used in previous works (Qi et al., 2024; Murty et al., 2024).
To achieve this, we use an Alpaca-style (Taori et al., 2023) data generation pipeline. Motivated by Qi et al. (2024), we randomly sample user queries from the training data and use them seed prompts for LLM to generate new, similar queries. For the web-navigation task, these queries are filtered initially by an LLM to filter out impossible trajectories for the web-agent. These newly generated user queries are then given to a demonstrator agent which tries to complete the task in the environment, which we collect as a synthetic trajectory. Finally, we then score this trajectory by using an outcome- supperiiee reward model (ORM) to filter for successful and unsuccessful trajectories. This initial process is depicted in Figure 3 in the first row for the web- navigation task and the prompts for the query generation are adapted from (Qi et al., 2024).
4.2.1. SYNTHETIC DATA GENERATION FOR DYNAMIC REPLANNING
It is important also create synthetic data that captures dynamic replanning. This is important because a lot of user queries require planning based on dynamic observations that are only known during the plan execution. Examples queries that require such planning are: "Analyze the search results and select the most relevant item" or "Find the most recent pending order".
We can use similar algorithm to generate synthetic replan- ning data. The main difference is that for replanning data generation, we need to supply the teacher LLM with origi- nal plan data along with the trajectory that the webagent has taken to reach the point that requires replanning. You can find detailed prompts in Appendix A.
4.2. Grounded Plan Generation
4.2.2. SYNTHETIC DATA GENERATION FOR THW.THHHOOO--T-S-IINGG REASONING
While we can use synthetically created user queries and then collect the resulting trajectories to train the EXECUTOR, this approach presents challenges when used to create synthetic data for the PLANNER.
Similarly, also need to generate synthetic data to elicit CoT reasoning for both the PLANNER and EXECUTOR, since not all models have been trained to generate reasoning traces. We use an algorithm similar to Section 4.2 to gen- crate reasoning traces for both plan and action generation. For plan reasoning generation, we have the teacher LLM generate reasoning before outputting the plan while for ac- tion reasoning generation, we provide the original plan data and the trajectory that the webagent has taken, along with the expected correct action and prompt the teacher LLM to generate a reasoning trace for that action.
naive approach would be to provide a teacher LLM with user query and prompt it generate step-by-step plan to accomplish the task. However, this runs into a fundamen- tal limitation: the teacher LLM lacks access to the actual website or environment and has not been pretrained on such tasks. Attempting this method results in generated synthetic plans that are often misaligned with how the tasks need to be performed on the web.
To address this, we leverage the in-context learning capa- bilities of I. LLMss which allows them to generalize on tasks outside their pretraining distribution. Specifically, we take advantage of this capability and provide the teacher LLM the trajectories that we created in Sec. 4.1 and prompt it to "reverse-engineer" structured plans from these trajectories. Given the trajectory, we prompt the LLM to analyze the sequence of actions and to synthesize a coherent plan that will be used to guide the EXECUTOR downstream. To make sure that the plan is grounded to the actual environment, we further prompt the model to also include which low-level ac- tions in the trajectory would be assigned to which high-level actions in the plan, to ensure that the plan matches actual execution of the trajectory. This ensures that the generated plans align with the real execution environment, making the both accurate and executable.
4.3. Synthetic Plan Expansion
The previous approach requires a simulator environment to collect actions and then create a synthetic plan by reverse- engineering the actions. Collecting successful trajectories that passes the ORM in Sec. 4.1 can be time consuming since the teacher model may generate lot of unacceptable trajectories. This will affect the amount of data that can generate both for the EXECUTOR as well as the PLANNER. This issue is noticeably worse for the PLANNER since each successful trajectory that passes the ORM model entails on average 8 different steps which provide 8 training data points for the EXECUTOR, but only plan. However, we can effectively address this data imbalance, by expanding the synthetic plans.
Specifically, we expand the PLANNER dataset by generating
This is depicted in the second row of Figure 3, where the
6

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
similar query-plan pairs that resemble the existing data, similar to the Alpaca style query generation in Section 4.1.
et al., 2023) benchmark. We also evaluate PLAN-AND- ACT the full WehArena dataset as well the Web- Voyager (He et al., 2024a) dataset, which is a dynamic, realworld web dataset. See Section A.2 and Section A.3.
Similar to Section 4.1, we initially randomly sample query- plan pairs from the synthetic PLANNER training data. These examples serve as implicit constraints, guiding the language model to generate structurally consistent and semantically valid query-plan pairs while maintaining diversity.
Models: For our primary PL.AN-AND-CC framework, model by fine-tuning separate instances for both the PLANNER and EXECUTOR components. For our dynamic replanning experiments, we use a LLaMA-3, 3.3-70B-Insste ing LoRA (Hu et al., 2021) (due to computational con- straints). Each component is trained on our synthesized datasets as described in previous sections. We use GPT- 4o as the Synthetic Query Generator (Section 4.1), Plan Generator (Section 4.2) and Synthetic Plan Generator (Section 4.3). We use WebRL-Llama-331-7000 (Qi et al., 2024) as the actor model and OR.M-Llama-3.. 3.1-8B (Qi et al., 2024) as the filter model for filtering for successful trajectories. For generating CoT traces Section 3.4, we used DeepSeek-RI RI-istilll---- Distill-Llama-7000 (Guo et al., 2025) as the teacher model.
we utilize 3.LMAA-33-700-mm-s-
Using this pipeline with GPT-40, we expanded the synthetic plan data to 10,000 additional user query-plan pairs. This approach demonstrated significant advantages in both ef- ficiency and scalability, reducing data generation time to under an hour while simultaneously addressing the overfit- ting problem through increased data diversity. The resulting synthetic dataset exhibits a broad spectrum of use cases, contributing to improved model generalization (Section 5.2). This process is depicted in the third row of Figure 3 and the prompts for this are in Appendix A.8.
model fine-tuned us-
Targeted Plan Augmentation: While this large-scale data generation enhanced diversity and reduced underfitting for the PLANNER, it not adaptive, and doesn't 't take into ac- count what kinds of tasks are more difficult for the model in training. A key advantage of our approach is that we have explicit control over the data generation by allowing to analyze the model failures and selectively refine the dataset.
Baselines: We compare PLAN-AND-ACE against sev- eral strong baselines to evaluate its effectiveness. These include zero-shot L.L.MA3333-005 Instruct without any fine-tuning, -LLMA-333370BB Instruct fine-tuned specif- ically on the WebArena-Lää training set (ReAct-style prompting), and the WebRI--LJama-3.1-2 which is the current SOTA model on WebArena-lite. On Webarena-lite, we also compared against GPT-4- Turbo, GPT-4o, AWM (Wang et al., 2024b), and WebPilot (Zhang et al., 2024b). For the full WebArena dataset, we evaluated against NNetNav (Murty et al., 2024), AutoWe- bGL.M (Lai et al., 2024), WebPilot, and AgentOccam (Yang et al., 2024a). For the WebVoyager dataset, we evaluated against NNetNav, SpenWee (He et al., 2024b), Wilbur(Lutz et al., 2024), and Agent-E (Abuel- saad et al., 2024). These models were evaluated with a success rate metric, which requires complete task comple- tion for a positive score.
Motivated by previous works (Lee et al., 2024; Qi et al., 2024; Yang et al., 2024b) around adaptive curriculum- learning, we ran our model through held-out validation set which revealed several failure patterns in model perfor- mance. From there, our goal was to identify training data examples that seemed relevant to the failure patterns, in- stances where, if the model had seen more similar examples during training, it might improve performance on these tasks. To this end, we used an LLM to classify training data points that could be relevant to the failure nodes on each website and used them as seed data to generate 5,000 more synthetic plans. The prompts used to do this are in Appendix A.10 for classification and Appendix A. for generation. As we can see in Table 1, this targeted plan augmentation was able to significantly improve performance.
model,
Hyperparameters: The hyperparameters we used to train our PLANNER and EXECUTOR modules are found in Ta- ble 5. For the data generation in Section 4.1 and Sec- tion 4.3, we use 5 seed data points to generate 10 new synthetic data points.
5. Results
5.1. Experimental Setup
Environment: We run ablations on PLAN-AND-ACT us- ing WebArena-Lite (Koh et al., 2024), benchmark con- taining 165 test cases across diverse websites including OpenStreetMap, Reddit, GitLab, content management system (CMS), and OneStopShop (OSS). WebArena-Lite uses a binary success metric (1 for complete task success, 0 for failure) and provides training data while being more computationally efficient than the full WebArena (Zhou
5.2. Static PLANNER Results
Table shows the results of our experiments.
The columns represent a different versions of the EXECU- TOR (LLaMA-3.3-70B) The first column is a base EXECU- TOR, which is not finetuned. The second column has an EXECUTOR that was trained only on 1,113 WebArena-lite
7

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
Table 1. Task success rate (SR) of PLAN-AND-ACE WebArena-Lite, buman-verifice subset of WebArena. The rows represent incremental improvements to the PLANNER, while the columns show results for different EXECUTOR. For the executor, the first column is base prompted EXECUTOR, the second column is for an EXECUTOR finetuned on WebArena-lite data, and the third columa shows results when finetuned on both WebArena-lite training data and the 923 synthetically generated data from Section 4.1. The first row shows the results without PLANNER. For the results in this row, the Executors were trained ReAct style, with no plans. The second to sixth row shows reported results from WebRI. (Qi et al., 2024) including the current SOTA on WebArena-lite. The seventh row shows the result when using a base pero-shot PLANNER. The eigth row adds finetuning with the WebArena-Ile lite data and the ninth row adds finetuning with the additional data generated in Section 4.1. The tenth and eleventh row are after finetuning with the 10,000 synthetic plans generated in Section 4.3 and with the additional 5,000 synthetic plans generated by Targeted Augmentation. The 12th row shows the results after we introduce dynamic replanning into the architecture. The last row shows the results after adding CoT reasoning. Scores are averaged across all websites in the WebArena environment.
EXECUTOR Design
PLANNER Design
Base
+ Finetuning
Synthetic Traj.
No Planner
9.85
36.36
36.97
GPT-4-Turbo
17.6"
GPT-4o
13.9*
AWM + GPT-4-0613 (Wang et al., 2024b)
35.5"
WebPilot + GPT-4o (Zhang et al., 2024b)
37.2"
WebRL-3.1-70B (Qi al., 2024)
49.1"
Base
14.21
17.16
23.63
Finetuning
22.42
16.36
20.60
Synthetic Trajectories (Section 4.1)
24.24
27.28
30.30
+ Plan Expansion (Section 4.3)
27.10
38.18
39.40
Targeted Augmentation (Section 4.3)
29.63
42.42
43.63
+ Dynamic Replanning (Section 3.3)
44.24
48.48
53.94
+ CoT (PLAN- AND-ACT) (Section 3.4)
57.58
training data points, and the third column being an EXECU- TOR trained on both the WebArena-lite training data as well as the 923 synthetically generated action trajectories from Section 4.1.
see, naively finetuning the PLANNER did not improve per- formance for the finetuned EXECUTOR. Here, we found that the PLANNER was overfitting the training data and did not generalize to general plans for new, unseen tasks.
No PLANNER. The first row shows the results for each of these Executors when trained with the baseline ReAct prompt (Yao et al., 2022b) without a PLANNER. As we can see, doubling the amount of action trajectory data does not significantly improve performance, showing a 0.61% % im- provement from just training on the WebArena-Hie data. We cited this as motivation in Section 4.1 1 focus improving the PLANNER through plan generation.
Finetuned PLANNER with data expansion. The ninth through eleventh row show the results when iteratively dif- ferent synthetic data augmentation strategies. The ninth row shows the results after augmenting the PLANNER with extra synthetic trajectories from Section 4.1. The tenth row shows the results after using these grounded trajectories to generate 10,000 synthetic query-plan pairs from Section 4.3, and the eleventh row shows the performance after also adding in the 5,000 targeted synthetic query-plat pairs.
Base PLANNER. The seventh row shows the results of en- hancing each EXECUTOR with a base PLANNER (LLaMMA- 3.3-70B), which is not finetuned. As we can see, the per- formance improves for the base EXECUTOR, but fails to improve over the baseline for the trained Executors. What this can be attributed to is that since the PLANNER is not trained on data that is grounded to these specific websites, these plans are suboptimal and can confuse the EXECUTOR.
From these rows, we can see that a properly trained PLANN NER consistently improves performance across all of the different Executors. Even with base EXECUTOR, adding a PLANNER increases success rate from 9.85% to 29.63%. This validates our core hypothesis that explicit planning helps bridge the gap between high-level user intentions and low-level actions.
Finetuned PLANNER. The eighth row shows the results of using a PLANNER that has been finetuned only on the 1,113 plans in the WebArena-lin lite training data, As we can
The impact of generated data expansion is particularly no- table. Each expansion of the training dataset yields per- formance improvements, with the most substantial gains
8

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
coming from the addition of the 10,000 directly generated plans, increasing success rates by approximately 10 percent- age points. The hailure-analssi-guidde examples provided a final boost of 4-5 percentage points, highlighting the value of targeted data generation. Interestingly, the EXECUTOR'S s performance scales with training data size, but shows dimin- ishing returns after the initial 1,1 examples, suggesting that the bottleneck may lie more in plan quality than action execution.
tions, enhancing task consistency and adaptability to dy- namic environments. However, major challenge is that out-of-the-box LLMs are not efficient at generating accurate plans for environments outside their pretraining distribu- tion. In this work, we introduced PLAN-AND-ACT, a novel framework that enhances LLM agents' ability to tackle com- plex, long-horizon tasks through scalable synthetic data generation.
A key advantage of our method is its efficiency in data gen- eration. Our pipeline generated 15,000 synthetic training examples in under an hour using GPT-4o, whereas environ- ment interaction would take days or weeks. This scalability allowed us to match saate-of-the-ae performance with sim- ple supervised fine-tuning.
5.3. Dynamic Replanning Results
Despite these improvements, our detailed error analysis re- vealed fundamental limitations in the static PLANNER archi- tecture. While the EXECUTOR performed well concrete, deterministic tasks like navigating to specific pages, sorting tables, or posting comments on Reddit, it struggled with tasks requiring analysis of dynamic content. This aligns with our hypothesis in Section 3.3, that a static PLANNER would push some complex reasoning onto the EXECUTOR when it should focus solely on grounding abstract plans into specific actions. More explicit examples of this can be
Our results demonstrate that PLAN-AND-ACT significantly outperforms existing methods in web-based navigation tasks, Through synthetic data generation, plan expansion, and tar- geted refinement, our framework consistently improves suc- cess rates. Dynamic replanning further enhances model robustness by adapting strategies based on real-time obser- vations.
found in Appendix A.5.
By focusing on improving the planning component while keeping a standard EXECUTOR, we demonstrate ap- proach's potential. This modularity suggests future work could enhance performance by improving the EXECUTOR while maintaining our efficient planning framework. Be- yond web navigation, our framework holds promise for broader applications in various digital environments requir- ing long-horizon decision making.
5.3.1. REPLANNING RESULTS
To address the previous limitation we finetuned the PLAN- NER with additional replanning data (as discussed in Sec- tion 3.3). The results are shown in the 12th row of Ta- ble 1. As we can see, the addition of this capability signifi- cantly increases the performance of the model by 10.31% over the static PLANNER, achieving 53.94% accuracy WebArena-Lite, Notably, this result surpasses the previ- ous SOTA 1ebRL-33.177BB on the second row by 4. 4.84%. You can see some explicit examples where the PLANNER with dynamic planning is able to refine and improve the plan in Section A.5, and comprehensive breakdown of the performance by website can be found in Figure 4.
Limitations
One main drawback is that Action Trajectory Generation Section 4.1 does depend on having a baseline model that can successfully complete the web tasks. The synthetic data generation pipeline introduced in Section 4.3 is able to mitigate some of these concerns with a sufficient amount of training data. However, for datasets that do not have any training data, such as WebVoyager, the pipeline will depend on having a base model to collect trajectories.
Importantly, even with Base EXECUTOR (which has not been finetuned at all), we were able to significantly improve the performance of the model by 34.39% achieving 44.24% accuracy, just by providing a high-quality and dynamic plan. This result highlights the importance of explicit planning and justifies our framework with separate PLANNER and EXECUTOR, demonstrating that well-formed plan can substantially enhance performance even with an untrained EXECUTOR. WebArena and Web Voyager results can be found in Section A.2 and Section A.3.
Furthermore, our current framework does dynamic replan- ning (3.3) after every action, which can be inefficient and slow down performance. Future work can address these concerns by having the EXECUTOR decide when it needs to replan, or by having the PLANNER delegate tasks to separate subagents.
Acknowledgments
6. Conclusion
We thank Chris Joseph John and Anshul Verma for their help with the running of some of the benchmarks. We ac- knowledge gracious support from Apple team, as well as Nvidia for providing GPU hardware. We also appreciate the
It has been shown that separating high-level reasoning (PLANNER) from low-level execution (EXECUTOR), im- proves aligmment between user queries and executable ac-

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
support from Microsoft through their Accelerating Founda- tion Model Research. Furthermore, appreciate support from Google Cloud, the Google TRC team, and specifically Jonathan Caton, Divvy Thakkar, and Prof. David Patterson. Prof. Keutzer's lab is sponsored by the Intel corporation, Intel One-API, Intel VLAB team, the Intel One-API center of excellence, as well as funding through BDD, BAIR, and Furiosa. We appreciate great feedback and support from Ellick Chan, Saurabh Tangri, Andres Rodriguez, and Kit- tur Ganesh. Sehoon Kim and Suhong Moon would like to acknowledge the support from the Korea Foundation for Ad- vanced Studies (KFAS). Hiroki Furuta is supported by JSPS KAKENHI Grant Number JP22J21582. Our conclusions do not necessarily reflect the position or the policy of our sponsors, and no official endorsement should be inferred.
Gholami, A. Tinyagent:
Function calling the edge. arXiv preprint arXiv:2409.00608 2024.
Furuta, H., Lee, K.-H., Nachum, O., Matsuo, Y., Faust, A., Gu, S. S., and Gur, I. Multimodal web navigation with instruction-finetune foundation models. arXiv preprint arXiv:2305.1 /154,, 2023.
Furuta, H., Lee, K.-H., Gu. S. S., Matsuo, Y., Faust, A., Zen, H., and Gur, I. Geometrie-averaged preference optimization for soft preference labels. arXiv preprint arXiv:2409.0660 2024.
Gunasekar, S., Zhang, Y., Aneja, J., Mendes, C. C. Del Giorno, A., Gopi, S., Javaheripi, M., Kauffmann, P., de Rosa, G., Saarikivi, O., et al. Textbooks are all you need, arXiv preprint arXiv:2306. 1144,, 2023.
Impact Statement
Guo, D., Yang, D., Zhang, H., Song, J., Zhang, R., Xu, R., Zhu, Q., Ma, S., Wang, P., Bi, X., et al. Deepseck-rl: In- centivizing reasoning capability in llms via reinforcement learning. arXiv preprint arXiv:2501.12945. 2025.
This work aims to improve the capabilities of large language model-based agents in performing complex, multi-step tasks by enhancing their planning abilities. Our framework could positively impact productivity and accessibility by enabling more effective Al assistants for web-based tasks. However, improved autonomous web agents could also raise privacy concerns and potentially automate certain jobs, particularly those involving routine online workflows. We believe these advances should be developed alongside appropriate safe- guards and with consideration for economic transitions. Our synthetic data generation methods may also help reduce the data collection and annotation burden for training spe- cialized agents, supporting more efficient Al development practices. Future research should explore the fairness and robustness of these planning systems across different user contexts and application domains.
Gur, I., Nachum, O., Miao, Y., Safdari, M., Huang, A., Chowdhery, A., Narang, S., Fiedel, N., and Faust, A. Understanding html with large language models. arXiv preprint arXiv:2210.03945, 2022.
Gur, I., Furuta, H., Huang, A., Safdari, M., Matsuo, Y., Eck, D., and Faust, A. A real-world webagent with planning, long context understanding, and program synthesis. arXiv preprint arXiv:2307.12856, 2023.
He, H., Yao, W., Ma, K., Yu, W., Dai, Y., Zhang, H., Lan, Z., and Yu, D. Webvoyager: Building an end-to-end web agent with large multimodal models, arXiv preprint arXiv:2401.13911 2024a.
References
He, H., Yao, W., Ma, K., Yu, W., Zhang, H., Fang, T., Lan, Z., and Yu, D. Openwebvoyager: Building multimodal web agents via iterative real-world exploration, feed- back and optimization. arXiv preprint arXiv:2410. 2024b.
Abuelsaad, T., Akkil, D., Dey, P., Jagmohan, A., Vempaty, A., and Kokku, R. Agent-e: From autonomous web navigation to foundational design principles in agentic systems. arXiv preprint arXiv:2407.13032. 2024.
Hu, E. J., Shen, Y., Wallis, P., Allen-Zhu, Z., Li, Y., Wang, S., Wang, L.,, and Chen, W. Lora: Low-rank adaptation of large language models. arXiv preprint arXiv:2 1066009666 2021.
Bai, H., Zhou, Y., Cemri, M., Pan, J., Suhr, A., Levine, S., and Kumar, A. Digirl: Training in-the-wild device- control agents with autonomous reinforcement learning. arXiv preprint 2rXiv:2406.18890 2024.
Kannan, S. S., Venkatesh, L., and Min, B.-C. Smart- Ilm: Smart multi-agent robot task planning using large language models. In 2024 IFFF/RSJ International Con- ference on Intelligent Robots and Systems (IROS), pp- 121 12140-12147, IEEE, 2024.
Deng, X., Gu, Y., Zheng, B., Chen, S., Stevens, S., Wang, B., Sun, H., and Su, Y. Mind2web: Towards a general- ist agent for the web. Advances in Neural Information Processing Systems, 36, 2024.
Kim, G., Baldi, P., and McAleer, S. Language models can solve computer tasks. arXiv preprint arxiv:2303.174 174.1 2023a.
Erdogan, L. E., Lee, N., Jha. S., Kim, S., Tabrizi, R., Moon, S., Hooper, C., Anumanchipalli, G., Keutzer, K., and
10

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
Kim, S., Moon, S., Tabrizi, R., Lee, N., Mahoney, M. W., Keutzer, K., and Gholami, A. An IIm compiler for par- allel function calling. arXiv preprint arXivv2312.04511, 2023b.
Ou, T., Xu, F. F., Madaan, A., Liu, J., Lo, R., Sridhar, A., Sengupta, S., Roth, D., Neubig, G., and Zhou, S. Synatra: Turning indirect knowledge into direct demonstrations for digital agents at scale. arXiv preprint arXiv:2409.15637, 2024.
Koh, Y., Lo. R., Jang, L., Duvvur, V., Lim, M. C., Huang, P.-Y,, Neubig, G., Zhou, S., Salakhutdinov, R., and Fried, D. Visualwebarena: Evaluating multimodal agents alistic visual web tasks. arXiv preprint arXiv:2401.33649 2024.
Patel, A., Hofmarcher, M., Leoveanu-Condrei, C., Dinu, M.-C., Callison-Burch, C., and Hochreiter, S. Large language models can self-improve at web agent tasks. arXiv preprint arXiv:2405. 203009 2024.
Pawlowski, P., Zawistowski, K., Lapacz, W., Skorupa, M., Wiacek, A.,, Postansque, S., and Hoscilowicz, J. Tinyclick: Single-turn agent for empowering gui automation. arXiv preprint (tf::2410.118771 2024.
Kojima, T., Gu, S. S., Reid, M., Matsuo, Y., and Iwasawa, Y. Large language models are zero-shot reasoners, Ad- vances in neural information processing systems, 35: 22199-222133 2022.
Prasad, A., Koller, A., Hartmann, M., Clark, P., Sabharwal, A., Bansal, M., and Khot, T. Adapt: As-needed decompo- sition and planning with language models. arXiv preprint arXiv: 1.05772, 2023.
Lai, H., Liu, X., long, I. L., Yao, S., Chen, Y., Shen, P., Yu, H., Zhang, H., Zhang, X., Dong, Y., et al. Autowebglm: A large language model-based web navigating agent. In Proceedings of the 30th ACM SIGKDD Conference on Knowledge Discovery and Data Mining, pp. 5295-5306, 2024.
Qi, Z., Liu, X., Iong. L., Lai, H., Sun, X., Yang. X., Sun, J., Yang. Y., Yao, S., Zhang, T., et al. Webrl: Training Ilm web agents via self-evolving online curriculum re- inforcement learning, arXiv preprint arXiv:241 1.02337, 2024.
Lee, N., Wattanawong, T., Kim, S., Mangalam, K., Shen, S., Anumanchipalli, G., Mahoney, M. W., Keutzer, K., and Gholami, A. Llm2llm: Boosting ulms with novel iterative data enhancement. arXiv preprint arXiv:2403. 15042, 2024.
Rafailov, R., Sharma, A., Mitchell, E., Manning, D., Er- mon, S., and Finn, C. Direct preference optimization: Your language model is secretly a reward model. Ad- vances in Neural Information Processing Systems, 36. 2024.
Liu, X., Zhang. T., Gu, Y., Iong, I.,, Xu, Y., Song, X., Zhang, S., Lai, H., Liu, X., Zhao, H., et al. Visualagent- bench: Towards large multimodal models as visual foun- dation agents, arXiv preprint arXiv:2408.0632 2024.
Rawles, C., Li, A., Rodriguez, D., Riva, O., and Lillicrap. T. Androidinthewild: A large-scale dataset for android de- vice control. Advances in Neural Information Processing Systems, 36, 2024.
Lutz, M., Bohra, A., Saroyan, M., Harutyunyan, A., and Campagna, G. Wilbur: Adaptive in-context learning for robust and accurate web agents. arXiv preprint arXiw:2404.05902, 2024.
Shi, T., Karpathy, A., Fan, L.,, Hernandez, J., and Liang, P. World of bits: An open-domain platform for web- based agents. In International Conference on Machine Learning, pp. 3135-3144. PMLR, 2017.
Moon, S., S., Erdogan, L. E., Kim, S., Lim, W., Keutzer, K., and Gholami, A. Efficient and scalable estimation of tool representations in vector space. arXiv preprint arXiv:2409.02141, 2024.
Song, C. H., Wu, J., Washington, C.,, Sadler, B. M., Chao, W.-L., and Su, Y. LIm-planner: Few-shot grounded plan- ning for embodied agents with large language models. In P Proceedings of the IEFF/CVF international conference on computer vision, pp. 2992299989999 -009,, 2023.
Murty, S., Bahdanau, D., and Manning, C. D. Nnetscape navigator: Complex demonstrations for web agents with- out a demonstrator. arXiv preprint arX.v.2410.02907, 2024.
Song, Y., Xu, F. F,, Zhou, S., and Neubig, G. Beyond browsing: Api-based web agents. 2024.
Nayak, S., Morrison Orozco, A., Have, M., Zhang. J., Thiru- malai, V., Chen, D., Kapoor, A., Robinson, E., Gopalakr- ishnan, K., Harrison, J., et al. Long-horizon planning for multi-agent robots in partially observable environments. Advances in Neural Information Processing Systems, 37: 67929 67967, 2024.
Sridhar, A., Lo, R., Xu, F. F., Zhu, H., and Zhou, S. Hier-
archical prompting assists large language model on web navigation. arXiv preprint arXiv:2305.142555 2023.
Sun, H., Zhuang, Y., Kong. L., Dai, B., and Zhang, C. Ada- planner: Adaptive planning from feedback with language

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
models. Advances in neural information processing sys- Tems, 36:58202-58245, 2023.
Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., and Cao, Y. React: Synergizing reasoning and acting in language models. arXiv preprint arXiv:2210003629, 2022b.
Sutton, R. S. Reinforcement learning: An introduction. A Bradford Book, 2018.
Zhang, C., Yang, Z., Liu, J., Han, Y., Chen, X., Huang, Z., Fu, B., and Yu, G. Appagent: Multimodal agents smartphone users. arXiv preprint arXiv: 2023.
Taori, R., Gulrajani, I. Zhang, T., Dubois, Y., Li, X., Guestrin, C., Liang, P., and Hashimoto, T. B. Stanford alpaca: An instruction-foo -onllooi Ilama model, 2023.
Wang, K., Zhu, J., Ren, M., Liu, Z., Li, S., Zhang, Z., Zhang, C., Wu, X., Zhan, Q.. Liu, Q., al. survey on data synthesis and augmentation for large language models. arXiv preprint (xXi::241.128800 2024a.
Zhang, C., He, S., Qian, J., Li, B., Li, L., Qin, S., Kang, Y., Ma, M., Lin, Q. Rajmohan, S., et al. Large lan- guage model-brained gui agents: A survey, arXiv preprint 2.Vi::241118888 2024a.
Wang, L., Xu, W., Lan, Y., Hu, Z.., Lan, Y., Lee, R. K.-W,, and Lim, E.-P. Plan-and-solve prompting: Improving zero-shot chain-of-thought reasoning by large language models. arXiv preprint arXiv:2305.04400 2023.
Zhang, Y., Ma. Z., Ma. Y., Han, Z., Wu, Y., and Tresp. V. Webpilot: A versatile and autonomous multi-agent system for web task exccution with strategic exploration. arXiv preprint arXiv:2408. 15978, 2024b.
Wang, Y., Kordi, Y., Mishra, S., Liu, A., Smith, A., Khashabi, D., and Hajishirzi, H. Self-instruct: Aligning language models with self-generated instructions. arXiv preprint arXiv:2212. 10560, 2022.
Zhou, S., Xu, F., Zhu, H. Zhou, X., Lo, R., Sridhar, A., Cheng, X., Ou, T., Bisk, Y., Fried, D., al. Webarena: A realistic web environment for building autonomous agents. arXiv preprint arXiv:23077 13854, 2023.
Wang. 7. 7., Mao, J., Fried, D., and Neubig, G. Agent workflow memory. arXiv preprint arXiv:2409.07429, 2024b.
Wei, J., Wang, X., Schuurmans, D., Bosma, M., Xia, F., Chi, E., Le, Q. V., Zhou, D., et al. Chain-of-thee of-thoof- prompting elicits reasoning in large language models. Advances in neural information processing systems, 35:24824-2486 24837, 2022.
Xie, T., Zhang. D., Chen, J., Li, X., Zhao, S., Cao, R., Hua, T. J., Cheng, Z., Shin, D., Lei, F., et al. Os- world: Benchmarking multimodal agents for open-ended tasks in real computer environments. arXiv preprint arXiv:2404.07977 2024.
Xu, C., Sun, Q.. Zheng. K., Geng, X., Zhao, P., Feng, J., Tao, C., and Jiang, D. Wizardlm: Empowering large language models to follow complex instructions. arXiv preprint arXiv:2304. 12244,2240,,
Yang, K., Liu, Y., Chaudhary, S., Fakoor, R., Chaudhari, P., Karypis, G., and Rangwala, H. Agentoccam: A sim- ple yet strong baseline for 11m- based web agents. arXiv preprint arXiv:2410. 13825, 2024a.
Yang. Z., Li, P., Yan, M.. Zhang, J., Huang, F., and Liu, Y. React meets actre: Autonomous annotations of agent trajectories for contrastive self-training. arXiv preprint arXiv:2403. 2024b.
Yao, S., Chen, H., Yang, J. and Narasimhan, K. Webshop: Towards scalable real-world web interac- tion with grounded language agents. arXiv preprint arxiv:2007.02266, 2022a.
12

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizan Tasks
A. Appendix
A.I. Chain Thought Results
Base Model
CoT
Performance (%)
Llama-3.3-70B
X
53.94
Llama-3. 1-8B
/
53.33
QWQ-32B
54.88
A.lama-33--77
57.58
Table Comparison of PLAN-AND-ACE models with/without Chain Shain-of-Thougee Thought. The row shows the performance using a 70B model without the CoT data while the other rows show the performance using the CoT data.
In the 13th of Table 1, it shows the result of adding CoT reasoning the PLANNER and EXECUTOR. As can see, it improves performance by 4.36% and sets new SOTA of 57.58% WebArena-lite.
In order to quantify the improvement from using CoT reasoning, we also finetuned a Llama-3. 1aama-3..--B-iie 1-1---innsttrctt model and QWQ-32B on the exact same data as the model in the 13th row in Table 2. As we can see, the 8B model on the second row performs on par with the non-CoT 70B model on the third row, which shows just how important CoT is.
A.2. WebArena Results
Method
Base Model
Acc. (%)
NNetNav (Murty et al., 2024)
Llama-3. 1-8b
16.3
AutoWebGLM (Lai et al., 2024)
ChaGGLM3-6B
18.2
WebPilot (Zhang et al., 2024b)
GPT-4o
37.2
AgentOccam (Yang et al., 2024a)
GPT-4-Turbo
43.1
AgentOccam-Judge (Yang al., 2024a)
GPT-4-Turbo
45.7
PLAN-AND-ACT
Llama-70B
45.7
PLAN-AND-ACT
QWQ-32B
48.15
Table Comparison of methods on the WebArena benchmark. As you can see, PLAN-AND-ACE performs on-par with other prior work.
We also evaluated our approach on the full WebArena dataset Table As we can see, PLAN-AND-ACT performs better or on-par with most other prior work.
A.3. Web Voyager Results
Technique
Base Model
Acc. (%)
NNetNav (Murty et al., 2024)
Llama-3.1-8h
34.2
OpenWeb (He et al., 2024b)
Idefics2-8b-inss
27.4
Web (He et al., 2024a) (text)
GPT-4-Turbo
44.3
Wilbur (Lutz et al., 2024)
GPT-4-Turbo
52.6
Web (He et al., 2024a)
GPT-4-Turbo
57.1
PLAN-AND-ACT
Llama-3.1-8b
58.08
Agent-E (Abuelsaad et al., 2024)
GPT-4-Turbo
73.1
PLAN-AND-ACT
QWQ-32B
81.36
Table 4. Comparison of techniques on the Web benchmark. PLAN-AND-ACT outperforms all open-source prior work and sets new text-only SOTA on WebVoy.ger.
Furthermore, we evalauted PLAN- AND-ACT on the WebVoyager benchmark by finetuning a llama-3.1 model as well as a QWQ-32B model, which you can see in Table 4. Our goal was to evaluate our approach on weal-world webtasks, as opposed to the simulator based tasks WebArena.
13

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
Since WebVog does have any training data, used the text-only Web Voyager model with GPT-4o collect 1500 synthetic trajectories (Section 4.1) and used QWQ-32B annotate the plans (Section 4.2), CoT reasoning (Section 3.4) and to generate 10k synthetic plans (Section 4.3).
Our 8B model out performs all previous open source models and our 32B model out performs all prior work and sets a new SOTA for text-only WebVoyager
A.4. Planner and Executor Output Examples
Task: "From my stay at Homewood Suites Southpointe, what's the estimated driving time to reach PPG Paints Arena?"
Planner Output
# Stee
Reasoning: From the initial HTML state, I observe that I am on the OpenStrestMap website. The page includes a search input field and direction sign icon that likely allows users to find directions initiate process
between two peints. The first step finding directions.
Step: Initiate the process of finding directions.
## Step
Reasoning: After initiating the direction-finding process, the next step is to input the starting location, which is 'Homewood Suites Southpeinte', This will set the starting point for the directions. Step: Input HHoeeoodd Suites Southpointe' the starting location.
## Step 3
Reasoning: With the starting locatien set, the next step is to input the destination, which is rP2G Paints Arena'. This will set the endpoint for the directions.
Step: Input 'PPG Paints Arena' as the destination.
# Step 4
Roasoning: After setting both the starting location and the dostination, the next step to initiate search for directions. This will generate the directions between the two points.
Step: Initiate the search for ricetions.
## Step
Reasoning: Once the directions are generated, the final step is to analyze the results to determine the estimated driving time from
Homewood Suites Southpointe to PPG Paints Arena. The exact time will be displayed on the results page.
Step: Analyze the results to determine the estimated driving time from Homewood Suites Southpointe to PPG Paints Arena.
Executor Output
Output 1:
81 ement::: the rection sign the right side of the Go icon do iaction=",,,ck, element="1>")
Output 2:
# Element: The field the beginning, located in the upper left corner
do (ayt:onn"TTpe", argument- "egument="Homeewee "Homewood Suites Southpointe",
14

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizan Tasks
"lement="13")
Output 3:
Element: The field Labeled "To' at the top leit do (action="Type", argument="PPG Paints Arena", element="14")
Output 4:
Element: The Go button do (action="Click", element="16")
Output 5:
Note: Distance: 29km. Time: 0:34. exit (message="The estimated driving time from Homewood Suites Southpointe to PPG Paints Arena is 0:34.")
Task: "Create a shipping report from 08/05/2022 to 03/01/2023"
Planner Output
# Step
Reasoning: From the initial HTML state, I observe that I am the Magento Admin Panel homepage. The page has left sidebar navigation menu with several sections including 'Dashboard', 'Sales', 'Catalog', 'Customers', 'Karketing', 'Content', 'Reports', 'Stores', and 'System'. Each section appears to be elickable, and some have nested subsections visible through expandable lists. The main content area shows dashboard with various widgets including revenue statistics, tax information, shipping details, and quantity metrics. To create shipping report, need to navigate the 'Rpports' section in the left sidebar and then access the 'Shipping' report option.
Step: Navigate to the 'Reports' section and access the 'Shipping' report optien.
Step
Reasoning: To generate the shipping report for the specified date range, we need to input the 'From' and "To' dates. The 'From' date should be set to 08/05/2022 and the "To' date should be set to that the report covers the desired
03/01/2023. This will period.
Step: Input the date range for the shipping report from 08/05/2022 to 03/01/2023.
Step
Reasoning: After setting the date range, we need to generate the report by clicking the "Show Report' button. This will display the shipping report for the specified period.
Step: Generate the shipping report by clicking the Show Report' button.
## Step 4
Reasoning: Once the report is generated, need to ensure that all relevant information is visible. This step ensures that the complete report details are accessible.
Step: Ensure that the complete shipping report details are visible.
15

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
HP Step 5
Reasoning: Finally, we need to exit the task by providing a message that the shipping report for the specified date range has been created. This step concludes the task and informs the of the successful completion.
Step: Exit with a message indicating that the shipping report for the specified date range has been created.
Executor Output
Output 1:
:lement: the 'Reports' tab left sidebar menu do laction="Click", element="7"))
Output 2:
Blement: the "Shipping' link under the 'Sales' section do (action="Click", clement="18")
Output 3:
A Blement: the "From' input field in the 'Filter' section do (action="Type", argument==08/05/2022 clement="24"))
Output 4:
# Element: the 'To' date input field in the 'Filter' section do (action="Type", azqumen==003/01/2222 element="27"))
Output 5:
A Blements the Show Report' button located at the top right area of the Shipping Report' section do (action="click", clement="16"))
Output 6:
do (action="Scroll) Down")
Output 7:
exit (message="The shipping report from 08/05/2023 to 03/ 01/ 0//001/22223 has been created.")
A.5. Replanner Examples
1. QUERY REFINEMENT
This section presents an example of how a replanner refines an initial plan when an execution failure occurs.
16

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
Task: "How long does it take walk from Carnegie Museum of Art to library CMU?"
Initial Plan
#4 Step Reasoning ng: Prom the initial HTMI, state, observe that am on the OpenStreetMap website. The page includes search input field. The first step is search for libraries CMU to identify which we'll get directions to. Step: Search for libraries at CMU.
#4 Step 2
Reasoning: After finding the libraries CMU, we need analyze search results to identify the available libraries and select one for getting directions.
Step: Review the search results and select library at CMU.
Step
Reasoning: Now that we have identified a specific library, we can initiate the process of finding directions between the two points. Initiate the process of finding directions.
Step:
#4 Step
Reasoning: After initiating the direction-finding process, we need to input the starting location, which is 'Carnegie Museum of Art'. Step: Input 'Careegie Museum of Art' the starting location.
## Step 5
Reasoning: With the starting location set, we need to input the selected library as the destination. Step: Input the selected CMU library as the destination.
# Step 6
Reasoning: To ensure that the directions provided for walking, need to select the appropriate option for walking directions. step: Select the option for walking directions.
AM Step 7
Reasoning: After all parameters are set, we can analyze the results to determine the walking time between the two locations.
Step: Analyze the results to deternine the walking time from Carnegie Museum of Art to the selected CMU library.
Executor's s Actions: The executor attempts to search for libraries at CMU by performing the following actions:
# Element: the search bar da (action==ff (action="Searaa" axgument="Librase at CMU", element="
Element: the search button
do (action="Click", element="13")
However, upon executing this step, the system receives the following **HTML response**, which indicates that search results were found:
<htm1>
<li id="17" results found"> No results found </1i>
</htm1>
17

---

Reasoning: With the list potential libraries identified, next step is to get directions to each library from Carnegie Museum of Art. This will help in determining the distance and time required to reach each library, allowing us to identify the closest one. Carnegie PLAN-AND-ACT: Improving Planning of Agents for Long- Long-Horizon Tasks
This failure necessitates refinement of the plan.
Replanning Refining the Search Query: Since the initial search query ("Library at CMU") returned no results, the replanner modified the query to more general term: "Library near CMU" to improve the likelihood of retrieving relevant results.
Refined Plan
## Step
Reasoning: From the current HTML state, I observe that the page shows search results with 'No results found' (element with id-' 17'). The page contains search bar (id='12') and a Go button (1d='13') for initiating new searches. There's also a direction sign icon (id='14') that likely allows for finding directions between two points. The main content area provides information about
OpenStreetMap and its contribators. Looking at the previous actions,
that the user attempted search for 'Library CMD' and clicked the Go butten, but this broad search query including 'Library at CMU' returned no resuits. This indicates that need to modify our approach Given these observations and the failed previous search attempt, need refine our search query by removing the "Library CMU specification and focusing more specifically on libraries near CMU to get more relevant results.
simplifying the search terms.
Step: Refine the search query by focusing on libraries near CMU.
Step
Reasoning: After refining the search query, we need to analyze the search results to identify potential libraries that are near CMU, This will help in determining the closest library based on the search results.
Step: Analyze the search results to identify potential libraries near CMJ.
## Step 3
Step: Get walking directions each identified library from Museum of Art.
## Step 4
Reasoning: After obtaining the distances and times for each library, the final step is to identi fy the closest library based on the recorded distances and provide the result to the user.
Step: Identi ff the closest library based on the recorded distances and provide the result to the user.
Executor's s Next Action According to the Refined Plan: To reflect the updated strategy, the executor modifies its search action:
do (actiio=" argument= "Library near CMU", element=112")
18

---

PLAN-AND-ACT: Improving Planning of Agents for Long- Long-Horizon Tasks
A.5.2. ANALYZING SEARCH RESULTS MEMORY (AGGREGATING RESULTS ACROSS MULTIPLE PAGES)
This section presents an example of how replanner refines an initial plan when broad high-level step, such as "analyze the search results," needs to be refined into concrete actions.
Task:
"Present the monthly count of successful orders from Jan to December 2022 in MM:COUNT format"
Initial Plan
AA Step Reasoning: From the initial HTML state, observe that am on the Magentio Admin Fanel homepage, The page has left sidebar navigaticn menu with several sections including 'Dashboard', 'Sales' 'Catalog',
'Customers', "Marketing', 'Content', 'Reports', 'Stores', and 'System'. Each section appears to be clickable and some have nested subsections visible through expandable 1ists. The main content area shows & dashboard with various widgets including revenue statistics, tax information, shipping details, and quantity metries. To access the order reports, we need to navigate through the 'Reports' section in the 1eft sidebar, where we can then find and select the 'Orders' report option under the 'Sales' section.
Step: Navigate to the 'Orders' report section under the 'Reports' section.
## Step 2
Reasoning: To generate the report for the specified period, we need to set the date range from January 2022, December 31, 2022. This involves entering the start and end dates the respective date picker input fields.
Step: Set the date range from January 1, 2022, to December 31, 2022.
## Step
Reasoning: To ensure the report generated for the correct period, we need to select the 'Month' option from the 'Period' dropdown. This will aggregate the data on monthly basis.
Step: Select the 'Month' option from the 'Period' dropdown.
A1 Step
Reasoning: After setting the date range and period, we need to generate the report by clicking the "Sho Report' button. This will display the order report for the specified peried. step: Generate the report by clicking the 'Show Report' button.
## Step 5
Reasoning: Once the report is generated, we need to analyze the results to identify fy the monthly count of successful orders from January December 2022. This involves viewing the report and noting the counts for each month.
Step: Analyze the report results to identify the monthly count of successful orders irom January to December 2022.
AM Step 6
Reasoning: After identifying the monthly counts, we need to provide the results in the COUNTT format. This involves exiting with message containing the monthly counts for each month from January December 2022.
Step: Exit with a message containing the monthly counts of successéul orders from January to December 2022 in the 'MM:COUNT' format.
Executor's Actions: The executor follows the plan up until the broad "analyze the report results" step:
R1ement: the REPORTS sectiondo (action ic", el 22lmmnt="7'"
19

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
Element: the 'Orders' report optiondo (action-"Click) element="15")
Element the 'From' datedo (action==Type", argument==01/01/2022, =lement=*24")
# Element the 'To' datedo (action=""")""" 2zgumont="12/31/2022 element=*27")
Element: 'ontt' in the dropdown
do "laction=SSelen" Dropdown Option", argument= "Monthh,, element "222")
# Klement: Show Report' do (action=""lick", element="16")
The executor reaches the analysis step, but the broad instruction to "analyze the report" needs refinement.
Refining the Analysis Task: The replanner observes that the executor requires step-by-step guidance to extract the relevant order counts. It refines the broad analysis step into structured data extraction.
Replanning
First Replan
First step of the replan:
I Step 1
Reasoning: The report results new visible, and need to analyze the order ccunts for each month. The report is structured list, where each row contains a month and the corresponding order count. The first step is to start extracting data from the initially visible rows. The extracted counts so far are: 01:11, 02:16, 03:14, 04:8
Step: Extract the order counts from the initially visible rows.
Next executor action:
do (action="Scrol) Down")
Second Replan
First step of the replan:
Step
Reasoning After capturing the first set of order counts, need to scroll down to reveal more entries. As new rows become visible, I will extract and record their data. The additional extracted counts
05:8, 06:13, 07:9, 08:8, 09:10, 10:4
Step: Scroll down and extract the next set of order counts.
Next executor action:
do (action=*) "ocooonn"srroll Sccoll Down")
Third Replan
First step the replan:
20

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
## Step 1
Reasoning: The final set of order counts needs to be retrieved. I will scroll down again, ensuring capture all rema ning visible data. The final extracted counts are:
11:11, 12:10
Step: Ferform a final scroll to capture any remaining order counts.
Next executor action:
exit (message-"1he "The monthly count of successful orders from Jan to December 2022 is: 01:11, 02:16, 03:14, 04:8, 05:8, 06:13, 07:9, 08:8, 09:10, 10:4, 11:5, 12:10")
A.6. Planner Prompt
Planner has system prompt where its high-level goals are listed; in the user message, it sees the current user query and the initial HTML state.
A.6.1. PLANNER SYSTEM PROMPT
# Goal
You are the Global Planner agent, an expert plan generator for web navigation tasks. You will be proivded with the following information:
+*User Query*+: The web task that you are required to generate global plan for.
++Initial HIML State**: initial HTML state
page.
You are responsible for analyzing the usery query and the initial HTML state to generate structured, step-by-step global plan that outlines the high-level steps to complete the user query. The global plan that you generate shouldn't directly describe Low-level web actions such as clicks or types (unless necessary for clarity) but outline the high-level steps that encapsulate one or more actions in the action trajectory, meaning each step in your plan will potentially require multiple actions to be completed. Your global plan will then be handed to Executor agent which will perform lox-level web actions on the webpage (click, type, hover, and more) to convert your global plan into a sequence of actions and complete the user query.
Expected Output Format The global plan you generate should be structured in a numbered 1ist format, starting with '# Step I' and incrementing the step number for each subsequent step. Each step in the pian should be in this exact format:
...
Step
Reasoning: |Your reasoning herel Step: (Your step here]
Here is breakdown of the components you need to include in each step of your global plan as well as their specific instructions:
Reasoningr:: In this section, you should explain your reasoning and thought process behind the step you high-level justification for why the actions in this step are grouped together and how they contribute to achieving the overall goal. Your reasoning should be based on the information available in the user query (and potentially agent in understanding the strategic deciaion-making process behind your global plan.
proposing.
should provide
the initial ETML state) and should guide the Executor
21

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
SteppA: In this section, you should provide a concise description of the global step being undertaken. Your step should summarize one or more actions as a logical unit. It should be specific and concentrated as possible. Your step should focus the logical progression of the task instead the actual low-level interactions, such as clicks or types.
# Guidelines:
Ensure every action and reasoning aligns with the
query, the webpage hand, and the global plan, maintaining the strict order of actions.
Minimize the number of steps by clustering related actions into high-level, legical units. Rach step should drive task completion and avoid unnecessary granularity redundancy. Focus on logical progression instead of detailing lox-level interactions, such clicks or UI-specific elements. Provide clear, specific instructions for each step, ensuring the executor has all the information needed without zelying on assumed knowledge. For example, explicitly state, 'Input ' 'New York' as the arrival city for the flights,' instead of vague phrases like 'Input the arrival city.'
You can potentially output steps that include conditional statements in natural language, such as 'If the search results exceed 100, refine the filters to narrow down the options.' However, avoid overly complex or ambiguous instructions that could lead to misinterpretation.
High-Leved Goals Guidelines:
Focus on high-levei goals rather than fine-grained web actions, while mai maintaining speci ficity about what needs to be accomplished. Each step should represent meaningful unit of work that may encompass multiple low-level actions (clicks, types, etc.) that serve common purpose, but should still be precise about the intended outcome, For example, instead of having separate steps for clicking a search box, typing a quezy, and clicking search, combine these into single high-level but specific step like "Search for product in the search box".
Group related actions together that achieve conmon sub-goal. Multiple actions that logically belong together should be combined into a single step. For example, multiple filter-reiated actions can be grouped into a single step like "Apply price range filters between $1C0-$200 and select 5-star rating". The key
identiff actions that work together accomplish a specitic objective while being explicit about the criteria and paraneters involved.
Focus describing WHAT needs to be accomplished rather than HOW it will be implemented. Your steps should clearly specify the intended outcome without getting the mechanics of VI interactions.
executor agent will handle translating these high-level but precise steps into the necessary sequence of granular web actions.
Initial HIML State Guidelines:
the initial HTML of the webpage as reference provide context your plan. Since this is just the initial HTML, possibly only a few of the initial actions are going to be taken on this state and the subsequent ones are going to be taken on later states of the webpage; however, this initial НTи-, should help you ground the plan you are going generate (both the reasoning behind individual steps and the overall plan) in the context of the webpage at hand. This initial HDM,, should also help you ground the task description and the trajectory of actions in the context of the webpage, making it easier to understand the task. You MUST provide an observation for the first step of your global plan, including the elements, their properties, and their possible interactions. Your observation should be detailed and provide clear understanding of the current state of the HTML page.
the initial HTML state in your reasoning
# Formatting Guidelines:
Start your response with the *# Step 1' header and follow the format provided in the examples.
22

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
Ensure that each step is clearly separated labeled with the (Ad Step header, where N is the step number. Include the 'Reasoning' and 'Step' sections in each step.
A.6.2. PLANNER USER MESSAGE
# User Query (user_query
Initial HTML State (initial_htmllstarc
You MUST start with the *## Step 1' header and follow the format provided in the examples.
A.7. Executor Prompt
Executor follows the WebArena- defined executor prompt where each user-assistant message pair represents an HTML- action round. The only addition we have is to the system prompt which describes what plan is.
A.7.1. EXECUTOR SYSTEM PROMPT
Goal
You are the Executor Agent, a powerful assistant can complete complex web
navigation tasks by issuing web actions such as clicking, typing, selecting, and more. You will be provided with the following information:
+Task Instruction The web task that you are required to complete.
G+olbal Plan**; high-level plan that guides you complete the web tasks.
*Previous action trajectery*4: A sequence of previous actions that you have taken in the past rounds.
**Current HTML**: The current HTML of the web page.
Your goal is to use the Global Plan, previcus action trajectory, and the current observation to output the next immediate action to take in order to progress toward completing the given task.
Task Instruction: (intent)
Global Plan
The Global Plan is structured, step-by-step plan that provides you with roadrap to complete the web task. Each step in the Global Plan (denoted the step number) contains a reasoning and a high-level action that you need to take. Since this Global Flan encapsulates the entire task flow, you should identify where you are in the plan by referring to the previous action trajectory and the current observation, and then decide the next action take. Here is the Global Plan for the your task:
'A step X where
[global_plan)
A.8. Plan Data Annotator Prompt
Similar to the planner prompt, there is a system prompt that defines the goals of the plan annotator; and the user message provides the user query, the initial HTML state, and the action trajectory for which the plan annotator needs to generate plan.
23

---

Expected Output Format PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
1. PLAN DATA ANNOTATOR SYSTEM PROMPT
* Goal
are the Global Planner agent, expert plan generator for web navigation tasks. You will be proivded with the following information: **User Query**: The web task that you are required to generate global plan for.
+*Initial HIMI State**: The initial HTML state the page.
**Trajectorre=: A sequence of actions that represent a trajectory navigation task. It is formatted as serics of actions where each action first has a comment ('#1) that describes the element to be Interacted with note what provides some context about the action and the current task state. The action is then described with the do function, which takes arguments: the action to be perforndd, the element to be interacted with, and sometimes an argument. The actions are numbered sequentially to indicate the order in which they should be executed.
a web
You are responsible for analyzing initial HTML state and the trajectory provided below and producing a structured, step-by-step global plan that clusters multiple actions into the fewest number of logical steps possible. The global plan that you generate shouldn't describe fine-grained web interactions such clicks types but outline the high-level steps that encapsulate one or more actions the trajectory, meaning each step your plan will potentially require multiple actions to be completed. You will also be tasked to classify each action in the trajectory with one of the steps in your global plan. Each of your steps will be handed to another executor agent that will convert your step into fine-grained web interactions/ hence, your steps should include every speci fic information needed for completing eging the task without assuming the executor agent has access to the whole task or trajectory.
The global plan you generate should be structured in a numbered list format, starting with 'H Step l' and incrementing the step number for each subsequent step. Each step in the plan should be in this exact format:
...
# Step
Reascning: [Your reasoning here]
Description: [Description of the actions this step covers]
Step: [Your step here]
Actions:
[list action indexes associated with this step]
Here is breakdown of the components you need to include in each step of your global plan well their speci fic instructions:
*easscning In this section, you should explain your reasoning and thought process behind the step you are proposing. It should provide a high-level justification for why the actions in this step are grouped thogether and how they contribute to achieving the overall goal. Your reasoning should be based on the information available (and potentially on the initial ETML state) and should guide the exccutor agent in understanding the stratogic decision-making process behind your global plan.
the trajectory
*escrriptionn:: This section should include a brief description of the actions that are grouped together in this step. You should exactly copy the action descriptions from the trajectory without any modifications additional information. This is to ensure that the executor agent accurately map the actions to the global plan steps. Specifically, every action that you include in your description should include any '1 Element', 'A Note', or "4 Exit' comments that are present in the trajectory as well as their corresponding 'do' functions.
24

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
Step**: this section, you should provide a concise description of the global step being undertaken. Your step should summarize one or more actions from the trajectory as a logical unit. It should be as specific and concentrated possible, without referring to any HTML or UI elements. Your step should focus the logical progression of the task instead the actual fine-grained interactions, such as clicks or types.
**Actions**: This section should 1ist the indexes of the actions associated actions should be grouped under one broader
with this step. one logical step. The indices in this section should exactly match the indices of the actions in the trajectory.
H Examples
Here are some examples of the expected output fermat for the global plan where the input is the task description and the trajectory of actions taken to complete the task and the output is the structured global plan that clusters multiple actions into the fewest number of logical steps possible without sacrificing specificity:
jin_context_exmpples
# Planning Guidelines:
Ensure every action and thought aligns with the trajectory and global plan, maintaining the strict order of actions. Actions should be sequential, with no skipping or misaligament (e.g., avoid assigning con-consecutive actions like Step 1: [0,3,4], Step 2: [1,21] Deviation from the trajectory's order will be PENALISED!
Minimize the number steps by clustering related actions into high-level, logical units. Each step should drive task completion and avoid unnecessary granularity or redundancy. Focus on logical progression instead of detailing fime-grained interactions, such as clicks or UI-specific elements. Provide clear, specific instructions for each step, ensuring the executor all information needed without relying on assumed knowledge. For example, explicitly state, 'Input 'New York' as the arrival city for the flights,' instead of vague phrases like Input the arrival city.'
You can potentially output steps that include conditional statements in natural language, such "If the search results exceed 100, refine the filters to narrow down the options.' However, avoid overly complex or ambiguous instructions that could Lead to misinterpretation.
High-level Goals Guidelines:
Focus on high-level goals rather than fine-grained web actions, while maintaining specificity about what needs to be accomplished. Each step should represent meaningful unit of work that may encompass multiple 1cw-level actions (clicks, types, etc.) that should still precise about the intended outcone. For example, instead having separate steps for clicking a search box, typing a query, and clicking search, combine these into single high-level but specific step like "Search for product".
common purpose, but
Group related actions together that achieve commen sub-goal. Multiple actions that logicall calically belong together should be combined into single step. For example, multiple filter-re ated actions can be grouped into single step like "Apply price range filters between $1CC-$200 and select 5-star rating". The key is to identify actions that work together accomplish a specific objective while being explicit about the criteris and paraneters involved.
Focus on describing WHAT needs to be accomplished rather than нow it will be implemented. Your steps should clearly specify the intended outcome without getting into the mechanics of UI interactions. The executor agent will handle translating these high-levei but precise steps into the necessary sequence of granular web actions.
Provide clear, specific instructions for each step, ensuring the executor has all the information needed without zelying assumed knowledge. For example, explicitly state, 'Input 'New York" as the arrival city for the
25

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
flights,' instead of vague phrases like "Inpu The action trajectory might include several "scroll down" actions necessary to locate or find an element, but you should not explicitly say "scroll down to find x in your step description. Instead, you can use phrases like "locate X", "find y", "look for 2", similar phrases represent the scroll actions in your step description. The act of scrolling
arrival city.'
not part of the high-level goal but just implementation details, so you should not explicitly mention it in your step description. Example:
BAD plan (mentions scrolling):
'**
Step I: Scroll down to find the "Contact Us! button and el click it
Step 2: Scroll through the 1ist to find the order numbered 1D12344
GOOD plan (avoids menticning scrolling):
step 1: Locate the 'onttcct Us' button and click it step Find the order numbered ID12345 '..
# Initial HIML State Guidelines:
the initial HTML of the webpage as a reference provide context for your plan, Since this is just the initial HIML, possibly only a few of the initial actions are going to be taken on this state and the subsequent ones going to be taken on later states of the webpage; however, this initial HIML should help you ground the plan you are going generate (both the reasoning behind individual steps and the overall plan) in the context of the webpage at hand. This initial HTML should also help you ground the task description and the trajectory of actions in the context of the webpage, making it casier to understand the task. You provide an observation
initial HTML state your reasoning for the first step of your global plan, including the elements, their properties, and their possible interactions. Your observation should be detailed and provide clear understanding of the current state of the нTм. this.
page. Please refer to the examples for more information on how
# Formatting Guidelines:
Start your response with the 'P Step 1' header and follow the format provided the examples.
Ensure that each step is clearly separated and labeled with the 41 Step N' header, where N is the step number.
Include the 'Reasoning', 'Actions that this step covers', Indices of actions', and 'Step' sections in each step.
A.8.2. PLAN DATA ANNOTATOR USER MESSAGE
H User Query [goal_description)
# Initial HTML State finitial_heml_state)
Trajectory
The following is a sequence of actions that represent a trajectory of a web navigation task. It is formatted as series of actions where each action first has comment ('41) that describes the element to be interacted with or note what provides some context about the action and the current task state. The action is then described with the do function, which takes two arguments: the action to be performed, the element to be interacted with,
26

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
and sometimes an argument. actions are numbered sequentially indicate the order in which they should be executed:
(trajectory)
A.9. Synthetic Plan Generator Prompt
Similarly, the synthetic plan generator also has a system prompt that presents the goals of the synthetic plan generator and also provides the seed data examples. The user message specifies how many synthetic plans to generate (from the seed data examples the system prompt).
A.9.1. SYNTHETIC PLAN GENERATOR SYSTEM PROMPT
Goal
You are Plan Data Generater thàt generate synthetic data to train planner language model to be excellent plan generation web navigation tasks. The data that this model going to trained (and hence the data you generate) is going to be in the following format:
**Input**: A user query for web navigation task. **Output**: A high-level global plan to accomplish the task.
You will be given some examples on how the input-output pairs look like and your goal is to generate new data pairs that are similar to the examples given. Your goal is to increase the data di diversity by covering wide queries while also grounding your data generation
range of possible process on the specific website that the examples are based on, You shouldn't just copy the examples since that would not help the model generalize better but possible the webaite. You must use the given examples to infer what is possible on the website and ground your generated data on it.
also shouldn't generate data that is not
Expected Output Format
The input-output pairs you generate should be structured follows:
.*.
Data Pair (ii))
User Query:
<user query>
Initial HTML State:
<index of the example whose initial HТM, state you are starting from>
Global Plan: <glcbal plan>
where:
'(iH)) is the data pair number.
*cuser query> is brief description of the task that the user wants to
accorplish on website.
*Kindex of the example whose initial HTML state you are starting from is the index of the example whose initial HTML state you are starting from.
This is just an integer like 1, 3, etc.
><giobll plan> is high-level global plan that outlines the steps needed to accemplish the task.
Instructions
Here are the guidelines to fellow when generating the data:
# User Query Instructions
The User Query is a brief description of the task that the user wants to
accemplish on website. It should be concise and focused on the main goal
of the task. The user query should provide enough context for agent to
27

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
generate high-level global plan to accomplish the task.
| Initial НTM, State Instructions
The Initial HTML State is the HTML representation of the webpage at the beginning of the task. It provides the context for the user query and the global plan. When generating new data, you should choose the initial ATML state of one of the examples that you want to start from and provide the index of the example whose initial HIML state you are starting from. This will ensure that the generated data is grounded in the context of the specific website and HTMLs that the examples are based on. You should only provide the index of the example whose initial HTMI, state you are starting from. For example, if you are starting from the second example's initial HTиL state ('4 example 2)), you shou'd provide '2' the initial HTML state.
When generating multiple data pairs, you should ain to use different examples' initial HIML states in a balanced way, While you don't need to use each HTML state exactly equally, you should ensure good coverage across all examples. Some HTML states may enable wider range of user queries and can used more frequently, but you shouldn't completely ignore or heavily underutilize any of the exemples. The goal to leverage the full range of possible HТM states and website functionalities shown in the examples.
Aftering picking which HTML to start from, you MUST provide an observation of the initial HTML state in your reasoning for the first step of your global plan, including the elements, their properties, and their possible interactions. Your observation should be detailed and provide a clear understanding of the current state of the HTML page. Please refer to the examples for more information on how to do this.
Global Plan Instructions
The Global Plan is structured, step-by-step plan that provides high-level everview of the actions that need to be taken to accomplish web navigation task. The plan should be detailed enough to guide the through task but not too detailed that becomes a step-by-stop instruction. In other words, the global plan that you generate shouldn't directly describe low-level web actions such as clicks or types (unless necessary for clarity) but outline the high-level steps that encapsulate one
actions in the action trajectory, meaning each step in your plan will potentially require muitiple actions to be completed. Your global plan will then be handed to an Executor agent which will perform Low-level web actions the webpage (click, type, hover, and more) to convert global plan into sequence of actions and complete the user query.
44 Global Plan Expected Output Format
The global plan you generate should be structured in a numbered list format, starting with 'H Step l' and incrementing the step number for each subsequent step. Each step in the plan should be in this exact format:
# Step N
Reasoning: [Your reasoning here] Step: [Your step here] ...
Here is breakdown of the components you need te include in each step of your global plan well their specific instructions:
*eassoning:::: In this section, you should explain your reasoning and theught process behind the step you are proposing, high-level justification tegether and how they contribute to achieving the overall goal. Your reasoning should be based on the information available in the user query (and potentially
should provide a for why the actions in this step are grouped
the initial ETML state) and should guide the Executor agent in understanding the strategic decision-making process behind your global plan.
++Step**: In this section, you should provide cencise description of the global step being undertaken. Your step should summarize one or more
28

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
actions as a logical unit. It should be as specific and concentrated pcssible. Your step should focus on the logical progression of the task instead of the actual low-level interactions, such as clicks or types.
High-level Goals Guidelines:
Focus on high-level geals rather than fine-grained web actions, while maintaining specificity about what needs to be accomplished. Each step should represent meaningful unit of work that may encompass multiple Lcw-level actions (clicks, types, etc.) that serve common purpose, but should still be precise about the intended outcone, For example, instead having separate steps for clicking search box, typing a query, and clicking search, combine these into single high-level but speci fic step like "Search for product".
Group related actions together that achieve
sub-goal. Maltiple actions that logically belong together should be combined into single step. For example, multiple filter- actions car be grouped into a single step like "Apply price range filters between $1CC-$200 and select 5-star rating". The key is to identify actions that work together accomplish a specific objective while being explicit about the criteria and parameters involved.
Focus on describing WHAT needs to be accomplished rather than HOW it will be implemented. Your steps should clearly specify the intended outcome without getting into the mechanics of VI interactions. Another executor agent will handle translating these high-level but precise steps into the necessary sequence of granular web actions.
Examples
Here are some examples you must utilize to understand what is possible on the website, what kind of actions are executable, what ETML elements are present on the website, and what kind of tasks you can generate data for.
Remember:
1. You are required to take inspiration from these example but not exactly copy them since we want enough diversity to be able to cover a wide variety of use cases.
2. You shouldn't hallucinate or create non-existing elements or actions that are not possible on the website. If you make up something that is not possible the website, you will be penalized. Your data needs to be grounded on the website and the exanpLes given.
(examples_ste |str
A.9.2. SYNTHETIC PLAN GENERATOR USER MESSAGE
Use the given examples to generate
new data
pairs. The data pairs ra you generate SHOULDN'T r be similar to each other. They wide range of possible queries and tasks.
should be diverse and
Output Formatting
You should output the data pairs generate in the following format:
Data Pair (i) User Qucry: <user query>
Initial HTML State:
<index of the example whose initial HIML state you are starting from. Remember this is just an integer like 1, etc.>
Global Plan:
<global plan> '
29

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
Remember
You shouldn't hallucinate or create non-existing elements or act actions that are not possible on the website. If you make up something that is not possible the website, you will be penalized. Your data needs to be grounded the website and the examples given.
You are required to take inspiration from these exemples but not exactly copy them since we want enough diversity to be able to cover a wide variety of use cases. However, while trying to create diverse data, you MUST avoid making up non-existing elements actions that are not possible the website.
You MUST provide detailed initial HTM, state observation for the first step of your global plan.
A.10. Training Data Failure Classification Prompt
For classifying the training data based on the failure classes we identified, we have the main system prompt which defines the goal of the classification model. Each website has its own failure classes. If the model classifies training data point into any one of these classes, keep that data point for the next round of synthetic data generation.
A.10.1. MAIN SYSTEM PROMPT
# Goal
You are an expert classifier model tasked with classifying data points that were used to train a "Planner" mode". This model was trained to take in user query (or a task) related connon webaites such shopping websites, Reddit, GitLab, etc., and output high-level global plan for completing that task. After training, we conducted a failure analysis to identify the types of errors the planner was most prone to.
Now, using identified failure classes, we aim to label the training points of the global planner. The purpose of this classification is to determine which data points can be leveraged to generate synthetic data. This synthetic data will be used to retrain the planner, helping it correct its mistakes and avoid previous failures.
For each data point, you will receive:
The website name: e.g., "shopping_admin""
A user query (task) The user query task that the planner is supposed to complete
A ground truth global plan: The global planner was trained to generate this plan for the given user query.
Remember:
The data points that will be given you going to perfect (they are from the training data): They are going to be the best possible plans that the planner can generate. Hence, your job is not to classify the data point itself into a failure class but rather identify whether this data point is good example to train the planner to generate better plans and which failure class will potentially help the planner avoid.
Your job:
1) Read the given user query and the plan carefully
2) Icentify what this data points is trying to do and what the planner
model learn from being trained on this data point and data points like it
3) Provide clear reasoning for your classification decision
4) Classify the data point into one of the known failure classes for that website "Other" if no class fits; specifically, you should classify the failure class that this data point will help the planner avoid if it
trsined on this data point and data points like it
Below is the set of possible classes for the website: sobbittevvalue.
celassificaiionneee section www.tiiooooooweeeeeeeoooooooo for_website)
30

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
General guidelines:
1. Carefully check the user query and plan
2. Match them against the class definitions
3. If of the classes apply, label "Other"
4. Provide your output the following format:
# Reasoning
[Explain your thought precess and why this example fits the chosen class]
# Classification
[Class 1abel: "Class A", "Class ,", "Other", etc.]
Please your output follows this exact format.
Here are the prompts for the failure classification model for each website separately. Each failure class was identified by looking at our model's performance on the validation set:
1.10.2. SHOPPING ADMIN (CMS) FAILURE CLASSES
Here the classes for the shopping admin admmn website:
Shopping Admin Website Classes
#1 Class Search Query Optimization Failures
**# Description
The planner fails to implement proper search query strategies, particularly:
Using overly specific search terms without fallback to broader terms Not utilizing the search functionality effectively when simpler queries would work
Missing critical search parameters or using irrelevant ones
# Training Data Needed
Examples showing fallback to broader search terms specific searches fail
Cases demonstrating effective use of search functionality with simpler queries
144 Example Tasks
1. "Show me the name of the customers who have expressed dissatisfaction with Chloe tank"
- -Error: Planner used exact "chloe tank" search instead of broader "chloe" search that would have found "chioe plastic tank"
2. "List the top 3 search terms in my store"
Error: Planner incorrectly included date filtering steps which don't exist in searen terms report Solution:
Training data showing correct navigation of "search terms" report without date filtering
#* Class B: Product Attribute Update Confusion
**# Description
The planner confuses high-level status changes with specific attribute updates: Using "Chango status" action instead of updating specific product attributes Attempting to modify stock/pricc/sall status through wrong interface clements
#* Training Data Needed
Examples showing correct attribute updates for sales status Cases demonstrating proper stock level modifications
Examples distinguishing between status changes and attribute updates
31

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
444 Example Tasks
1. "Mark all Hollister shirts on sale"
Error:
Planner used general status change instead of specific sale attribute update
Solution:
Training data showing how update sale attributes
specifically using 'update attributes' option
2. "Make all Acno capri as cut of stock" Error: Planner tried using Enable/Disable status instead of stock attribute
Solution: More examples of updating product attributes vs changing status
# Class C: Review Analysis Navigation Failures
*** Description
The planner fails to properly navigate and analyze product reviexs: Missing steps to access preduct review secticns Failing to specify review content examination steps
including steps gather specific review details
**# Training Data Needed
Examples showing navigation product review sections
Cases demonstrating preper review content analysis Examples gathering specitic review details
*** Example Tasks
1. "Tell me the reasons why customers like Circe's products"
Planner dión't include steps access and analyze review content Solution: Training data shewing how navigate to and analyze zeview sections
Error:
H Other Description: If none of the above classes match.
A. 1..... REDDIT FAILURE CLASSES PROMPT
Reddit Website Classes
# Class A: Content Reposting Strategy Failures
## Description
The planner fails implement correct reposting workflow:
Missing steps to access repost functionality Creating new posts instead of using repost features Incorrect navigation for cross-posting
#* Training Data Needed
Examples showing proper repost functionality usage
Cases demonstrating cross-posting workflows
44 Example Tasks
1. "Rc-post the image of costume contest to funny subreddit"
-Error: Planner created new post instead of using existing repost functionality
Sclution: Training data showing correct repost/crosspost workflow
# Other Description: If none of the above classes match.
A. 10.4. GITLAB FAILURE CLASSES PROMPT
32

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
GitLab Website Classes
# Class A: Issue/MR Navigation Strategy Pai Tures
#4 Description
The planner fails to use proper navigation paths for issues/merge requests:
Using global search instead of dedicated Issues/MR sections
Not utilizing proper filtering tabs (0pen/Closed/ALI)
Missing steps to access personal issues/MRs through correct interface
#4 Training Data Needed
Examples showing navigation through Issues/MR tabs
Cases demonstrating preper of filtering options
Examples accessing personal issues/MRs
** Example Tasks
1. "Open my latest created issue that has homepage content in its title" Planner used glcbal search instead of navigating through Issues tab and filters
Error:
Solution:
Training data showing navigation through Issues section with proper filtering
2. "Checkout merge requests requiring my review" Error:
Planner attempted repository search instead of using MR section with revicw filter Solution: Examples showing how to access personal merge requests
# Class B: Profile/Project Settings Navigation Errors
#*# Description
The planner fails to locate correct paths user/project settings: identifying correct navigation path for profile settings Missing steps to access specific project settings sections
Using non-existent UI elements for status/member management
** Training Data Needed
Examples showing correct profile settings navigation
Cases demonstrating project member management
Examples of updating user status through correct paths
## Example Tasks
"Set my gitlab status as Enjoying life"
Error: Planner looked for non-existes stent "Adit status" button instead of profile settings path
update profile settings and status 2. "Create a new public project and add members" Error:
Solution:
Training data showing
Planner tried accessing members through settings instead of project information page Solution:
Examples showing correct project member management workflow
# Class C: Repository Analysis Strategy Failures
**# Description
The planner fails implement proper repository analysis strategies:
Not utilizing correct sorting/tiltering for
Missing steps to access personal repositories section
Incorrect navigation for contribution analysis
#4 Training Data Needed
Examples showing repository sorting by stars
Cases demonstrating personal repository filtering
Examples analyzing repository contributions
33

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
444 Example Tasks
1. "Tell me the repositories where made contributions with most stars" Planner didn't navigate to personal repositories section for proper star filtering
Error:
Solution: Training data showing how filter and personal repositories
# Class D: Commit Sectien Access Errors
#*# Description
The planner fails to properly access the commi ts section of the repository Not identifying the correct path to the commi ts section Missing steps to filter commits by date and author Incorrect navigation for commit history analysis
**# Training Data Needed
Examples showing correct navigation to the commits section Cases demonstrating filtering commits by date and author Examples analyzing commit history
#*# Example Tasks
1. "How many commits did Eric and Kilian make to allyproject 1/3/2023?"
Error:
Planner dien't navigate to the commits section apply correct filters
Solution: Training data showing how to access the commits section and filter by date and author
Other
Description: If none of the above classes match.
A.10.5. SHOPPING (OSS) FAILURE CLASSES PROMPT
Shopping Website Classes
Class Account Feature Navigation Failures
#*# Description
The planner fails to locate specific account-related features:
Missing steps to access newsletter subscriptiens identifying correct paths for account settings Incorrect navigation for personal features
#* Training Data Needed
Examples showing navigation newsletter subscriptions Cases demonstrating account settings access Examples of personal feature management
## Example Tasks
"Subscribe to the newsletter of OneStopMarket"
Error: Planner dión't identify path through account settings to newsletter subscription
Solution: Training data showing navigation to newsletter subseription section
# Class B: 'Advanced Search' Feature Indorutilization
### Description
The planner fails effectively
'advanced search" functionality: Not utilizing price range filters in advanced search
Missing steps to combine category and price filtering
Using basic search when advanced search would be more efficient
34

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
444 Training Data Needed
Examples showing proper use of advanced search with price filters
Cases demonstrating categery price range filtering
Examples of complex search criteria using advanced search
#*# Example Tasks
1. "Show me products under $30 in men shoes' category"
Error: Planner used basic search instcad of 'avvanced search! with price filter
Solution: Training data showing how use advanced search with category
and price range filters
2. "Buy the highest rated preduct from the meat substitute category within $100-200"
Error: Planner dien't utilize 'advanced search' price range functionality Solution: Examples showing how to combine category, price range and rating filters
Other Description: If none of the above classes match.
1.10.6. MAP FAILURE CLASSES PROMPT
Map Rebsite Classes
# class A: Location Search Strategy Failures
**# Description
The planner fails to properly handle tasks requiring location search before directions:
Not searching to resolve generic/unseeitted Location references (e.g., "nearest coffee shop", "a library")
Attempting to get directiens before resolving arbiguous locations through search
-Msssnn steps to select specific locations from search results when generic terms are used
#*# Training Data Needed
Examples showing proper workflow for resolving generic location references before getting directions
Cases demonstrating search and selection when both endpoints are not specifically naned
#*# Example Tasks
"Show me the walking distance from nearby hotels to Gardner Steel Conference Center"
Error: Planner jumped to directions without first searching for nearby hotels
Solution: Training data showing how to search for nearby locations before getting directions
2. "How long does it take to walk from Carnegic Museum of Art to 1ibrary at CMJ"
Error: Planner tried direct routing without first identifying specific library location Solution: Examples showing how to search for and select specitic destinations
# Other
Description: If none of the above classes match. For example, if the data point contains a simple direction finding task between already named iccations, it should be classified as "Other".
35

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
A.11. Synthetic Plan Generation after Failure Analysis
After the failure analysis and the training data classification, objective now is to generate data that is similar to the seed data (instead of generating diverse data). That is why this part has a slightly different prompt than the prompt above for the synthetic plan generator prompt at Appendix A.9. For each seed data point, we generate one more synthetic plan.
Goal You are Data Generater tasked with producing one synthetic data point from a single provided example. The new data point should:
1. **Preserve the same cere user intention** the original example. Avoid changing the main purpose high-level goal of the user. **Introduce minor variatiens** details such as product names, numeric valucs, or the user's s phrasing, to ensure the data point is not an exact ссpy.
3. +ssee the same Initial HTML State index** (unless otherwise specified or context that is logically consistent with the original example's ATML environment.
4. **Output a coherent high-level planee that remains grounded in the capabilities indicated by the initial HIML state and the provided example.
Your output must follow this format:
# Data Pair 1
User Query:
<new user query reflecting the same intention
Global Plan:
# Step
Reasoning: conci but clear explanation of how you' building upon the initial нТMЗ state and addressing the user's a goal]
step: [A high-level step aimed at fulfilling part of the user's s request.]
# Step
Reasoning: [...]
step: [...]
:.:
# Important Details
**Maintain the same overall user goal*s. Do not drastically alter the user's s end objective. For example, if the user originally wanted to "update the stock levels of product," keep that high-level aim. **ereeev exact VI element names**; Never medify:
Button names and labels
Form field identifiers Page names and URLs
Specific
element IDs classes
Any technical identifiers used in the website
* Vary only non-technical details**. Changes should be limited to: User's writing style and tone
Generic product descriptions
Numeric values (when not referring specific elements)
General context that doesn't involve UI elements
Language Variation Requirements
*<iversee Query Perspectivesr:: Generate queries from different viewpoints such as:
36

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
Direct requests: need to..."
Question format: "Could you help me..." Task-oriented, "Look for..."
Casual tone: "Hey, I want to..."
Sentence Structure Variationa::
Vary between simple, compound, and complex sentences
Mix up word order (c.g., "The product inventory needs updating" ve "I need to update the product inventory")
Use different transiticnal phrases and connectors *+ooabblarry Diversity**:
Use synonyms and alternative expressions ons for common actions (e.g., "rodify", "change", "update", "revise", "adjust") Vary between formal and informal language styles
Avoid copying phrases verbatim from the example **Vary the objects, names, and locations** use different places, repositories, titles, products, ids, etc. **NEVVR modify the UI element names** (see the list above in '4 Important Details')
the user query. For example,
**ee the global plan structured and concise*.. Each step should provide high-level sub-goal ("Apply filters", "Navigate to product page", "Update attributes", etc.), and group logically related actions together. Try not to change the plan of the given exanple too much since those plans are ground truth exanples that want to generate more data similar to order for the Planner to become better at that specific task.
*easoniig sections** in each step should briefly explain the sub-goal and how it connects to the overall intention, referencing any relevant elements from the initial HTML state necessary.
*Noo hallucinations of features or VI elements not present in the initial HTML state. Stay aligned with the existing structure and capabilities.
Given Example (example_str)
Task
Generate **singlex* new data point that preserves the user's main goal but changes details. Output exactly the format described above while ensuring linguistic diversity in the generated content.
A.12. Replanner Data Annotator Prompt
For the replanner data annotation, provide all the previous plans, the current HTML state, and the future actions the model and we ask it to generate replan grounded on the future actions. For this, we have system prompt that defines the goals of the replanner and we represent the previous rounds of replan as user-assistant messages, similar to how the Executor treats each assr-assistant message pair as an HTML-action pair in Appendix A.7.
A. A. SYSTEM PROMPT
# Goal and Rules
You are the Global Planner agent, an expert plan generator for web navigation tasks, responsible for providing high-level plans to help users achieve their goals on a website. You will be assisting user who is navigating a simplified web interface to complete task. The user will interact with the website by clicking actions. You will be given:
elements, typing text, and performing other
+Ueer Query++: The web task that you are required to generate global plan for.
**HMM*** The current HTML state of the web page.
*Previous Actions**: The previous actions that the user taken.
**Future Actions*:: The future actions that the user will take.
37

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
At each round user-web interaction, you will generate structured plan based on the user's previous actions and the required future actions. Your geal is to:
1. Cluster future actions into logical, high-level steps. This need to create steps that describe the overall goal rather than specific fine-grained web interactions (clicks, types, etc.), ,, where each step should encapsulate one more actions in the future trajectory.
that you
2. Classify each future actien under appropriate step
3. Provide sufficient detail for the user to complete each step without assuring prior knowledge
Rules:
For the first round, create complete plan from. scratch
For later rounds, incorporate previous actions reasoning but only plan
future steps
The plan should be updated each round as new actions become available.
Focus high-level geals rather than specific web interactions, unless
needed for clarity
Group related actions logically to minimize the number steps while maintaining clarity
# Expected Output Format
The plan you generate should be structured in numbered 1ist format, starting with *# Step 1' and incrementing the step number for each subsequent step. Each step in the plan should be in this exact format:
Step
Reascning: |Your reasoning here] Step: [Your step here]
Here is breakdown of the compenents you need to include in each step of your
plan as well as their specific instructions:
Reasoningge:: In this section, you should explain your reasoning and thought process behind the step you are proposing. It should provide high-level justi ciation for why the actions in this step together and how they contribute to achieving the overall goal. Your reascning should be based on the information available in the trajectory (both the actions the user has aiready taken and the future actions they should take) and should guide the user in understanding the strategic decision-making process behind your plan.
grouped
Note: In the reasoning section of the first step, you should include an **observation<* of the current ETML state of the task, including the elements, their properties, and their possible interactions. Your observation should be detailed and provide clear understanding of the current state of the нTML page. You should also include a **reflection* on the previous actions that have been taken so far.
Descriptionn:::: This section should include brief description on of the actions that are grouped together in this step. You should exactly copy the action description ons from the trajectory without any rodification or additional infornation. This is to ensure that the user can accurately map the actions to the plan steps. Specifically, every action that you include in your description should include any '# Element', '# Note', or '# Exit' comments that are present in the trajectory as well as their corresponding 'do" functions.
**Step*:: this section, you should provide concise description of the global step being undertaken. Your step should summarize one or more actions from the trajectory as a logical unit. It should be as specific and concentrated as possible, without referring to any ETML or VI elements. Your step should focus the logical progression of the task instead the actual fine-grained interactions, suen as clicks or types.
38

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
Actions*4: This section should list the indexes of the actions associated with this step. One or more actions should be grouped under one broader logical step. The indices in this section should exactly match the indices of the actions in the trajectory.
# Examples
Here are some examples of the expected output fermat for the plan where the input is the user query and the output is the structured plan that clusters muitiple actions into the fewest nunber of logical steps possible without sacrificing speci specificity:
(examples)
Maintain Strict Order of Actions and Be Specific:
**trrict order of actions**: Ensure every acticn and thought aligns with the trajectory and plan, maintaining the strict order of actions. Actions should be sequential, with no skipping misalignment (e.g., avoid assigning non-consecutive actions like step 1: 10, Step [1,2]). Deviation from the trajectory's order will PENALIZED!
speciiii instructionse:: Provide clear, specific instructions for each step, ensuring the user has all the information needed without relying assumed knowledge. For example, explicitly state, "Input "New York' the arrival city for the flights," instead vague phrases like "Input the arrival city"; or instead of saying "Type an appropriate review for the product." you should say "Type II love this product' as a review for the product."
High-level Goals Guidelines:
Focus on high-level geals rather than Fine-grained web actions, while maintaining specificity about what needs to be accomplished. Each step should represent meaningful unit of work that may encompass multiple lcw-level actions (clicks, types, etc.) that serve common purpose, should still be precise about the intended outcone. For example, instoad of having separate steps for clicking search box, typing a query, and clicking search, combine these into single high-level but specific step like "Search for product".
Group related actions together that achieve common sub-goal. Multiple actions that logically belong together should be combined into a single step. For example, multiple tilter-re-ated actions single step like "Apply price range filters between $1CC-$200 and select 5-star rating".
be grouped into
key to identify actions that work together accomplish a specific objective while being explicit about the criteria and paraneters involved.
Focus on describing WHAT needs to be accomplished rather than HOW it will be implemented. Your steps should clearly specify the intended outcome without getting into the mechanics of UI interactions. The executor agent will handle translating these high-level but precise steps into the necessary sequence of granular web actions.
Search Results and Dynamic Content Guidel ines:
CRITICAL: Since you are like data annotator, which is given the ground truth action trajectory, you might be tempted to output steps that di rectly describe dynammic search results that appears in future actions. You MUST NOT do this. User will the trajectory beforehand like you do. Because this, if your task requires you to "search" for something and analyze the search results, you should output high-level steps such as "Analyze the search results for gas stations and note their locations" focus the high-level steps. You will
have access the trajectory
the actions in
"Look through the orders to find
order number 178" and let the have the chance to look at the search results in the future steps when you see them in the current HTML state. Until then, please just reference the search results in nigh-level terms.
Formatting Guidelines:
39

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
Start your response with the "PP Step header and follow the format provided in the examples.
Ensure that each step is clearly separated and labeled with the 4A Step N' header, where N is the step number.
Include the 'Reasoning', 'Description', 'Step', and 'Actions' sections in each step.
A. A.... USER-ASSITTANT MESSAGES
Each round of replanning is formulated as user-assistant message pair where the assistant messages are the previous plans and the user messages are in the following format.
All previous user messages represented in the following format since don't want dump the entire HTML and the future actions into the context:
* Round (index)
** HTML simplified html
#1 Action taken (previous action taken)
# Future Actions Trajectory
** Future actions **
And here is the last user message where we provide the current HTML state and the future actions for which it needs to replan:
# Round (last action index)
(current_ html )taasttee state)
## Future Actions Trajectory
The following is the future trajectory to complete the web navigation task. is formatted as series of actions where each action first has comment ('#') that describes the element to be interacted with or a note which prevides some context about the action and the current task state. The action is then described with the do function, which takes two arguments: the action to be performed, the el element scmetimes an argument. The actions are numbered sequentially to indicate the order in which they should be executed:
interacted with, and
(future (future_ttraecttee trajectory)
You MUST start with the 'M Step header and follow the format provided in the examples.
A.13. Replanner Prompt
Similar the replanner data annotator prompt Appendix A.12, we represent the previous rounds of replans as user- assistant message pairs. The only difference is that the replanner doesn't 'tt know the future actions. Also, it has system prompt that defines the high-level goals of the replanner.
A. 1. SYSTEM PROMPT
40

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
Goal and Rules
You are an expert plan generator for web navigation tasks, responsible for providing high-level plans to help users achieve their goals on website. You will be assisting user who is navigating simplified web interface to complete a task. The user will interact with the website by clicking on elements, typing text, and performing other actions. You will be given:
**User Query*+: The web task that you are required to generate global plan for.
**H The current HTML state the web page.
+rrvvioss Actions**: The previous actions that the user has taken, *Prrvvouus Global Plans*+: The previous global plans generated in the previcus rounds.
At each round of user-web interaction, you will generate structured plan based on the user's previous actions, current HTML state, and the previous glebal plans.
Rules:
For the first round, create complete plan from scratch
For later rounds, incorporate previous actions in reasoning but only plan
future steps
The plan should updated each round new actions become available.
Keep the plan concise and actionable
Focus on high-level goals rather than specific web interactions, unless
needed for clarity
Remember:
since the previous global plans were constructed without. seeing the current state of the итM that you are viewing now, they may include steps that are not needed (e.g., Less efficient, unrelated, or wrong) miss some important actions that where the previous global plan needs to be refined based on the current state of the HTML, your key responsibility is to make the previous plan more specific by:
required to proceed further. In these
1. Identifying which steps from the previous plan based on the current нTML state
possible/viiible
2. Updating those steps with specific details you can now see (e.g., exact items to click, specific text to enter)
3. Removing steps that are longer relevant needed
4. Adding new steps if the current state reveals necessary additional actions
5. Fixing any errors or assumptions based on the current state
6. Adapting the plan if expected elements or results are not found
For example:
If a previous step was "search for products", and you now see search results, update the plan with which specific result to select If previous step was "navigate to section", and you now see the navigation options, specify which exact link/button to use If previous step was "find an item", and item. not found, provide alternative items or navigation paths
Consider the previous glcbal plans when generating the new plan, decide whether make any changes, and provide your reasoning.
# Expected Output Format
The plan you generate should be structured in nurbered 1ist format, starting with #e Step 1' and incrementing the step number for each subsequent step. Each step in the plan should be this exact format:
# Step N
Reasoning: [Your reasoning here]
Step: [Your step here]
...

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
Here is breakdown of the components you need to include in each step of your plan as well as their specific instructions:
Reassoning In this section, you should explain your reasoning and proposing.
thought process behind the step you high-level justification for why the actions in this step are grouped together and how they contribute to achieving the overall goal. Your reasoning should be based on the information available in the trajectory (both the actions the should take) and should guide the user understanding the strategic decision-making proceas behind your plan.
should provide
has already taken and the future actions they
Note:
the reasoning section of the first step, you should include vxobservation the current ETML state of the task, including the elements, their properties, and their possible interactions. Your observation should be detailed and provide a clear understanding of the current state of the HIML page. You should also include a **reflectiones on the previous actions that have been taken far. This reflection should include:
What were the previcus actions that were taken?
were the previous actions successful? How do you know this from the current HTML state? For example, if the previous action was to cype in input field, you MUST reflect whether the input field is now populated with the correct text.
Step+*+: In this section, you should provide a concise description of the global step being undertaken. Your step should summarize one more actions from the trajectory concentrated as possible, without referring to any ETML or elements. Your step should focus on the logical progression of the task instead of the actual fine-grained interactions, such clicks or types.
logical unit. should be as specific and
Specific:
Specific instructions::: Provide clear, specific instructions for each step, ensuring the user has all the information needed without relying on assured knowledge. For example, explicitly state, "Input " "New York' as the arrival city for the flights, instead of vague phrases like "Input the arrival city"; or instead of saying "Type an appropriate review for the product." you should say "Type 'I love this product' as a review for the product."
High-level Goals Guidelines:
Focus on high-level goals rather than fine-grained web actions, while maintaining specificity about what needs to be accomplished. Each step should represent meaningful unit of work that may encompass multiple 1cw-level actions (clicks, types, etc.) that should still precise about the intended outcone. For example, instead having separate steps for clicking a search box, typing a query, and clicking search, combine these into single high-level but specific step like "
common purpose, but
Group related actions together that achieve commen sub-goal. Multiple actions that Nogically belong together should be combined into single step. For example, e, multiple filter-re ated actions can be grouped into single step like "Apply price range filters between $1CC-$200 and select 5-star rating". The key is to identify actions that work together accomplish a specific objective while being explicit about the criteris and paraneters involved.
Focus on describing WHAT needs to be accomplished rather than нOw it will be implemented. Your steps should clearly specify the intended outcome without getting into the mechanics of UI interactions. The executor agent will handle translating these high-levei but precise steps into the necessary sequence of granular web actions.
# Formatting Guidelines:
42

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
Start your response with the "PP Step header and follow the format provided in the examples.
Ensure that each step is clearly separated and labeled with the '4 Step N' header, where N is the step number.
Include the 'Reasoning' and 'Step' sections in each step.
A. 131..2. USER-ASSISTANT MESSAGES
Each round of replanning is formulated user-assistant message pair where the assistant messages are the previous plans and the user messages are in the following format:
All previous user messages are represented in the following format since we don't want to dump the entire HTML into the context:
Previous Actions
** List of previous actions **
HTML
Si simplified html
Here is the last user message where we provide the list of previous actions and the current HTML state upon which the model needs base its replan.
Previous Actions (previous actions of the executor)
HTML (obs)
A.14. WebArena Performance Breakdown
Figure Task performance metries by website.
Website
# Tasks
Avg. Steps (All)
Avg. Steps (Success)
Avg. Steps (Fail)
Success Rate (%)
Overall
165
11.12
7.52
13.43
53.9
GitLab
30
13.70
5.98
20.35
53.3
Reddit
19
9.37
8.31
9.92
84.2
Shopping Admin
35
12.40
8.65
14.41
48.6
Shopping
45
9.87
7.11
10.66
55.6
Map
26
10.00
10.37
9.10
46.2
Multiple Websites
10
11.70
6.00
17.83
30.0
43

---

PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
A.15. Hyperparameters
Training Hyperparameters
Learning Rate
2e-5
Optimizer
AdamW
LR Scheduler
Cosine
Warmup Ratio
0.1
Batch Size
32
Epochs
1
FP16/BF16
Enabled
Machine
8xA100
Framework
torchtune
(a) Training
Inference Hyperparameters
Temperature
0
Framework
vL.LM
Max tokens generated
4196
Maximum sequence length
32000
(b) Inference
Figure Model hyperparameters for training and inference
44


Reviews:
[{"review_id": "FW33qxJD0q", "reviewer": "Reviewer_4dS1", "summary": "This paper introduces Plan-and-Act, a framework consisting of a planner that generates high-level task plans and an executor that translates these plans into specific actions. To deal with unexpected failures, the planner will be involved in updating the plan after each execution step. Besides, a synthetic data generation method is proposed to finetune the planner. Through experiments in the WebArena-Lite environment, Plan-and-Act achieves a state-of-the-art success rate.", "questions": "", "limitations": "", "rating": 3, "confidence": null, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "> R1-1:  The paper only reports the success rate of the methods on the WebArena-Lite benchmark. Additional metrics, such as the average number of steps required to complete a task, would provide a more comprehensive assessment.\n\nBelow are additional metrics, including average steps and a success/failure breakdown, as suggested. To provide a more comprehensive assessment, we have also provided a breakdown comparing successful and unsuccessful tasks across the different websites/tasks. Furthermore, we have run experiments on other datasets including WebVoyager. Please see R2-1 response below.\n\n| Website           | # Tasks | Avg. Steps (All) | Avg. Steps (Success) | Avg. Steps (Fail) | Success Rate (%) |\n| ----------------- | ------- | ---------------- | -------------------- | ----------------- | ---------------- |\n| Overall           | 165     | 11.12            | 7.52                 | 13.43             | 53.9%            |\n| GitLab            | 30      | 13.7             | 5.98                 | 20.35             | 53.3%            |\n| Reddit            | 19      | 9.37             | 8.31                 | 9.92              | 84.2%            |\n| Shopping Admin    | 35      | 12.4             | 8.65                 | 14.41             | 48.6%            |\n| Shopping          | 45      | 9.87             | 7.11                 | 10.66             | 55.6%            |\n| Map               | 26      | 10.00            | 10.37                | 9.10              | 46.2%            |\n| Multiple Websites | 10      | 11.70            | 6.00                 | 17.83             | 30.0%            |\n\n\n\n> R1-2: The proposed framework lacks novelty, as it essentially follows a hierarchical planning approach and utilizes environmental feedback for replanning—both of which are commonly used in planning applications.\n\nWe would like to direct the reviewer to our response R3-4 in our response to Reviewer 3.\n\n\n> R1-3: The experiments are conducted solely on WebArena-Lite, a simulated environment. It would be more informative to evaluate the approach on WebVoyager, which better reflects real-world web behavior.\n\nWe conducted new experiments on WebVoyager, please see R2-1 in our response to Reviewer 2, where Plan-and-Act achieves SOTA results for text-only models on WebVoyager with an accuracy of **80.02%**.\n\n\n> R1-4: More prior methods [1, 2] should be included in the experimental comparison to better contextualize the improvements.\n\nAgentOccam [1] and WebPilot [2] do not report results on WebArena-lite, so we evaluated our method on the full WebArena benchmark; please see R2-2 for a detailed comparison, where we find that Plan-and-Act achieves performance on-par or better with prior work on WebArena.\n\n\n> R1-5: The writing could be improved in the following aspects: (1) The Related Work section should not merely summarize previous studies but should also explicitly discuss the similarities and differences between the proposed approach and existing methods. (2) The paper should include a thorough discussion of the limitations of the proposed method.\n\nRegarding related work, we will expand it based on the discussion in R3-4.\n\nRegarding the limitations, one main drawback is that Action Trajectory Generation (Section 4.1) does depend on having a baseline model that can successfully complete the web tasks. The synthetic data generation pipeline introduced in Section 4.3 is able to mitigate some of these concerns such that with a sufficient amount of training data. However, for datasets that do not have any training data, such as WebVoyager, the pipeline will depend on having a base model to collect trajectories.\n\nWe will include a more thorough discussion of limitations in the final version of the paper.", "claims_and_evidence": "Yes.", "methods_and_evaluation_criteria": "Yes, the proposed methods make sense for the web task. However, the paper only reports the success rate of the methods on the WebArena-Lite benchmark. Additional metrics, such as the average number of steps required to complete a task, would provide a more comprehensive assessment.", "theoretical_claims": "No, there is no theoretical claim.", "experimental_designs_or_analyses": "Yes.", "relation_to_broader_scientific_literature": "A new synthetic data generation strategy can improve LLM's performance for long-horizon web tasks.", "essential_references_not_discussed": "No.", "other_strengths_and_weaknesses": "Strengths:\n1. The experimental results are positive, achieving new state-of-the-art performance on the WebArena-Lite benchmark.\n2. The paper provides sufficient ablation studies to demonstrate the contribution of individual components.\n\nWeaknesses:\n1. The proposed framework lacks novelty, as it essentially follows a hierarchical planning approach and utilizes environmental feedback for replanning—both of which are commonly used in planning applications.\n2. The experiments are conducted solely on WebArena-Lite, a simulated environment. It would be more informative to evaluate the approach on WebVoyager, which better reflects real-world web behavior.\n3. More prior methods [1, 2] should be included in the experimental comparison to better contextualize the improvements.\n4. The writing could be improved in the following aspects: \n(1) The Related Work section should not merely summarize previous studies but should also explicitly discuss the similarities and differences between the proposed approach and existing methods.\n(2) The paper should include a thorough discussion of the limitations of the proposed method.\n\nReferences:\n\n[1] Zhang et al., WebPilot: A Versatile and Autonomous Multi-Agent System for Web Task Execution with Strategic Exploration.\n\n[2] Yang et al., AgentOccam: A Simple Yet Strong Baseline for LLM-Based Web Agents.", "other_comments_or_suggestions": "No.", "questions_for_authors": "See Weaknesses and Evaluation Criteria.", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "AVmLkUINba", "reviewer": "Reviewer_kftV", "summary": "The authors propose Plan-and-Act, which consists of two separate modules for planning and acting (execution), with dynamic replanning for better adaption to different situations. The Planner generates high-level plans, which are taken as input for the Executor to generate low-level actions. Importantly, for the training of the two modules with enough domain knowledge, the authors use synthetic data generation. While the low-level actions can be the training data for the Executor, the authors suggest two approaches for enhanced training of the Planner. The first approach is plan annotation, which annotates collected trajectories with plan \"labels\" by prompting LLMs. To scale up the training data for Planner, the second approach to synthetically generate plan data is used. On WebArena-Lite, they show that Plan-and-Act can outperform the baselines.\n\n## update after rebuttal\n\nI appreciate the authors for providing the extended empirical results.\n\nWhile the added empirical results do add value to the work and address some of my concerns, I still believe none of WebArena and WebVoyager justify the claim of being \"long-horizon.\" From my experience, neither WebVoyager nor WebArena requires long-horizon executions. On a relatively minor but related topic, the number of steps for the failure trajectories shouldn't be used for measuring the complexity of tasks (and even successful trajectories can contain non-optimal actions and steps).", "questions": "", "limitations": "", "rating": 3, "confidence": null, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "> R2-1: One primary weakness of this work is its empirical evaluation. It only provides the evaluation on WebArena-Lite, which employs non-real-world websites as part of the environment. The experimental results may be strengthened by evaluating the proposed approach on more realistic benchmarks, such as WebVoyager.\n\nThat is a fair point. We have evaluated our method on WebVoyager and report the results below, where we achieve **80.02**% accuracy which is SOTA for text-only models (note that operator uses multi-modal approach ).\n\nTo evaluate our approach on WebVoyager, we first collected training data, since WebVoyager does not have any trajectories. We used the text-only WebVoyager model and generated 1500 trajectories using the Action Trajectory Generation (Section 4.1). We then used QWQ-32B to annotate our trajectories (Section 4.2) and to generate 10k synthetic plans (Section 4.3). Our model uses both Dynamic-Replanning and CoT reasoning introduced in R3-5. We finetuned 2 llama-3.1-8b-instruct models for the Planner and Executor.\n\nFurthermore, we tried using QWQ-32B as a zero-shot executor with our finetuned llama-3.1-8b-instruct model as the planner.\n\nOur 8B planner and executor has an accuracy of 58.08% and our 8B planner and 32B executor achieves an accuracy of **80.02**%, which sets a new SOTA for all open source models, as well as one for all text-only models, since OpenAI Operator uses vision. \n\n| Technique              | Base Model                                               | WebVoyager Accuracy (%) |\n| ---------------------- | ------------------------------------------------------- | ----------------------- |\n| WebVoyager (text-only) | gpt-4-turbo                                             | 44.3                    |\n| NNetNav                | llama-8b-instruct                                       | 34.2                    |\n| OpenWebVoyager         | Idefics2-8b-instruct                                    | 27.4                    |\n| Wilbur                 | gpt-4-turbo                                             | 52.6                    |\n| WebVoyager             | gpt-4-turbo                                             | 57.1                    |\n| Plan-and-Act           | llama-8b-instruct planner + llama-8b-instruct executor | 58.08                   |\n| Agent-E                | gpt-4-turbo                                             | 73.1                    |\n| Plan-and-Act           | llama-8b-instruct planner + zero-shot QWQ-32B executor | **80.02**                   |\n| OpenAI Operator        | OpenAI Operator                                         | 87.0                    |\n\n\n\n\n> R2-2: SOTA claims on WebArena-Lite (not just from this submission) may need further investigations, as many papers still use the original WebArena for evaluation and the corresponding performance on the WebArena-Lite subset should be derivable.\n\nWe appreciate the feedback from the reviewer. We investigated your suggestion and found that while some papers do release traces that allow you to see the trajectories, the evaluation of these traces is impossible for some tasks without running the simulation itself.\n\nThus, we evaluated Plan-and-Act on the full WebArena benchmark. We used the Llama 70B model with CoT that we introduced in R3-5. Below, you can see our performance compared to other work prior to the ICML deadline. Plan-and-Act performs better/on-par with all prior work, while being open-source. \n\n| Method           | Base Model      | WebArena Accuracy (%) |\n| ---------------- | --------------- | --------------------- |\n| NNetNav          | Llama-3.1-8b    | 16.3                  |\n| AutoWebGLM       | ChatGLM3-6B     | 18.2                  |\n| WebPilot         | gpt-4o          | 37.2                  |\n| AgentOccam       | GPT-4-Turbo     | 43.1                  |\n| AgentOccam-Judge | GPT-4-Turbo     | 45.7                  |\n| Plan-and-Act     | Llama-70B       | 45.7                  |\n| Openai Operator  | Openai Operator | 58.1                  |\n\n\n\n\n> R2-3: While the targeted problem itself is relevant to LLM agents, the current empirical evaluation (only on WebArena-Lite) makes it hard to assess the proposed method's broader applicability.\n\nPlease see R2-1 and R2-2.\n\n\n> R2-4: More papers can be cited in the context of using separate planner and executor, especially \"ADaPT: As-Needed Decomposition and Planning with Language Models\"\n\nWe will add ADaPT in related work.\n\n\n> R2-5: Given the task distribution of WebArena(-Lite) and example plans and trajectories, the use of the term \"long-horizon\" can be an overstatement or misleading.\n\nWe kindly refer the reviewer to the table in R1-1, in the response to Reviewer 1. There, we have provided a breakdown of the number of steps per task in WebArena-lite. Each task averages around 9-13 steps on average.", "claims_and_evidence": "- The claims that constitute the proposed approach are empirically supported by the results on WebArena-Lite. Especially, Table 1 provides a performance improvement breakdown across the components of the proposed method.", "methods_and_evaluation_criteria": "- The proposed method for synthetic generation of planning data is sound. Especially, for environments or domains where the dynamics itself can change over time, such as web navigation, generating data that is grounded to the actual environment is important.\n- (Also as mentioned in this paper,) synthetic augmentation of planning training data can introduce noise to some extent.", "theoretical_claims": "There is not much of theoretical claims from this submission.", "experimental_designs_or_analyses": "- One primary weakness of this work is its empirical evaluation. It only provides the evaluation on WebArena-Lite, which employs non-real-world websites as part of the environment. The experimental results may be strengthened by evaluating the proposed approach on more realistic benchmarks, such as WebVoyager.\n- SOTA claims on WebArena-Lite (not just from this submission) may need further investigations, as many papers still use the original WebArena for evaluation and the corresponding performance on the WebArena-Lite subset should be derivable.", "relation_to_broader_scientific_literature": "- While the targeted problem itself is relevant to LLM agents, the current empirical evaluation (only on WebArena-Lite) makes it hard to assess the proposed method's broader applicability.", "essential_references_not_discussed": "- More papers can be cited in the context of using separate planner and executor, especially \"ADaPT: As-Needed Decomposition and Planning with Language Models\"", "other_strengths_and_weaknesses": "- Given the task distribution of WebArena(-Lite) and example plans and trajectories, the use of the term \"long-horizon\" can be an overstatement or misleading.", "other_comments_or_suggestions": "N/A", "questions_for_authors": "N/A", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "Yp4RixvCP3", "reviewer": "Reviewer_6X2E", "summary": "This paper proposes Plan-and-Act, an agent for web environments which separates planning from execution. A planner generates the overall plan, and a separate executor carries out the plan by issuing low-level actions. In order to train the planner, a synthetic data generation method is introduces to annotate trajectories with feasible plans. The method achieves a new sota on WebArena-Lite.", "questions": "", "limitations": "", "rating": 3, "confidence": null, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "> R3-1: It is difficult to understand the contributions of the paper within the broader literature of planning in LLM agents, as discussion of related works in agents with planning is missing\n\nWe thank the reviewer for their feedback. Please see response R3-4.\n\n\n> R3-2: The paper does not discuss the difference between Webarena and Webarena-Lite, and it is difficult to understand the distinction of the approach among the many approaches in Webarena\n\nWe appreciate the reviewer’s feedback. WebArena-lite was introduced in VisualAgentBench as a subset of the full WebArena, refined to remove unclear and impossible tasks, and also generated a training set where the original WebArena benchmark does not. For a discussion on how our approach differs from other prior work in this area, please refer to R3-4. For a comparison of results, please refer to R2-2, where we show that Plan-and-Act performs on-par with existing prior work on the full WebArena benchmark while being completely open source. \n\n\n> R3-3: There are numerous prior works which propose a dynamic plan-and-execute architecture, which are not discussed in the paper:\n> \n> AgentOccam: A Simple Yet Strong Baseline for LLM-Based Web Agents, ICLR 2025\n> WebPilot: A Versatile and Autonomous Multi-Agent System for Web Task Execution with Strategic ExplorationIiii\n> Adaptive planning from feedback with language models, NeurIPS 2023\n\n\nWe appreciate the feedback from the reviewer. AgentOccam and WebPilot were referenced in the Introduction as well as Section 2.1 of the Related Work section and we thank the reviewer for the pointer to AdaPlanner. We will expand and discuss these works in the final version of the paper. For a more in-depth discussion of how our work differs from the existing literature, please see R3-4.\n\n\n> R3-4:   … its weaknesses are the lack of discussion of related works and limited novelty, as plan-and-execute is a common approach among related works. I am willing to increase my score if the authors address these points.\n\nThe Plan-and-Act framework is not just a hierarchical planning framework, but also a data generation framework. Prior work that involve planning and hierarchies such as AgentOccam, WebPilot, AdaPlanner, and ADaPT are all prompting methods using closed-source models such as GPT-4o as their base model. Our method provides a simple, systematic way to generate high quality training data to train LLMs on web tasks.\n\nIn addition, our method uses a very simple 2-agent framework, which is significantly simpler compared to other prior work with planning. AgentOccam uses a “Planning via Generation” technique where the planning is incorporated into the action space and the model plans in a tree-like fashion. WebPilot has a significantly more complex infrastructure with 6 different agents in total. AdaPlanner has a In-Plan and Out-of-Plan Refiner to facilitate replanning when the plan is wrong and a skill-discovery module that is orthogonal to our method and can be used in conjunction. ADaPT uses recursive decomposition to decomposes tasks when the executor fails, whereas our dual-agent architecture simply replans at each step. All of these methods use more excessive prompting to improve performance, while our method has a simple Plan-and-Act structure at runtime.\n\nOther work that have discussed generating training data for Web Agents such as DigiRL, WebRL, AutoWebGLM, and NNetNav provide more complex techniques for collecting diverse trajectories, which are complementary to Plan-and-Act, as our pipeline (Section 4.1) is simple and can be interchanged. Furthermore, they only produce trajectory data, but do not planning data (Section 4.2). They also rely on external simulators to generate data, whereas our method can generate synthetic planning data without a simulator (Section 4.3).\n\n\n\n> R3-5: It would be beneficial to report results using a smaller LLama model as well, to demonstrate the generality of the proposed approach.\n\nWe thank the reviewer for this feedback. We have also trained a Llama-3.1-8b-instruct model using the Plan-and-Act framework.\n\nWe also decided to add CoT style reasoning to the Planner and Executor so that it generates some reasoning before it generates the plan/action.  Furthermore, we also finetuned another Llama-70B model on this data as well to see how the performance would be for the Llama-70B model with CoT as well:\n\n\n- Llama-70B with Dynamic Replanning: 53.94% (89/165)\n- Llama-8B with CoT with Dynamic Replanning: 53.33% (88/165)\n- Llama-70B with CoT with Dynamic Replanning: **57.58**% (95/165)\n\nWe evaluated smaller Llama-8B models and found that our approach still outperforms existing methods (53.33%), demonstrating strong generality. With CoT reasoning, our Llama-70B achieves **57.58**%, setting a new SOTA on the WebArena-lite dataset. We will include these results in the final version of our paper.", "claims_and_evidence": "The proposed method outperforms the previous sota, WebRL, and well designed ablations show that proposed components in planner and executor design contribute to the performance.", "methods_and_evaluation_criteria": "Methods are evaluated on Webarena-lite success rate. Baselines include finetuning ReAct style without a planner, and WebRL.", "theoretical_claims": "n/a", "experimental_designs_or_analyses": "see above", "relation_to_broader_scientific_literature": "There are several issues with the paper in terms of relation to the broader literature,\n- It is difficult to understand the contributions of the paper within the broader literature of planning in LLM agents, as discussion of related works in agents with planning is missing\n- The paper does not discuss the difference between Webarena and Webarena Lite, and it is difficult to understand the distinction of the approach among the many approaches in Webarena", "essential_references_not_discussed": "There are numerous prior works which propose a dynamic plan-and-execute architecture, which are not discussed in the paper:\n- AgentOccam: A Simple Yet Strong Baseline for LLM-Based Web Agents, ICLR 2025\n- WebPilot: A Versatile and Autonomous Multi-Agent System for Web Task Execution with Strategic ExplorationIiii\n- Adaptive planning from feedback with language models, NeurIPS 2023", "other_strengths_and_weaknesses": "The strengths of the paper are training a strong plan-and-execute approach using synthetic data, while its weaknesses are the lack of discussion of related works and limited novelty, as plan-and-execute is a common approach among related works. I am willing to increase my score if the authors address these points.", "other_comments_or_suggestions": "- It would be beneficial to report results using a smaller LLama model as well, to demonstrate the generality of the proposed approach.", "questions_for_authors": "see above", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "cDoTFQFRJl", "reviewer": "Reviewer_FBh4", "summary": "The paper proposes a Plan-and-Act methodology for long-horizon web-tasks. The basic premise of the Plan-and-Act method is that it decomposes the long-horizon planning into two modules: planning and executing. The planner module creates a long-horizon plan and the executor executes actions relevant to completing the tasks in this plan. The paper also introduces a dataset augmentation and synthesis process to fine-tune LLMs in the planning phase. The model achieves a ~10% increase in success rates compared to previous SOTA in the Web-Arena Lite benchmark.", "questions": "", "limitations": "", "rating": 3, "confidence": null, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "> R4-1: The experimental process for reproducing the tables is not provided in the paper (seeds, temperature, etc.). This makes it slightly harder to judge the effectiveness of the paper as I am not sure if the best results obtained with the LLMs were included in the paper. I would urge the authors to give more information on the reproducibility of the tables in the paper and any experimental parameters so that it is easier for the reader to reproduce.\n\nHyperparameters for SFT\n\nWe have used the following parameters for training both the Planner and the Executor models, both for the 70B and 8B models. As the 70B model, we have used Llama-3.3-70B-Instruct as the base model; and for the 8B model, we have used Llama-3.1-8B-Instruct as the base model.\n\n\n- Learning Rate: 2e-5\n- Optimizer: AdamW\n- LR Scheduler: Cosine\n- Warmup Ratio: 0.1\n- Batch Size: 32\n- Epochs: 1\n- FP16/BF16: Enabled\n- Machine: 8xA100\n- Framework: torchtune\n\nHyperparameters For Inference\n\n- Temperature: 0\n- Framework: vLLM\n- Max tokens generated: 4196\n- Maximum sequence length: 32000\n\nHyperparameters for Data Generation\n\nWe used GPT-4o for all data generation stages.\nWhen generating synthetic data, for each generation, we have retrieved 5 in-context examples and generated 10 new synthetic user query-plan pairs. \n\n\n\n> R4-2: I feel that the method introduced in this work has been introduced in a few other research papers (refer essential references not discussed section) before as well, albeit for other applications (robotics, etc.) These papers also focus on decomposing the long-horizon planning into multiple modules (planning + acting w/ replanning). I would urge the authors to discuss the differences of these prior works when compared to Plan-and-Act and maybe show a comparison against these methods as well. It might be possible that the superior performance might be due to the long customised prompts given as input to the LLMs (as shown in the appendix).\n\nWe thank the reviewer for their feedback. For method distinctions, see R3-4 in our response to Reviewer 3. For comparisons on other datasets, please see R2-1 (WebVoyager)/R2-2 (WebArena) in our response to Reviewer 2, where we show that our model performs on-par with other prior work on WebArena and set a new SOTA for text-only models on WebVoyager.\n\nRegarding the prompts given as input to the LLMs, most of the customized prompts in the appendix are for the data generation pipeline. At inference time, the System prompts for the Planner, Executor, and for Replanning are only the prompts in A.3.1, A.4.1, and A.10.1, which are fairly high-level and generic and similar in length to other prior work (See Figure 21 in WebRL).  \n\n\n> R4-3: The experimental design is valid as it is based on a benchmark dataset (WebArena-Lite). I would suggest the authors to include experimental details for better reproducibility of the experiments.\n\nPlease see R4-1.\n\n\n> R4-4: The results show improvement compared to previous SoTA. But the method used has been introduced previously for other applications. I am not sure if this would count as a novel contribution to the scientific literature.\n\nPlease see R3-4/R4-5.\n\n\n> R4-5: The papers below operate with a similar plan-act (+extra modules) for embodied robotics tasks. My initial thought was that something like this could be extended to the WebArena environment as well. [1]: Chan Hee Song, Jiaman Wu, Clayton Washington, Brian M. Sadler, Wei-Lun Chao, and Yu Su. LLMPlanner: Few-Shot Grounded Planning for Embodied Agents with Large Language Models, 2023 [2]: Nayak, S., Morrison Orozco, A., Have, M., Zhang, J., Thirumalai, V., Chen, D., ... & Balakrishnan, H. (2024). Long-horizon planning for multi-agent robots in partially observable environments. Advances in Neural Information Processing Systems, 37, 67929-67967. [3]: Shyam Sundar Kannan, Vishnunandan LN Venkatesh, and Byung-Cheol Min. SMART-LLM: Smart Multi-Agent Robot Task Planning using Large Language Models. arXiv preprint arXiv:2309.10062, 2023\n\nWe thank the reviewer for these additional references which we will add to our related work. Indeed, these works [1,2,3] use hierarchical LLM Agents to decompose tasks and plan for robotics/embodied agents which shares some similarity with Plan-and-Act. However, similar to the other planning based web agents mentioned in R3-4, none of these prior work contain a framework for collecting and generating synthetic data for training open source LLMs to get better at these tasks. The synthetic data generation pipeline of Plan-and-Act is what differentiates it from other prior work with planning and agents.\n\n\n> R4-6: I would urge the authors to present more experimental details for better reproducibility and a thorough explanation on why Plan-and-Act is different than other plan-act methods used in the papers linked above.\n\nPlease see R4-1 for more experimental details and R3-4/R4-5 for a detailed explanation on how Plan-and-Act is different from other plan-act methods.", "claims_and_evidence": "The claims made in the paper are supported well with the experiments. But that being said, I am always a bit skeptical about papers that operate with LLMs for evaluations wrt to reproducibility. The experimental process for reproducing the tables is not provided in the paper (seeds, temperature, etc.). This makes it slightly harder to judge the effectiveness of the paper as I am not sure if the best results obtained with the LLMs were included in the paper. I would urge the authors to give more information on the reproducibility of the tables in the paper and any experimental parameters so that it is easier for the reader to reproduce.", "methods_and_evaluation_criteria": "I feel that the method introduced in this work has been introduced in a few other research papers (refer essential references not discussed section) before as well, albeit for other applications (robotics, etc.) These papers also focus on decomposing the long-horizon planning into multiple modules (planning + acting w/ replanning). I would urge the authors to discuss the differences of these prior works when compared to Plan-and-Act and maybe show a comparison against these methods as well. It might be possible that the superior performance might be due to the long customised prompts given as input to the LLMs (as shown in the appendix). \n\nRight now, in its current state, I am going to lean towards weak accept but am willing to change if the authors can address some of the concerns I have raised in my review (specifically, the comparison to other plan-act-based methods)\n\nThe evaluation criteria seem to be from a standard benchmark and I have no qualms about it. The benchmark is apt for the application at hand and the proposed method performs better than previous SoTA.", "theoretical_claims": "No theoretical claims in the paper. Mostly experimental.", "experimental_designs_or_analyses": "The experimental design is valid as it is based on a benchmark dataset (WebArena-Lite). I would suggest the authors to include experimental details for better reproducibility of the experiments.", "relation_to_broader_scientific_literature": "The results show improvement compared to previous SoTA. But the method used has been introduced previously for other applications. I am not sure if this would count as a novel contribution to the scientific literature.", "essential_references_not_discussed": "The papers below operate with a similar plan-act (+extra modules) for embodied robotics tasks. My initial thought was that something like this could be extended to the WebArena environment as well.\n[1]: Chan Hee Song, Jiaman Wu, Clayton Washington, Brian M. Sadler, Wei-Lun Chao, and Yu Su. LLMPlanner: Few-Shot Grounded Planning for Embodied Agents with Large Language Models, 2023\n[2]: Nayak, S., Morrison Orozco, A., Have, M., Zhang, J., Thirumalai, V., Chen, D., ... & Balakrishnan, H. (2024). Long-horizon planning for multi-agent robots in partially observable environments. Advances in Neural Information Processing Systems, 37, 67929-67967.\n[3]: Shyam Sundar Kannan, Vishnunandan LN Venkatesh, and Byung-Cheol Min. SMART-LLM: Smart Multi-Agent Robot Task Planning using Large Language Models. arXiv preprint arXiv:2309.10062, 2023", "other_strengths_and_weaknesses": "I appreciate the way in which the results are presented where the increase in success rates is clearly visible with the addition of each module.", "other_comments_or_suggestions": "NA\n\n### Update after rebuttal:\nI wasn't sure if the \"official comments\" were visible to the authors and hence am including them here:\n\nI appreciate the authors' rebuttal. I am assuming that the authors will include the hyperparameters, discussion of additional experiments on WebVoyager, other missing references raised in the reviews in the camera-ready. I am increasing my score by 1 as the authors have clarified my questions.\n\nA suggestion: it would be nicer for the reviewers if you could copy the text to particular answers to questions raised in the rebuttal instead of redirecting to rebuttals of other reviewers. It gets hard to do that in the current state eg. \"please see R3-5 for more details\".", "questions_for_authors": "I would urge the authors to present more experimental details for better reproducibility and a thorough explanation on why Plan-and-Act is different than other plan-act methods used in the papers linked above.", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}]

Author rebuttal:

Meta-review: The paper studies LLM planning with separate planner and executors. The idea is relatively simple and has been applied in prior work, and this looks like the main concern from the reviewers. The authors partially address such concerns, and as the result two reviewers raised their scores to 3, and right now we have 3, 3, 3, 3 as the final scores. By reading the comments and rebuttals and relevant parts in the paper, I can understand that the main contribution of the paper seems to be using synthetic data to train the planner, while most prior studies simply use existing LLMs with prompting. There are also studies using synthetic data, but the authors claim that prior studies rely on simulators while their approach is simpler. Overall, my assessment on the paper is that the paper's contribution is to combine several relatively simple ideas (separate planner and executor, synthetic data for training, data generation using LLM instead of simulator, etc.) and provide a concrete implementation and evaluation. The research direction is very important and the authors provide a reasonable study to investigate a valid design point in this direction. Thus I would like to recommend weak accept (accept if there is room in the program) to the paper.
Decision: Accept (poster)