Scaling Synthetic Task Generation for Agents via Exploration
Authors: Ram Ramrakhya
Andrew Szot
Omar Attia
Bogdan Mazoure
Anh Tuan Nguyen
Yuhao Yang
Zhe Gan
Harsh Agrawal
Alexander T Toshev
Venue: ICLR 2026 Poster (2026)
Keywords: data science
embodied ai
agents
computer use agents
Primary area: foundation or frontier models, including LLMs
TL;DR: data generation pipeline for digitial ai agents

Abstract: Post-Training Multimodal Large Language Models (MLLMs) to build interactive agents holds promise across domains such as computer-use, web navigation, and robotics. A key challenge in scaling such post-training is lack of high-quality downstream agentic task datasets with tasks that are diverse, feasible, and verifiable. Existing approaches for task generation rely heavily on human annotation or prompting MLLM with limited downstream environment information, which is either costly or poorly scalable as it yield tasks with limited coverage. To remedy this, we present AutoPlay, a scalable pipeline for task generation that explicitly explores interactive environments to discover possible interactions and current state information to synthesize environment-grounded tasks. AutoPlay operates in two stages: (i) an exploration phase, where an MLLM explorer agent systematically uncovers novel environment states and functionalities, and (ii) a task generation phase, where a task generator leverages exploration trajectories and a set of task guideline prompts as context to synthesize diverse, executable, and verifiable tasks. We show AutoPlay generates $20$k tasks across $20$ Android applications and $10$k tasks across 13 applications Ubuntu applications to train mobile-use and computer-use agents. AutoPlay generated tasks enable large-scale task demonstration synthesis without human annotation by employing an MLLM task executor and verifier. This data enables training MLLM-based UI agents that improve success rates up to $20.0\%$ on mobile-use and $10.9\%$ on computer-use scenarios. In addition, AutoPlay generated tasks combined with MLLM verifier-based rewards enable scaling reinforcement learning training of UI agents, leading to an additional $5.7\%$ gain. coverage. These results establish AutoPlay as a scalable approach for post-training capable MLLM agents reducing reliance on human annotation.

Published as a conference paper at ICLR 2026
SCALING SYNTHETIC TASK GENERATION FOR AGENTS VIA EXPLORATION
Ram Ramrakhya, Andrew Szot, Omar Attia, Bugdan Mazoure, Anh Nguyen, Yuhao Yang, Zhe Gan, Harsh Agrawal, Alexander Tushev
ABSTRACT
Post- mest-Training Multimodal Large Language Models (MLLMs) to build interactive agents holds promise across domains such as computer-use, web navigation, and robotics. A key challenge in scaling such post-training is lack of high-quality downstream agentic task datasets with tasks that are diverse, feasible, and verifiable. Existing approaches for task generation rely heavily on human annotation prompting MLLM with limited downstream environment information, which is either costly or poorly scalable as it yield tasks with limited coverage. To remedy this, we present AUTOPLAY, a scalable pipeline for task generation that explicitly explores interactive environments to discover possible interactions and current state information to synthesize invironment-grounee
tasks. AUTOPLAY operates in two stages: (i) an exploration phase, where an MILM explorer agent systematically uncovers novel environment states and functionalities. and (ii) a task generation phase, where a task generator leverages exploration trajectories and a set of task guideline prompts as context to synthesize diverse, executable, and verifiable tasks. We show AUTOPLAY generates 20k tasks across 20 Android applications and 10k tasks across 13 applications Ubuntu applications train mobile-use and computer- use agents. AUTOPLAY generated tasks enable large-scall task demonstration synthesis without human annotation by employing MLLM task executor and verifier. This data enables training MLLM-based UI agents that improve success rates up 20.0% mobile-use and 10.9% on computer-use scenarios. In addition, AUTOPIAY generated tasks combined with MILMM verifier-based rewards enable scaling reinforcement learning training of UI agents, leading to additional 5.7% gain. coverage. These results establish AUTOPLAY as scalable approach for post-training capable MLLM agents reducing reliance on human annotation.
INTRODUCTION
Multimodal Large Language Models (MLLMs) are a promising foundation for building agents across wide range of downstream domains, including computer use (Qin et al., 2025; Agashe et al., 2025; OpenAl, 2025), web navigation (Zhou et al., 2023; Yao et al., 2024; 2022), video games (Fan et al., 2022; Wang et al., 2023), and robotics (Driess et al., 2023; Black et al., 2024; Kim et al., 2024). Owing to their broad knowledge and reasoning capabilities, these models are well-suited to understanding and planning the execution of open-ended tasks across these diverse application areas. A central challenge in training such agents is the scarcity of downstream interactive agentic data. Such interactive data consists of components: (I) Diverse Tasks: sufficiently
broad set of tasks or queries that cover real-world use cases of such agents, (2) Task demonstrations:
corresponding task execution trajectory. For most of these domains. such data is not readily available at web-scale, as much of the relevant interaction data resides on closed systems such as personal devices and commercial hardware. Consequently, post-training efforts for building agentic MILMS for such domains have relied heavily on human annotation to source large pool of diverse tasks and corresponding demonstrations (Li et al., 2024; Wang et al., 2025; Qin et al., 2025). However, this approach is prohibitively expensive and scales poorly. We argue, the fundamental bottleneck to enable scalable post-training of agentic MLLMs is lack large high-quality task definition datasets with tasks that are diverse, feasible to execute, verifiable, and aligned with real-world use cases. With access to such task datasets, MLLMs could be post- post-trained trained in a scalable manner with synthetically generated demonstrations using supervised finetuning (SFT) or via Reinforcement I Learning (RL.

---

Published as a conference paper at ICLR 2026
Summorasr
Summarine and Add Memory
Summmritzer
Summarize and Exploration Round
Exploration Round
Exploration Round
Stage
Roset
Reset
Environment Initial State
Environment
Fridironment
Contect
Contest
Task Guideline Prompts
Feature Use
Feature-Use
Task Generator
MLLM
Info. Retrieval
Task Generator
MLLM
Propose tasis for each
Stage 2
Information
Retrieval
functioniity shown above. Mase follow these guideliss::
diflerent informctio erxponment:
many mectings hawe
Project Deadlne' lncation Office 10:00
Feature Compasition
3. Tadis should raturl oser requerts soking about dets stored in the cnstronmnn Ex "How many meetings hove today?"
Wh location Meeding with 1797
One
2. Carcel my meeting thted Carch up on Det, 28th
inttrction "Dreater with utt
3. What evallable color options audiom oe theme Calendarapp?
Subtask
remirder hour befooe meeeiing 'Dal with Det. 25th
Repetition
4. Add now event oype "Posonaf in Calor dar settings.
Figure 1. AUTOPLAY generates large-scale, diverse and verifiable tasks for scaling supervision for MLLM agents. In stage (top), AUTOPLAY covers environment states through MLLM exploration policy that tracks seen states via a memory module. Next, stage 2 (hottom) uses these exploratory trajectories and task guideline prompts as context for proposing tasks. The guidelines help enforce task diversity and the exploration trajectories uncover environment features and content relevant for proposing tasks.
without any human annotation. This highlights the need for automatic and reliable pipeline synthesize tasks at scale.
For synthesized task datasets be useful, they must provide broad coverage of the target environment, ensuring a diverse and representative training set. They must also be feasible, meaning that agents can realistically execute them generate useful demonstrations. Finally, they should be verifiable filter hugh-quality trajectories for SFT or to build reward model for RL. However, building automatic pipeline that generates tasks with these properties is challenging as it requires explicit knowledge of current state information and what interactions are feasible in an environment knowledge that can only obtained through direct interaction with the environment.
In an attempt to address this challenge, prior works rely on limited domain knowledge of an MLLM to generate the tasks (Trabueco al., 2025; Zhou et al., 2025), this typically yields generic tasks with limited coverage and offers guarantees of feasibility or verifiability current MLLMs lack explicit grounding both environment dynamics and current state information. To address these shortcomings. propose approach that actively explores the agent's environment in exhaustive manner, collecting relevant information that can be used to ground MLLMs in the environment for scalable task generation. In this work, focus UT agents (Rawles et al., 2024; Xie al., 2025) that observe the current screenshot and interact with UT elements as a human user would. This setting both broad, capturing the full spectrum of everyday device tasks and practical since there are programmatic environments available for UI interactions (Rawles et al., 2024; Xie et al., 2024).
We introduce AUTOPLAY an approach for scalable task generation with focus task coverage, feasibility, and verifiability. Our method, depicted in Figure 1, incorporates two phases of exploration and task generation. First, in environment exploration phase, an MLLM explorer agent equipped with memory is prompted to exhaustively explore an increasing number of novel environment states (top of Fig. 1). Such exploratory trajectories are intended discover the accessible functionalities and content of the environment. Next, in task generation phase, task generator MLLM uses exploration trajectories as environment context to produce diverse environment groundddd tasks based on a set of task guideline prompts which describe desired task properties (bottom of Fig. 1). For instance, task guideline prompt for Feature- Use tasks would encourage generation of tasks that require doing diverse create, edit, of delete operations entities in the environment. We present example of the exploration trajectory collected by AUTOPLAY and the corresponding tasks synthesized using task generator grounded in the state of the environment in Fig.
2

---

Published as a conference paper at ICLR 2026
We use AUTOPLAY to scale task generation for mobile and computer UI agents. AUTOPLAY generates 20k tasks across 20 apps in an Android platform and 10k tasks across 13 apps in an Ubuntu platform. We then symthesize demonstrations for the -eyeeeerrtgee tasks using an MLLM executor and verify them with an MILM verifier, without relying on privileged environment information or human annotation. These demonstrations are used to finetune MILMM agent with SFT. Additionally, AUTOPLAY generated tasks also enable training the MLLM agent with RL, using the MLLM verifier as a reward model. Through these experiments we demonstrate AUTOPLAY enables post-training MLLM agents using both SFT and RL in scalable manner without relying on any human annotation.
We show that the AUTOPLAY pipeline is able to train effective MLLM UI agents. In mobile-use, AUTOPLAY boosts success rate performance by 13%-20% over the base model across a range of model sizes. computer-use, our method improves base model success rate performance by up to 10.9%. Beyond SFT, incorporating the generated tasks with the verifier for RL training yields an additional 5.7% improvement in task success rate. Together, these results demonstrate that tasks and trajectories lead to consistent and significant performance gains across model sizes and training paradigms. We also find that the AUTOPLAY task generation pipeline significantly outperforms prior approaches for synthetically generating tasks in the mobile-use domain (Trabucco et al., 2025; Zhou et al., 2025; Pahuja et al., 2025; Xie et al., 2025) which involve either generating tasks with limited environment information methods that interleave task proposal with execution. We find this improvement is a result of AUTOPLAY generating tasks with higher diversity, coverage, and feasibility for task execution than prior methods, ultimately yielding datasets that better support the training of capable UI agents.
AUToPLAY-generalee
2 RELATED WORK
Zero-Shot Methods for Agentic Tasks, Modular agentic pipelines (Agashe et al., 2025; Koh et al., 2024) that leverage MLLMs as high-level task planners, combined with diverse tools (e.g. lowelevel action controllers, memory, and tool use), have emerged as an effective approach for building capable UI agents across various domains (Xie et al., 2024; Rawles et al., 2024; Yao et al., 2024; Deng et al., 2023; Zhou et al., 2023). These pipelines aim to decompose the skills required for complex tasks-such as mapping high-level actions to environment-specific low-level controls, maintaining interaction history, verifying execution outcomes, and invoking tools-into specialized modules. Such modules can then be flexibly composed, enabling scalable and adaptable modular agentic pipelines. In this work, we leverage these agentic pipelines as synthetic data generation modules that enable us to collect Ul-interaction demonstrations for AUTOPLAY generated tasks to bootstrap training end-to-end UI agents that take environment observation as input and directly output actions.
Synthetic Task and Trajectory Generation. Synthetic data generation using agentic pipelines has emerged as promising approach to unlock internet-scale data for training UI agents. For instance, methods like PAE Zhou et al. (2025) leverage LLMSs conditioned on limited information about the environment (i.e. manually written textual descriptions) to propose tasks to synthesize task execution trajectories. In contrast, AUTOPLAY explicitly explores the environment to gather richer context about the environment without relying on human annotated textual descriptions. Another line of research focuses on iteratively proposing and executing tasks. Xie et al. (2025); Pahuja et al. (2025) use an initial screenshot from the environment and propose short-horizon subtask, and then execute this subtask, repeating this process and using the summary of previously executed sub-task as context propose the next subtask. This chain of subtasks is then summarized into single oong-horizon task with hindsight relabeling. Similarly, Trabucco et al. (2025) iteratively proposes and executes subtasks, but only for single iteration without chaining subtasks. Like AUTOPLAY these methods ground tasks in environment interactions, yet they are limited to each trajectory directly mapping to an instruction via hindsight relabeling. AUTOPLAY can propose multiple tasks from a single trajectory based on the uncovered possible interactions and sampled task guideline prompt. Furthermore, these prior works require each iterative subtask to start from the previous subtask, which progressively constrains the space of exploratory trajectories. On the other hand, methods like (Murty et al., 2024; 2025) start by using an LLM as a unconstrained exploration policy, next a trajectory labeler summarizes the exploration trajectories at regular intervals to a task instruction. Next, verifier verifies whether the trajectory completes the proposed task instruction or not, If it does not, a instruction following policy attempts to execute the proposed task instruction. In contrast to our method, (Murty et al.,
3

---

Published as a conference paper at ICLR 2026
Ensironment Contest
Feature-Uie Guidelines
Propose tasks for each funniionaliy shown.
Make sure to follow these guidelines:
Tasks requiring
CRUD operations specify parameters the Instruction. Ex
"Creste a meeting with cattendeer tited <t85k> <time>"
Noleel tokher
odle cleeeio
Tasks requiring edit
delete operations must only use enti shown environment context.
Task Remove the event 'Catch up" October 21st and the 'Meeting with Marketing' event on October 28th from Calendar.
2: 2: Create an event 'Discuss Project Deadline' at location Office starting at 16:00 on Oct. 15th with reminder 20 minutes before.
Figure 2. Example task generation based on an environment context, represented as a set screenshots and interactions, and a set of task guidelines. AUTOPLAY uses presences of events in the calendar together with guidance of using entities in the context, such as names and dates, to produce Task 1. Similarly, showing the event creation form in the context, coupled with guidance use these fields as task parameters, results in Task 2.
2024; 2025) does not use an exploration policy with memory and explicit task guidelines to maximize coverage of the environment or maximizing task diversity.
3 AUTOPLAY
3.1 PRELIMINARIES
We define AUTOPLAY in the context of multi-step decision making domains that be expressed as Partially Observable Markov Decision Processes (POMDP) (Puterman, 2014). A POMDP can be defined as tuple (S, O, P. R. Po) for underlying state space S, observation space O, action space A, transition function P: S x A - A(S), reward function It and initial state distribution po. We consider the extension of including a goal distribution G and the case where the reward is formulated as R(s. 9) for E S and g E G. We seek to learn a coal-conditioned policy π (a, (o. 9) mapping from observation On at timestep f and goal g to an action d, to achieve the goal state sy. We train a goal-conditioned policy =aaoo.)) g) in POMDP with dataset of tasks D. Using the above formalism, dataset of task 'D consists of tuples (g. 80) where g is coal-specifiiatiio in natural language, and 80 is the initial state of the environment. Similarly, we define trajectory a sequence = (oo; ... oT) ...
where the outcome of achieving goal is verified by reward model. In our case, the reward model only relies on the trajectory R(T,9) g) without privileged access to the environment state.
The goal of AUTOPLAY is to automatically generate large dataset of tasks D for a specific domain by actively interacting with POMDP to gather state information, semantics, and understanding dynamics. With access to task dataset D one can either attempt to generate training trajectories using a data collection policy for supervised finetuning (SFT), or use the reward model R in a multi-task reinforcement learning (RL) setup to train a goal-conditioned policy T <aaoo, g) We instantiate AUTOPLAY in the UI agent domain for mobilc-use and computer-use environments, e.g. a Calendar app on a mobile/desktop device. In this domain a state observation O is the partially observable device screenshot, an action is a UI interaction such as 'click', 'type', 'scroll', etc., and the transition operator is defined by transition dynamics of the UI application. A task is defined by goal like g = Reemove all the events on my calendar for next Tuesday" and initial state so starts with the agent on the homepage of the application with data populated in the Calendar application.
3.2 AUTOPLAY TASK GENERATOR
AUTOPLAY task generator operates in two stages: First, the POMDP is explored in a goal-agnostic manner to maximize coverage novel states of the environment using an explorer agent. Second, the task dataset D is produced using the information of the explored states combined with domain specific task guidelines.
4

---

Published as a conference paper at ICLR 2026
Algorithm 1 AUTOPLAY
Stage 1: Environment Exploration
Stuge 2: Task Generation
Parameters: apps M: of exploration tums
Parumeters:
task guidelines
K of tasks guideline and context
D
for
1...N .N.. de
for
1... Sample p P,
Sample 60 ~ S, Initialize context M = .. do Sample
Sample (91. (91..... 9X using
Sampletrajeccioy trajectory using MLLM(MM explorer explorer_ppomng prompt) Summarize m MI. summary_proom
MLLM (tusk yenerator prompl, T.).
D [(01 #1), .... (9K: .11)
8 = E (r), M M U {m)
where is the first state in
end
end for return
end for
Stage 1: Environment Exploration. In this stage, goal-agnostic explorer agent is employed to exhaustively explore the environment to maximize coverage over novel states and functionalities of the environment. The explorer agent is implemented using an MLLM agent equipped with an explicit memory of past interactions. At each timestep, the MLLM agent is provided current environment observation, past interaction memory, and prompted to select diverse actions, aiming to cover the full range of possible interactions within an environment. The explorer agent interacts with the environment for K steps. This process produces exploration trajectory, denoted as (01, 41, ,K ax). which we refer to as the environment context.
To ensure the environment is explored as exhaustively as possible, we repeat the exploration process for each environment M times. To encourage the explorer to cover novel states we provide explorer access to prior exploration turns {Ti,... 3 } i.e. episodic memory. As MLLMs have finite context window, directly conditioning on entire high-dimensional past trajectories is infeasible. Therefore, for each exploration turn i, we summarize the prior exploration turns {TI, ... ,T:11 to {m1,... m,-1} } where is concise and comprehensive text representation describing exploration trajectory T generated using a summarizer MLLM by m = MLLM (LLMMsummary. caammarry_rronppee r). At the end of stage 1, we obtain full environment context & (T1, TMM) J.
Stage 2: Exploration Conditioned Task Generation In this stage, each environment context from ~ E. is used to define set of N tasks. We would like to highlight that, the environment context r does not represent a successful execution of a task, rather it serves as context of what interactions are feasible and current state of the environment which can be used as hints synthesize tasks. More concretely, the environment context T helps uncover underlying information of the POMDP transition function T and state space S. We use MLLM as task generator that uses to generate environment-groune instructions from a single environment context, we find it useful to provide domain -spciffc prompts that specify guidelines for what constitutes good task to our task generator MLLM. These prompts, .NN,, referred to as task guidelines, are tailored to the target domain. For the UI domain,
tasks. Since there are many possible ways to derive task
P = they are illustrated in Fig. 2. For example, one guideline, called Feature-Use encourages creation of tasks that require doing diverse create, edit, of delete operations on entities in the environment shown in the corresponding environment context.
To produce the task dataset D, we append the task generator prompt, with trajectory data and task guideline prompt. We iterate over all combinations of trajectories in environment con- text r E & and task guideline prompt E 'P to sample a sequence of goals (91, ..''"..N'' .NN) ~ MLLM( geneertorerrtor____. generator_promptt p, T). Each goal, when paired with the initial state of 7, results in the task dataset. An example of this process for the UI domain is shown in Fig 2.
The above approach is summarized in Algorithm The prompts used for the explorer, summarizer, and task generator MLLMs are described in Appendix C.2. The explorer agent follows the same architecture as the task executor agent detailed Section 3.3.
3.3 TRAINING DATA GENERATION AND VERIFICATION
In the following, describe the task executor and verifier used in the UI domain.
Task Executor Agent. We use the tasks generated by AUTOPLAY to produce successful trajectories via an MI.LM based executor agent. Our executor agent builds the system proposed in Yang
5

---

Published as a conference paper at ICLR 2026
et al. (2025) and consists of MLLM planner, reflection tool, and grounding model. Given the task instruction, the current screenshot, previously executed actions, and a reflection trace of the last action generated by reflection tool, the MLLM planner generates high-level action in natural language. If this high-level action is coordinate- hased (e.g., a click), the grounding model translates it into a pixel-level coordinate for execution. Non-coordinate-baae basee actions are executed directly. The reflection tool supplements this process by taking as input the previous action, the prior observation, and the current observation to generate reflection trace. This trace describes the effect of the action on the environment and whether it was executed successfully, and it is provided as additional context to the high-level policy at the next timestep.
For both use and computer-use domains, we use GPT-4o (OpenAl et al., 2024) as both the planner and reflection model. We use UI-TARS- 7B (Qin et al., 2025) as the grounding model for mobile and G-TB1-7B (Yang et al., 2025) as the grounding model for computer-use. In the computer-use setting, we additionally supply the high-level policy with one heuristic action, to enable interaction with complex UI elements (like spreadsheets, detailed in Appendix F), which improves data collection success rates. These heuristic actions are only used by the expert and are not available to the trained AUTOPLAY policy.
Task Trajectory Verifier.
To determine whether LoooPPLL--geeeattee tasks are executed success- fully, we employ task verifier that evaluates trajectories. The verifier is an MLLM that takes as input the task instruction and the executed trajectory (represented as interleaved images and actions). It operates in three stages: (i) summarizing what the agent is doing in the trajectory, (ii) producing a Chain-of- -foTuhh (Wei et al., 2023) reasoning for whether the task has been completed, and (iii) issuing a final judgment of "success" or "failure". We use GPT-4o as the task verifier for trajectories collected using the task executor agent. Full details of the verifier and prompts are in Appendix C.4.
SFT Data Generation. To generate SFT data for mobile-use domain, we use 20 mobile apps from Rawles et al. (2024). Similarly, for computer-use domain, we use 13 desktop apps from Xie et al. (2024) on Ubuntu devices. We run the environment exploration for 3 turns to build the environment context and we define 4 task guideline prompts. Using these, we generate 50 tasks for each app, task guideline prompt, exploration context combination. We specify the precise prompts used for the task guidelines in Appendix C.I for each platform. We are able to generate ~20 tasks for Android platform and 10k for Ubuntu platform. After execution of these tasks and subsequent verification with the verifier obtain ~88 and ~3.55 successful trajectories respectively to use for SFT.
Base Model. For our experiments, we use Qwen2.5-V2 Instruct (Bai et al., 2025) 3B-72B MLLMs as the base model and finetune them using SFT and RL on our dataset to build a end-to-end UI agents. At each timestep. the policy takes as input: current image observation, history of past actions, the task instruction and outputs low-level actions. Appendix F describes the action space per-domain.
3.4 REINFORCEMENT LEARNING ON SYNTHETIC TASKS
We also use the tasks generated by AUTOPLAY in conjunction with the task verifier to scale rein- forcement learning (RL) training of mobile-use agents. For each RL training environment worker, we sample a random task from the AUTOPLAY task dataset (g, 5p) D. We then initialize the simulator state to So and task our agent to successfully complete the instruction. At the end of the rollout, we score the trajectory with the task verifier as either a success or failure, assigning a reward of 1 or 0 to the trajectory respectively. We use the Qwen2.5- V--32-5--VL-22--nnnnns instantiate the task verifier using the same verifier setup as in Sec. 3.3. By leveraging the AUTOPLAY task generator and an MLLM task verifier we unlock RL training with verifier feedback without requiring any human annotation. RL allows training on all AUTOPLAY tasks, even those the executor is not able to solve. However, for better training stability, we restrict RL training to the Sk tasks the executor can successfully solve at least once. We use GRPO to train the model with RL with group size 8 across 32 H100 GPUs See Appendix B.2 for full details.
Bai et al. (2025) MLLM to
EXPERIMENTS
In this section, we demonstrate that AUTOPLAY enables scaling generation of synthetic tasks for UI agents, that are feasible, diverse and grounded in environment state and functionality all without human annotations. The resulting high-quality tasks enable scaling of supervised finetuming (SFT) and reinforcement learning (RI.) for post-training MILMS as capable UI agents. We also show

---

Published as a conference paper at ICLR 2026
Method
Model Size
Pass
P
GPT4o + UI-TARS
43.1
55.3
Method
Pass@1
Pass
Seed-VL 1,5
62.1
GTA1
34.0
UI-TARS 230B
73.3
Agu 72B
10.3
UI-TARS 1.5
26.4
36.2
UI-TARS-1.5 7B
24.5
UI-TARS 72B
37.7
53.0
UI-TARS-1.5 72B
42.5
Owen- VL 2.5 7B
19.5
27.7
Qwen-Vi VL 2.5 7B
3.7
4.1
Qwen- VL 2.5 72B
35.0
43.5
Qwen-VL VL 2.5 72B
4.4
5.4
AUTOPLAY-7B
40.1
(+20.6 A)
58.4
(+30.7 A)
AUTOPLAY-7E
11.4
(+7.7 A)
12.1
(+8.0 A)
AUTOPLAY-72B
47.9
(+12. A)
68.2
(424. A)
AUTOPLAY-72B
14.5
(+101
16.0
(+10.6 A)
AUTOPLAY-3B 31.2
52.2
(b) OSrldd
AUTOPLAY-3B RL
39.9
(+57 A)
53.4 (+12
(a) Android World
Table 1. Evaluation results on UI agent benchmarks. Pass@1 and Pass@5 values for AUTOPLAY models include in parentheses the change relative to the corresponding base model of the same parameter size.
the tasks synthesized using AUTOPLAY achieve a higher task execution success rate and enable training more capable downstream agents compared to methods that do not explicitly explore the environment (Zhou et al., 2025) and ones that use iterative exploration (Xie et al., 2025; Trabucco al., 2025). Furthermore, we also evaluate importance of environment exploration and task guidelines for task generation and find that both components are important to build effective task proposer.
4.1 AUTOPLAY DATA FOR UI AGENTS
To assess how effectively AUTOPLAY generates training tasks for UI agents, we measure the per- formance of agents trained with these tasks established downstream benchmarks: Android- World (Rawles et al., 2024) for mobile agents and OSWorld (Xie et al., 2025) for desktop agents. We the AUTOPI.AY data described in Section 3.3 to train separate agent per benchmark. In both benchmarks, the agent evaluated using ground truth success verifier that has access to privileged environment information. We report the average success rate, referred to Pass@1 1, over inde- pendent random trials since most benchmark tasks have stochastic starting states with different goal details and application content. We also report the P metric, which is the percentage of tasks where any of the 5 independent trials succeeds.
AUTOPLAY improves agentic capabilities of base models: We use the synthetic data to finetune a base 2.een22.5-VI-X- into an agentic model AUTOPI.AY-XF for range of sizes X E (3, 7, 72). The resulting models consistently outperform their base as shown in Table 1. For example, AU- TOPI.AY-7B outperforms its base, Qwen2.5-VLL77H by 20.6% on AndroidWorld and by 7.7% on OSWorld. These gains demonstrate that the tasks generated by AUTOPLAY are highly relevant to the broad spectrum of UI agent tasks evaluated in both benchmarks, despite requiring human data collection. Similarly, the largest model, AUTOPLAY-725 -22B surpasses the strong Qwen2.5-VL-72B baseline by 12.9% points AndroidWorld and 10.1% points OSWorld illustrating that even highly capable UI agents benefit substantially from AUTOPLAY 's synthetic tasks. Remarkably, AUTOPLAY-3B achieves 34.2% 4.2%% success rate Android nearly matching the performance of the much larger Swee2.55VL-722 model, which attains 35.0%.
AUTOPLAY achieves competitive results with Proprietary Baselines trained on human data: Table 1 further shows that AUTOPLAY outperforms strong UI agent models such as UI-TARS-1.5 (Qin al., 2025), which was trained on large-scale human-annotated GUI data, by 10.2% at the 7B scale and 13.7% at the 72B scale on AndroidWorid. On OSWolld, AUTOPLAY-722 77B surpasses the two-stage training pipeline used in Viu Vis (Xu et al., 2024), which leverages both grounding data and human-annotated GUI navigation data, by 5.0% in success rate. Although UI-TARS-2 230B and Seed-VL--1.5 (ByteDanceSeedTTaam 2025) achieve higher performance on AndroidWorld, they rely on substantially larger mixtures of expert models. Similarly, UI-TARS outperforms AUTOPLAY OSWorld, likely due to its use of curated, human-labeled UI data- whereas AUTOPLAY autonomously explores, proposes tasks, and collects data without human supervision.
AUTOPLAY eventually outperforms the Executor: We also find in Table 1 that AUTOPLAY-722 outperforms the GPT-40 + UI-TARS (OpenAI, 2024; Qin et al., 2025) policy used to collect the data from the generated tasks by 4.8% on the average success rate. This demonstrates the strength of the task verifier for automatically filtering successful trajectories, without ground truth environment
7

---

Published as a conference paper at ICLR 2026
TASK EXECUTION
ANDROID WORLD
Task Generator
Pass@1 1 (f)
Pass@1 (t)
Pass@5 (*)
No Exploration
21.3
28.8 11.5
49.2
Iterative Exploration
56.4
21.6 #1.7
33.6
AUTOPLAY wo task guidelines
43.5
26.7 #2.7
38.9
AUTOPIAY
46.0
38.2 #3.1
58.5
Table 2. Ablations: We compare AUTOPLAY-7B with two baselines that perform lesser exploration, No Exploration and Iterative Exploration, as well as AUTOPLAY-7B without using task guidelines.
information. Furthermore, AUTOPLAY-725 72B achieves 12.9% higher Pass than the data collection policy, indicating it's ability solve new tasks, not just more robustly solve the same tasks.
AUTOPLAY effective for RL training: In Table we also highlight that it is feasible to perform RL training on the AUTOPLAY generated tasks, according the process described in Section 3.4. We see a 5.7% gain in AndroidWorld.. With RL training. the AUTOPLAY-2 -3B model performs similarly to the AUTOPLAY-7B model trained with just SFT (39.9% versus 40. 40.1% success rate).
4.2 ABLATION ANALYSIS
Next, we look at the importance of individual design decisions in AUTOPLAY. We use AndroidWorld and generate 5,000 Android tasks for all models. We then apply the same executor and verifier described in Section 3.3 to obtain successful trajectories, which are used to fine-tune the Qwen2.5- VL-7B model with supervised learning for AUTOPLAY and variations. Full details are in Appendix E.
Exploration Ablations: To quantify the importance of the environment exploration we compare with two alternative task proposal baselines. The first baseline, No Exploration, is based Zhou et al. (2025); Xie et al. (2025) and, unlike AUTOPLAY, performs no exploration of the domain. Instead, generates tasks solely from static environment context, such textual descriptions and application starting screenshots. To implement No Exploration, we manually write detailed descriptions of each AndroidWorld app's features and task guidelines in the same style as those used for AUTOPLAY. The second baseline. Iterative Exploration, follows Pahuja et al. (2025); Xie et al. (2025) and incorporates limited exploration. However, it only attempts sequentially execute series of short-horizon subgoals and summarize them as tasks, without performing broad exploration of the domain. As a result, it more constrained than AUTOPLAY. Our implementation begins the home page of the target application. An MILM proposes a short-horizon subgoal based on the initial screenshot, and the same data collection policy used in AUTOPLAY executes it. The MILLM then proposes the next subgoal, and this process repeats up 7 times. Finally, summarizer MLLM takes input the textual descriptions of the executed subgoals, along with their success or failure, and produces a long-horizon goal for the full trajectory akin to hindsight relabeling.
AUTOPLAY generates more feasible tasks: Out of the 5k tasks generated by each method, Table shows the same executor succeeds in 46.0% of the AUTOPLAY tasks compared to only 21.3% for No Exploration and 56.4% for Iterative Exploration. This demonstrates that more tasks generated by AUTOPLAY are feasible. A common failure mode of No Exploration baseline was hallucination in the proposed task since it only relies on app functionality description. AUTOPLAY, on the other hand, uses exploration context to ground task details in the actual states of the environment.
AUTOPLAY tasks train better agents: Table 2 also shows that agents trained with AUTOPLAY tasks outperform agents trained with tasks from No Exploration and Iterative Exploration. Agents trained with AUTOPLAY tasks outperform those trained with No Exploration tasks by 9.4% on Pass and Pass@5 5 success rates on AndroidWorld. AUTOPLAY tends to cover a broader range of functionalities in the environment compared to No Exploration. While Iterative Exploration does interact with the environment to generate tasks, AUTOPLAY tasks train agents that are 16.6% more successful, as shown by Task Execution Pass @1 1. This is because Iterative Exploration synthesizes long horizon trajectories by stitching easier short horizon subgoals to guide exploration. This consequently leads to less diverse and easier tasks. In contrast, through rounds of long-horizon exploration, AUTOPLAY generates diverse tasks that provide broad coverage over app functionalities.
We compare the task distributions generated by AU- TOPLAY and No Exploration in Figure 3. The distribution is computed over manually defined task categories that cover a broad range of possible tasks. For example, tasks in the Composition category
Exploration generates more diverse tasks:
8

---

Published as a conference paper at ICLR 2026
selprig
Conster Heneeee
Compoction
Oenauo ton
Compostirr
Crate
App
Delete
Doktts
Deviessvc
Fdt syttes oetiing
sytwe
The ronagement
Mefrrae ressna
Mnrrmationn netroval
Mat top resoring
Sylling roue
fepsst operatio
swarth
Spriddost odiing
Jwb saars
Text addr2
10
26
35
15
% Total Tedks
of Todls
Success raze 188
AutoPlay
AndroidWorld
AutoPlay
OSWorld
AutoPlay
No Exploration
(a) AndroidWorld Tasks
(b) OSWorld Tasks
(c) Effect of Exploration
Figure 3. Task Coverage. Left and Middle: For set of predefined categories, compare the task distribution across AndroidWorld/OSSoorr predefined categories, we compare the task distribution across AUTOPLAY generated tasks and Exploration generated tasks in light color. Additionally, we show number tasks that AUTOPLAY-7B executor solves for both task sets in darker color bars.
tasks and AUTOPLAY generated tasks in light color. Right: For of
Conp einterdion
Salt scrpting
Conplox edeectes
Compoalter
Conaze
Grer 100
rpp
Device seach
Dicunet ectiing
Edk syber serting
Eyt c
Interation
Musing hop rusorin
ibberet on revlece
Mull hop resoring
Mait hop ressciing
net matinn
Tox
Success rate (S6)
Success rate (X)
Success race 184
AutoPlay
AndroidWorld
AutoPlay
OSWorld
AutoPlay
No Exploration
(a) AndroidWorld Tasks
(b) OSWorld Tasks
(c) Effect of Exploration
Figure 4. Task Success Rates. Left and Middle: For set of predefined categories, we compare number of tasks that AUTOPLAY-7B executor solves per task category across IndroidWorkdOOSSollu test tasks and AUTOPLAY generated tasks. Right: For set predefined categories, we compare number of tasks that AUTOPLAY-78 executor solves per task category across AUTOPLAY generated tasks and No Exploration generated tasks.
require combining multiple skills or subtasks achieve the overall goal (e.g., "Find when John is free and schedule a meeting with him for this week."). Additional details about the task categories are provided in Appendix D. Although the two distributions exhibit similar trends trends-categoréa that are more prevalent under one method tend to be prevalent under the other-the the results consistently show lower execution success rates for No Exploration compared to AUTOPIAY, particularly categories such deleting, editing, retrieving in in-app data. This highlights the importance of grounding task generation in exploration.
Task guideline ablation:
The task guidelines prompts steer the AUTOPLAY task generator towards diverse categories with good domain coverage. Table 2 ablates the impact of the task guideline prompts and illustrates they important for generating tasks that train performant agents. We see minor boost in the ability of the executor to solve tasks, showing that task guidelines improve task feasibility. More importantly, guidelines provide a substantial boost in the downstream performance.

---

Published as a conference paper at ICLR 2026
TRAIN ON HOLDOUT APP
HOLDOUT APP
App Name
Pass@1 (f)
Pass05 (1)
Pass@1 1 (1)
Pass@5 (f)
Markor
26.1
38.4
11.5
38.5
Simple Calendar Pro
33.6
70.5
26.8
47.1
Broccoli-Recips Expense
20.0
38.6
35.4
46.1
Pro Expense Settings
47.7
66.6
51.1
66.6
74.4
80.0
72.0
80.0
Average Performance
40.4
58.9
39.4
55.7
Table 3. Generalization Results:
Evaluation results of AUTOPLAY-7B to holdout apps vs. training on test app.
AUTOPLAY generated tasks cover platform functionality: In addition, we compare of how well AUTOPLAY'S 's task distribution mimicks a natural task distribution. For this, we use Android World and OSWorld benchmarks as representative task distributions. As shown in Figure 3, AUTOPLAY produces task covering the majority of the categories. Further, our method seems to follow the distributions of these benchmarks. As shown in Figure 4, for AndroidWorld, the task executor performs quite well on majority of the categories except tasks where skills like fine-grained text editing, complex UI interactions (e.g. date-time picker wheels, etc), and cross app navigation is required which leads to the downstream policy perform poorly on these task categories. This clearly suggests, improving the task executor while keeping the task generator the same would lead to better quality synthetic dataset to improve downstream agent performance. For OSWorld, AUTOPLAY covers common task categories like document editing, however, it struggles to generate tasks with cross-app interaction, bash scripting and web search. We attribute this gap in task coverage lack of sufficiently diverse task guidelines prompts for computer-use domain.
Generalization unseen environments. In this section, we answer the question: How well do agents trained using AUTOPLAY data generalize to unseen environments compared to training on test environments? To study this question we holdout mobile applications (Settings, Markor, Simple Calendar Pro, Pro Expense, Broccoli-Rectie Recipe App) from our training split and evaluate generalization to these apps zero-shot at test time. Due to limited number of environments we train 5 separate models while holding out data from single environment. In addition, we also train model only on data collected in the held out environment. We compare the results of zero-shot generalization to held out environment with agents trained only on data from held out environment in Tab. 3. We find that agents trained on larger datasets generalize comparably well to holdout environments compared to training agents on data collected in test environments (39.4% vs. 40.4 on Pass@ success rate).
Verifier analysis. In Tab. 4, we present a human evaluation study to validate effeetiveness and human agreement of our verifier. We find the verifiers we used for SFT and RL show ~60% accuracy compared to ground truth labels and have high recall. Specifically, we sampled 200 unique tasks with ~50% execution success rate and asked 3 human annotators to label them. We label demonstration as successful at least annotators agree on it. Next, using human labels as ground truth we compare accuracy, precision and recall for our GPT-4o and Qwen-2.5 VL Instruct model based verifiers in table below. We find both verifiers achieve ~60% accuracy and have high recall but low precision. This suggests these models are more optimistic than pessimistic in labelling task as successful. We find the key failure mode of these models is to mark a long horizon task as successful when an agent completes partial subgoals but doesn't 't necessarily complete the full task.
CONCLUSION
We introduce AUTOPLAY, a scalable pipeline for synthesizing diverse, feasible, and verifiable tasks for post-training MLLM-based interactive agents. AUTOPLAY achieves this by explicitly exploring interactive environments combined with a carefully curated task guideline prompts to ground task generation in discovered states and accessible functionalities. We demonstrate the effectiveness of AUTOPLAY in training UI agents across both mobile and computer domains. AUTOPLAY generates 20k tasks across 20 Android applications and 10k tasks across 13 applications Ubuntu applications to train mobile-use and computer-use agents. This dataset enables training MLLM-based UI agents that improve in success rates up to 20.0% on mobile-use and 10.9% on computer-use domains. Furthermore, AUTOPLAY generated tasks combined with MLLM reward models enable scaling reinforcement learning training of UI agents, leading to additional 5.7% gain. Overall, these results establish AUTOPLAY as a scalable approach for post-training MLLM agents, reducing reliance on human annotation while significantly enhancing agent performance across domains.
10

---

Published as a conference paper at ICLR 2026
REFERENCES
Saaket Agashe, Jiuzhou Han, Shuyu Gan, Jiachen Yang, Ang Li, and Xin Eric Wang. Agent S: An Open Agentic Framework that Uses Computers Like Human. In International Conference on Learning Representations (ICLR), 2025. URL httpp://arree http:://wwwww.ooo/////////// 2410. 08164. 1, 3, 30
Shuai Bai, Keqin Chen, Xuejing Liu, Jialin Wang, Wenbin Ge, Sibo Song, Kai Dang, Peng Wang, Shijie Wang. Jun Tang, Humen Zhong, Yuanzhi Zhu, Mingkun Yang. Zhaohai Li, Jianqiang Wan, Pengfei Wang, Wei Ding, Zheren Fu, Yiheng Xu, Jiabo Ye, Xi Zhang, Tianbao Xie, Zesen Cheng, Hang Zhang, Zhibo Yang. Haiyang Xu, and Junyang Lin. Qwen2.5-v) technical report, 2025. URL https://arxiv. org/ 2502. 13923. 6, 15, 25
Kevin Black, Noah Brown, Danny Driess, Adnan Esmail, Michael Equi. Chelsea Finn, Niccolo Fusai, Lachy Groom, Karol Hausman, Brian Ichter, et al. pi wi_0: A vision-language-actioo flow model for general robot control. arXiv preprint arXiv:2410.24165 2024. 1
ByteDaancSSedTTem. Seed1 .5-vl technical report. arXiv preprint arXiv:2505.07002, 2025.
Xiang Deng. Yu Gu, Boyuan Zheng, Shijie Chen, Samuel Stevens, Boshi Wang, Huan Sun, and Yu Su. Mind2web: Towards generalist agent for the web, 2023. 3
Danny Driess, Fei Xia, Mehdi SM Sajjadi, Corey Lynch, Aakanksha Chowdhery, Ayzaan Wahid, Jonathan Tompson, Quan Vuong, Tianhe Yu, Wenlong Huang, et al. Palm-e: An embodied multimodal language model. 2023. I
Linxi Fan et al. Minedojo: Building open-ended embodied agents with internet-scale knowledge. In 1rXiv:2206.0885: 2022.
Moo Jin Kim, Karl Pertsch, Siddharth Karamcheti, Ted Xiao, Ashwin Balakrishna, Suraj Nair, Rafael Rafailov, Ethan Foster, Grace Lam, Pannag Sanketi, et al. Openvla: An open-source
vision-language-action model. arXiv preprini arXi::2406.09246, 2024.
Jing Yu Koh, Stephen McAleer, Daniel Fried, and Ruslan Salakhutdinov. Tree search for language model agents, arXiv preprint arX1v:2407.01476, 2024. 3
Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, Ying Sheng, Lianmin Zheng, Cody Hao Yu, Joseph E. Gonzalez, Hao Zhang, and Ion Stoica. Efficient memory management for large language model serving with pagedattention. In Proceedings of the ACM SIGOPS 29th Symposium on Operating Systems Principles, 2023. 15
Wei Li, William Bishop, Alice Li, Chris Rawles, Folawiyo Campbell-Ajala, Divya Tyamagundlu, and Oriana Riva On the effects of data scale on computer control agents. arXiv preprint M.Xiv:2406.03679, 2024. 1
Shikhar Murty, Christopher Manning, Peter Shaw, Mandar Joshi, and Kenton Lee. Bagel: Bootstrap- ping agents by guiding exploration with language, 2024. URL http:///aaxvv.oooaaa/aesse 081440
Shikhar Murty, Hao Zhu, Dzmitry Bahdanau, and Christopher Manning. Nnetnav: Unsupervised learning of browser agents through environment interaction in the wild. 2025. 3,4
OpenAl. Gpt-4o system card, arXiv preprini arXiv:2410.2127, 2024. "GPT-40 is an autoregressive omni model...
OpenAL. Computer-using agent: Introducing a universal interface for ai to interact with the digital world. 2025. URL https://openaa www./ooow.////cccocooooooooooooe wwwppter-usiin-eeeeeeeeee
1
OpenAI, Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Iige Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, Red Avila, Igor Babuschkin, Suchir Balaji, Valerie Balcom, Paul Baltescu, Haiming Bao, Mohammad Bavarian, Jeff Belgum, Irwan Bello, Jake Berdine, Gabriel Sermadett-Shapire Christopher Berner, Lenny Bogdonoff, Oleg Boiko, Madelaine Boyd, Anna-Luisa Brakman, Greg Brockman, Tim Brooks, Miles Brundage. Kevin Button, Trevor Cai, Rosie Campbell, Andrew Cann, Brittany Carey, Chelsea Carlson, Rory Carmichael, Brooke Chan, Che Chang, Fotis Chantzis, Derek Chen, Sully Chen,
11

---

Published as a conference paper at ICLR 2026
Ruby Chen, Jason Chen, Mark Chen, Ben Chess, Chester Cho, Casey Chu, Hyung Won Chung, Dave Cummings, Jeremiah Currier, Yunxing Dai, Cory Decareaux, Thomas Degry, Noah Deutsch, Damien Deville, Arka Dhar, David Dohan, Steve Dowling, Sheila Dunning, Adrien Ecoffet, Atty Eleti, Tyna Floundou, David Farhi, Liam Fedus, Niko Felix, Simón Posada Fishman, Juston Forte, Isabella Fulford, Leo Gao, Elie Georges, Christian Gibson, Vik Goel, Tarun Gogineni, Gabriel Goh, Rapha Gontijo-Lopes, Jonathan Gordon, Morgan Grafstein, Scott Gray, Ryan Greene, Joshua Gross, Shixiang Shane Gu, Yufei Guo, Chris Hallacy, Jesse Han, Jeff Harris, Yuchen He, Mike Heaton, Johannes Heidecke, Chris Hesse, Alan Hickey, Wade Hickey, Peter Hoeschele, Brandon Houghton, Kenny Hsu, Shengli Hu, Xin Hu, Joost Huizinga, Shantanu Jain, Shawn Jain, Joanne Jang, Angela Jiang, Roger Jiang. Haozhun Jin, Denny Jin, Shino Jomoto, Billie Jonn, Heewoo Jun, Tomer Kaftan, Eukasz Kaiser, Ali Kamali, Ingmar Kanitscheider, Nitish Shirish Keskar, Tabarak Khan, Logan Kilpatrick, Jong Wook Kim, Christina Kim, Yongjik Kim, Jan Hendrik Kirchner, Jamie Kiros, Matt Knight, Daniel Kokotajlo, Lukasz Kondraciuk, Andrew Kondrich, Aris Konstantinidis, Kyle Kosic, Gretchen Krueger, Vishal Kuo, Michael Lampe, Ikai Lan, Teddy Lee, Jan Leike, Jade Leung, Daniel Levy, Chak Ming Li, Rachel Lim, Molly Lin, Stephanie Lin, Mateusz Litwin, Theresa Lopez, Ryan Lowe, Patricia Lue, Anna Makanju, Kim Malfacini, Sam Manning, Todor Markov, Yaniv Markovski, Bianca Martin, Katie Mayer, Andrew Mayne, Bob McGrew, Scott Mayer McKinney, Christine McLeavey, Paul McMillan, Jake McNeil, David Medina, Aalok Mehta, Jacob Menick, Luke Metz, Andrey Mishchenko, Pamela Mishkin, Vinnie Monaco, Evan Morikawa, Daniel Mossing. Tong Mu. Mira Murati, Oleg Murk, David Mély, Ashvin Nair, Reiichiro Nakano, Rajeev Nayak, Arvind Neelakantan, Richard Ngo, Hyeonwoo Noh, Long Ouyang. Cullen O' O'Keefe, Jakub Pachocki, Alex Paino, Joe Palermo, Ashley Pantuliano, Giambattista Parascandolo, Joel Parish, Emy Parparita, Alex Passos, Mikhail Pavlov, Andrew Peng, Adam Perelman, Filipe de Avila Belbute Peres, Michael Petrov, Henrique Ponde de Oliveira Pinto, Michael, Pokorny, Michelle Pokrass, Vitchyr H. Pong, Tolly Powell, Alethea Power, Boris Power, Elizabeth Proehl, Raul Puri, Alec Radford, Jack Rae, Aditya Ramesh, Cameron Raymond, Francis Real, Kendra Rimbach, Carl Ross, Bob Rotsted, Henri Roussez, Nick Ryder, Mario Saltarelli, Ted Sanders, Shibani Santurkar, Girish Sastry, Heather Schmidt, David Schnurr, John Schulman, Daniel Selsam, Kyla Sheppard, Toki Sherbakov, Jessica Shieh, Sarah Shoker, Pranav Shyam, Szymon Sidor, Eric Sigler, Maddie Simens, Jordan Sitkin, Katarina Slama, Ian Sohl, Benjamin Sokolowsky, Yang Song, Natalie Staudacher, Felipe Petroski Such, Natalie Summers, Ilya Sutskever, Jie Tang, Nikolas Tezak, Madeleine B. Thompson, Phil Tillet, Amin Tootoonchian, Elizabeth Tseng, Preston Tuggle, Nick Turley, Jerry Tworek, Juan Felipe Cerón Uribe, Andrea Vallone, Arun Vijayvergiya, Chelsea Voss, Carroll Wainwright, Justin Jay Wang. Alvin Wang, Ben Wang, Jonathan Ward, Jason Wei, CJ Weinmann, Akila Welihinda, Peter Welinder, Jiayi Weng, Lilian Weng, Matt Wiethoff, Dave Willner, Clemens Winter, Samuel Wolrich, Hannah Wong, Lauren Workman, Sherwin Wu, Jeff Wu, Michael Wu, Kai Xiao, Tao Xu, Sarah Yoo, Kevin Yu, Qiming Yuan, Wojciech Zaremba, Rowan Zellers, Chong Zhang, Marvin Zhang, Shengjia Zhao, Tianhao Zheng, Juntang Zhuang, William Zhuk, and Barret Zoph. Gpt-4 technical report, 2024. URL https: /ttp:::://axiv..ooo wwwpxxivvoorgg/oooooo wtwp///a//a.///////// 6, 20, 25, 26, 31
Vardaan Pahuja, Yadong Lu, Corby Rosset, Boyu Gou, Arindam Mitra, Spencer Whitehead, Yu Su, and Ahmed Hassan Awadallah. Explorer: Scaling exploration-driven web trajectory synthesis for multimodal web agents. In Findings of the Association for Computational Linguistics: ACL 2025, pp. 6300-6325, Vienna, Austria, July 2025. Association for Computational Linguistics. ISBN 979-8-89176-256-5. URL https::/acllattholoog www.aaannnoooooggggoaaeooeo wtt///25..inninnss........ acl..26/. 3,
Martin L Puterman. Markov decision processes: discrete stochastic dynamic programming. John
Wiley & Sons, 2014. 4
Yujia Qin, Yining Ye, Junjie Fang. Haoming Wang, Shihao Liang, Shizuo Tian, Junda Zhang, Jiahao Li, Yunxin Li, Shijue Huang, et al. Ui-tars: Pioneering automated gui interaction with native agents. arXiv preprint arXiv:2501.12326, 2025. 1, 6, 7, 20
Christopher Rawles, Sarah Clinckemaillie, Yifan Chang, Jonathan Waltz, Gabrielle Lau, Marybeth Fair, Alice Li, William Bishop. Wei Li, Folawiyo Campbell-Ajala, Daniel Toyama, Robert Berry, Divya Tyanagundlu, Timothy Lillicrap, and Oriana Riva. Androidworld: A dynamic benchmarking environment for autonomous agents, 2024. 2, 3, 6, 7, 3,
12

---

Published as a conference paper at ICLR 2026
Zhihong Shao, Peiyi Wang. Qihao Zhu, Rumxin Xu, Junxiao Song, Mingchuan Zhang, Y.K. Li, Y. Wu, and Daya Guo. Deepseekmath: Pushing the limits of mathematical reasoning in open language models, 2024. URL httpps:/aarxw..org/bb///// 03300. 15
Brandon Trabucco, Gunnar Sigurdsson, Robinson Piramuthu, and Ruslan Salakhutdinov. Insta: Towards internet-scale training for agents, 2025. 2, 3,7
Guanzhi Wang et al. Voyager: An open-ended embodied agent with large language models. In arXiv:2305.16291, 2023.
Xinyuan Wang, Bowen Wang, Dunjie Lu, Junlin Yang, Tianbao Xie, Junli Wang, Jiaqi Deng, Xiaole Guo, Yiheng Xu, Chen Henry Wu, Zhenman Shen, Zhuokai Li, Ryan Li, Xiaochuan Li, Junda Chen, Boyuan Zheng, Peihang Li, Fangyu Lei, Ruisheng Cao, Yeqiao Fu, Dongchan Shin, Martin Shin, Jiarui Hu, Yuyan Wang. Jixuan Chen, Yuxiao Ye. Danyang Zhang, Dikang Du, Hao Hu, Huarong Chen, Zaida Zhou, Haotian Yao, Ziwei Chen, Qizheng Gu, Yipu Wang, Heng Wang, Diyi Yang, Victor Zhong, Flood Sung, Y. Charles, Zhilin Yang, and Tao Yu. Opencua: Open foundations for computer-use agents, 2025. URL wwttt:ttsss//t//eee wwg. wtw.ooogg///aaaaaeeeeeee abs////s....////////////// 09123.
Jason Wei, Xuezhi Wang. Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed Chi, Quoc Le, and Denny Zhou. Chain-of-thought prompting elicits reasoning large language models, 2023. URL https::/arrivv.rrgabbbs////////
11903. 6, 25
Jingxu Xie, Dylan Xu, Xuandong Zhao, and Dawn Song. Agentsynth: Scalable task generation for generalist computer-use agents. arXiv preprint arXiv:2506. 14205, 2025. 2, 3, 7, 8, 28
Tianbao Xie, Danyang Zhang, Jixuan Chen, Xiaochuan Li, Siheng Zhao, Ruisheng Cao, Toh Jing Hua, Zhoujun Cheng, Dongchan Shin, Fangyu Lei, Yitao Liu, Yiheng Xu, Shuyan Zhou, Silvio Savarese, Caiming Xiong, Victor Zhong, and Tao Yu. Osworld: Benchmarking multimodal agents for open-ended tasks in real computer environments, 2024. 2, 3, 6, 30
Yiheng Xu, Zekun Wang, Junli Wang, Dunjie Lu, Tianbao Xie, Amrita Saha, Doyen Sahoo, Tao Yu, and Caiming Xiong. Aguvis: Unified pure vision agents for autonomous gui interaction, 2024.
Yan Yang, Dongxu Li, Yutong Dai, Yuhao Yang, Ziyang Luo, Zirui Zhao, Zhiyuan Hu, Junzhe Huang, Amrita Saha. Zeyuan Chen, Ran Xu. Liyuan Pan, Caiming Xiong, and Junnan Li. Gtal: Gui test-time scaling agent, 2025. URL https://arxiv.orr htgg//bbb/200 85791. 5, 6, 20, 30
Shunyu Yao, Howard Chen, John Yang, and Karthik Narasimhan. Webshop: Towards scalable real-world web interaction with grounded language agents. In S. Koyejo, S. Mohamed, A. Agarwal, D. Belgrave, K. Cho, and Oh (eds.), Advances in Neural Information Processing Systems, vol- ume 35, pp. 20744-20757. Curran Associates, Inc., 2022. URL https: /ttp://eenoooooo.oooooor//o neurips. cc/ paper__ileesppperr//ae
Shunyu Yao, Noah Shinn, Pedram Razavi, and Karthik Narasimhan. 7-bench: A benchmark for tool-agent- interaction in real-world domains, 2024. URL pittps://arxili or org. /taaabbs/266. 12045. 3,3
Shuyan Zhou, Frank F Xu, Hao Zhu, Xuhui Zhou, Robert Lo, Abishek Sridhar, Xianyi Cheng, Yonatan Bisk, Daniel Fried, Uri Alon, al. Webarena: A realistic web environment for building autonomous agents. arXiv preprint arXi::2307.1388 2023, URL
dev. 1,
Yifei Zhou, Qianlan Yang. Kaixiang Lin, Min Bai, Xiong Zhou, Yu-Xiong Wang, Sergey Levione, and Erran Li. internet agents. In ICML, 2025. URL https://arxivv http://aaaii...oga/////2/2.12 13194. 7,
(PAE): Autonomous skill discovery for foundation model
13

---

Published as a conference paper at ICLR 2026
Verifier Model
Accuracy (1)
Precision (t)
Recall (t)
GPT-4o
59.3
56.9
82.8
VWen5 Instruct
61.8
57.7
95.9
Table 4. Verifier analysis: Human evaluation of verifier accuracy on AndroidWorld data.
Verifier
Pass @ (1)
Pass@5 (1)
Dataset Size
GPT-4o
40.1
58.4
8k
2) Qwen2.5-VL 72B
38.6
54.5
12k
Table 5. Verifier Ablations. Evaluation results of training Qwen-VI, 2.5 7B using SFT with different verifiers on WarloidWorld.
A ADDITIONAL EXPERIMENTS
Impact on distillation performance with different ver- ifiers. In this section, ablate the choice of verifier model used for data filtering for SFT and its impact on downstream performance. Specifically, proprietary MILMS like GPT-4o vs. open-source MI.LM Qwen2.5-VL. Instruct. This experiment is especially im- portant to evaluate what capability level is required in MLLM to be used as effective verifier and whether smaller open-source MILMs can be used as effective veri- fiers to enable RL scaling as proprietary models cannot be used due to cost implications. To do so, we use all ~20 tasks and demonstrations generated by our synthetic task proposer and exccutor and verify these using both GPT-4o and Qwen2.5-VL Instruct 72B to create two SFT datasets. In Tab. 5, present results of finetuning Qwen2.5-VL Instruct 7B model on these trajectory datasets and present evaluation results AndroidWorld benchmark. We find that model trained on GPT--oo verified trajectories out- performs Qwen2.5-VL Instruct 72B verified trajectories,
compare of
64
Success Rate
56
48
40
Rassgi61
Rass@ic5
Esparig<-i
Expertat-5
3B
78
32B
728
Model Size
Figure 5. Effect of incrcasing model size in AUTOPLAY.
however, the difference in performance is quite small 1.5% suggesting smaller open-source models capable verifiers that can enable RL training in mobile-use domains.
A.I GENERALIZATION RESULTS
So far for all experiments we have used same of training and environments. Even though these experiments demonstrate effectiveness of our pipeline in providing broad coverage over training task distribution and its impact downstream performance, another important question is: How well do agents trained using synthetic data generalize to unseen environments compared to training on test environments? To study this question we holdout mobile applications (Settings, Markor, Simple Calendar Pro, Pro Expense, Broccoli-Recipe App) from our training split and evaluate generalization to these apps zero-shot at test time. Due to limited number of environments we train 5 separate models while holding out data from a single environment. In addition, on data collected in the held out environment. We compare the results zero-shot generalization to held out environment with agents trained only data from held out environment in ??. We find that agents trained on larger datasets generalize comparably well to unseen (or test) environments compared to training agents data collected in test environments.
also train a model only
14

---

Published as a conference paper at ICLR 2026
B TRAINING DETAILS
B.1 ALGORITHM PARAMETERS
We provide parameter values for AUTOPLAY, as listed in Algorithm 1, for both Android and
OS World experiments:
Parameter Name
AndroidWorld
OSWorld
S of apps
20
13
K # of exploration turns
3
5
P # of task guidelines
4
4
K # of task generations per guideline and context
50
50
B.2 RL TRAINING DETAILS
We use GRPO (Shao et al., 2024) for our RL finetuning experiments using H100 GPUs. As we require MLLM verifier for evaluating task success and reward generation we use 2 GPUs on everywhere GPU node to host the Qwen2.5-VL. Instruct 32B (Bai al., 2025) MILM using vLLM (Kwon et al., 2023) inference engine. The verifier only takes the final 8 frames of task exccution as input and predicts a binary evaluation of the task execution in addition to reasoning and task summary described in Sec. 3.3.
Each GPU node runs environment workers and RL trainer on the GPUs with 8 environments per GPU. We evaluate the policy after 120 GRPO updates. This is equivalent to 8 x 24 x 16 x 120 368, 640 environment samples. Additional hyperparameters are detailed in Tab.
C ADDITIONAL AUTOPLAY DETAILS
C.I TASK PROPOSER AGENT
AUTOPLAY task proposer agent operates in stages where it first explores the environment in goal-agnostic manner to collect experience from the environment that can aid in synthesis of high-quality task that are grounded in environment state and feasible execute. The task proposer takes as input the task proposer prompt, coal-agnostic exploration observations and task guideline prompt to generate a sequence tasks. We present the task proposer prompt prefix in Appendix C.I.
Next, for mobile-use domain we define 4 separate task guideline prompts that are specific to mobile- use domain which the task proposer uses addition exploration experience to generate tasks. These prompts cover tasks of following types: (1.) Feature-Use Appendix C.I: Tasks that use basic features of the app and provide broad coverage over all features shown, (2.) Cnature-Composition Ap- pendix C.1: Tasks that composes multiple feature-use tasks create complex tasks with multiple subtasks, (3.) Information Retrieval Appendix C.I: Tasks that require searching for specific infor- mation requiring answering queries asked by users about state of the environment, (4.) Feature- Repetition Appendix C.1: Tasks that require executing feature-use tasks over multiple entities stored in an application (e.g. deleting multiple calendar events).
For computer-use domain we define 2 separate task guideline prompts mentioned in Appendix C. and Appendix C.I.
Task Generator MILM Prompt (Mobile-Use: Android and Computer-Use: Ubunt)
capable UT understanding agent. You will provided agp that shows different features and the current state of the spp. Your Lask is to convert the tasks
Images the (PLATFORM)
described Functionalities into to conplete. Use the images fron the app to ground these tasks to the ones that are feasible. Propose as many diverse tasks as posstble caver broad range features.
understanding agent should
For all descrthed and demonstrated functioralsties output a 1ist of up to (NSKSTASKS) unique tasks app which should be following fornet:
15

---

and Published as a conference paper at ICLR 2026
Parameter
Value
Number of GPUs
Number of environments per GPU
8
Rollout length
16
GRPO Group Size
Number of mini-batches per epoch
LR
1.e
Entropy coefficient
0.0
KL divergence coefficient
0.0
LR scheduled
10 linear warmup steps from 0 LR to le-6 LR
Max gradient norm: 1.0
Optimizer
Adam
Weight decay
0.0
Table 6. Hyperparameters used RI. finetuning using GRPO.
Lasks
"thought": '<Detailed thought and enough to execute and whather satisfies the task proposal gutdelinas?", "instruction's snatural language instruction describing with/without template parens with nate of the app?,
for the task, why task simple
"tag": <few words describing the type tasks, "app_.naee":
of the app?.
"template parans":
"paran_name".
"descriation". sparan descriptions
"possible.values:: [slist randon
TTASK_GUTOELIE IIE__NNOPPPPTT
(ENVERORMENT_EGN) _EONTEXT)
Feature-Use Task Guidelines Prompt (Mobile-Use: Android)
For each functionality/feesurrs nake sure to follow these guidelines while generating tasks:
1. Create possible tasks. example, there worldeide clock feature then you can create tasks like: "Add dorldwide clack for <city>", "Remove worldxide clock for <eily>", "Add wor Idwide clock for seityal, cily_2> and rearder to put <eity_2> before <city_1>". Make
app the phone
add <paran> details in "templete parans" JSON allow
creation of diverse tasks.
any instruction if
going
paraneters
follewing
3. (paran_name)
fornat:
any information/evententt required entities for completing the task are paraneter prraneterized/eee periiied/eeppll templttdda For exanple:
requires
a.) for a task that requires creating notes both the nate the new note and content the should specified
b.) Similarly, if task requires editing some details describe the exact edit you't like proposing such tasks, only edits existing antities shown in the inages from the app for such tasks. If no such entities exist ask the agent first create
nake, entity
edit it.
If lask requires deleting entily. describe the entily that needs to be deleted. When preposing such a task, only ask to delete an entity that already exists as shown in the inages such tasks.
fron the then delete it.
such entities
first
requires copying entity, describe entity where it should be copied to (ex: which folder or date). when proposing such task, only ask Inages fron the agp for such tasks, and then it.
to copied
to copy entity that already exists as shown to first
such entities exist the e.) For all paraneters that are terplsted if any paroneter refers to an entity for edit. delate
list possible values only
entities
exists or will be created.
instructions unanbiguous clearly describes parformed on the
16

---

Published as a conference paper at ICLR 2026
5. Do not include tasks that require accesinn/uulaaddng//eeuu content from real world. For example, scanning document, recording new video, taking picture using canera.
6. Task instructions should be natural user requests someone eight actually ask a capable UI agent complete the app.
7. If any supports brewsing information from the web or library nake sure to include that in the task instruction. For exanple, if task requires searching for baok the web, nake include that in the task instruction.
Information Retrieval Task Guidelines Prompt (Mobile-Use: Android)
For each propesed task take sure to follow these guidelines:
Create tasks that require retrieving different lypes information that are useful for user to nake decisions. These tasks should be natural user requests soneone night ask in real world. For example, if there is calendar app on the phone you can propese tasks like: "Kou many neetings do I have scheduled for [date]?", "What neetings do I have to attend between (start_time) and (end_tine) on date [date]? List each event separated by comna". Make sure to add each templated paran (paran) "tesplate parans" in ISCN allow creation of diverse tasks.
2. Task instructions should be natural user requests sonecne right actually ask a capable uf agent complete on app. for example, "Check
current sample rate app. is bad task because of how it is specified. Instead, propese tasks like "What is the Audia Recorder app?" 'can you tell ne current sanple rate sat in the Audio Recorder app?". The latter two tasks are better because they explicitly ask for the infornation to be retrieved and are aore natural user requests.
in the Audio Recorder
current sample rate set
3. For all such tasks,
JSON which contains natural language answer to the lask, This ansser should be valid answer that can be retrieved from the agp. For exarple,
generate "answer" field in the
task "What the weather forecast should be a valid weather forecast for the specified city and date.
(city) on (date)?', the answer
4. any task instruciton there are going be templated paransters then add in following Fornat: (paran_nane)
5. For all such task propose different varieties of information retrieval tasks that require different features. Here
searching for information the app and different apps:
examples
a.)
listed the notes app?", *What todos notes app. you can ask "How nany todes
are panding for today in the list fron note eetc"
b.)
fitnees app, "What workouts do have planned for this week?", "How lang did wor kout in last week?", etc.
6. Only proposes tasks where the last action the agent should require to solve the task is to return natural language response with information requested
user, For exasple, , *What
is the weather forecast for (city) on (date)?" is good task because it requires the agent to return natural language respanse with weather forecast for the specified city and date. whereas, "How do I view the veather forecast?" or "How can set the city to [city) in weather app?" is not good task because does not specify the information to be retrieved and requires the agent show denonstration 7. Do not propose anbiguous tasks that do not specify the informstion to be retrieved. For exanple, "What the weather like?"
the
to view the weather forecast.
gonoric and should be avaided. Instead, propose tasks like "What is the weather forecast for (city) on {date)?'.
g. any app suaports browsing information from web library rake sure to incluce tasks that require searching informacion from web. For example; "How nuch is the price of a book titled (book)?", , etc.
Feature Composition Task Guidelines Prompt (Mobile-Use: Android)
For each task proposed take sure follow these guidelines:
compesition of multiple subtasks that require UI agent to sequence of subtasks across nultiple functienaltiesssuutees
1. Each task should
for exanple, if there is a clock which has worlduide clock, alarıs, and timar feature then you create tasks like: "Add derld clack for (city) then set an alarn for (tine) on days ()", "Remove dorldwide tiser for [hour) hours, (ninute) ninutes", "Delete the alarn for (tine) and delete all the world clocks". Make sure to add each templated (paran) details in "template parans" in ISCN allow creation diverse variants each tasks.
app the
clock for (city)
2. Task Instructions should be natural user requests, unanbi guous and clearly describes actual task that can be perforned on the app. For example, "Ereate calendar event for neeeting titled (title) (time) (date) for duration [duration) for neeting with Rob than delate the first event on (dste2)" is good lask as it specifies all required details. In contrast, a Lask like "Create calendar event for titled (title) on (date) then delete bad task as it does not specify the start tine/duration of the event.
first event on (date2)'
2. any instruction
there are going to be tomplated paraneters then specify it following fornat in the instruction. (paran_nase)
3. For all such tasks that require craating/addsng/cdiinng
any informatian/event/annt required entities for corpleting the task paraneterized/ terizee/ttppaated For example: e.) For notes app, "Create note titled title) with content (note_content in (fulder) folder and then delete note titled (note_tätle_2) good task it templates title, content, and location of notes.
17

---

Published as a conference paper at ICLR 2026
b.) expense app, "crease expenses for (expense_nare_") anount (anount_]), category (catagory_1), note (note_1) follosed by expense (oxpense_namo_2) anount (anount_2), category (category_2), note [note_2] and then delete all duplicate expenses". For files app, nared [nane_2), [nare_3)".
ask "Search for file naned (nane_]) and then delete the files
Do include tasks exanple, scanning document, recording a new video, taking a picture using canera. 5. If any app suaports browsing information from
require
content fron real world. For
library nake sure to include that the task instruction. For example, If a task requires searching for book the web, make sure to include (hat in the lask instruction.
Subtask Repetition Task Guidelines Prompt (Mobile-Use: Android)
For each task proposed nake sure to follow these guidelines:
1. Each task instruction you propose should repeatedly ask to execute the feature or subtask for single functionality. for exemple, if there is a calendar app on the phone which has multiple calendar events then you should prepose tasks like; "Delete events [event_ {event_2), (ovent_3)", "Delete all events on date [date_1) (date_2)", "Dalete events (event_1] on (date_1), (event_2) on [date_2], [event_3) on [date_3]" and so on. Make sure to add each templated (paran) detaily in "template parans" ISON allow creation of diverse variants each lasks, Make sure the for each instance of event in template params unique values froe screenshots shown are used.
2. Task instructions should be natural user requests, unanbi guous and clearly describes a actual task can be perforned on app.
instructions can specify sane in different ways. For example, "Dalete all events on [date_1)" can also he specified as "Delate all events (day) of the [week)", and a lask like "Delete all events on this weekend" can be specified as "Delete all events Saturay and Sunday of current week".
3. Also specify tasks in various ways that require inferring detsils of the entity being referred looking details fron the screenshot. For example, the app expanse app you specify tasks like 'Delete expenses that have expense anount greater than [amount]" or "Delete all expenses that are in (catogory) category" or "Dalete expenses that have note containing "rote_content"".
4. Propuse tasks that require repeatedly executing same feature for all types of Lasks like trestt/delete/eiit.. For example. the
propose tasks like "Create notes titled (note_1), (note_2), (note_3) with content (content_l), (content_2), (cantent_s)", "Dalete notes ticled (nate_l), [note_?), [nete_3)", "Edit titled (note_1) change contant to (new_tontent__)) ), edit sote titled (note_2) 2) to change content to [nen_content_2)" and so on. there are going be tomplated paraneters then spectfy it following
5. any instruction Fornat in the instruction: (paran_nane))
6. Do not include tasks that require sccessing/uoloddig///eee
content from real world. For exanple, scanning document, recording new video, taking picture using
7. If any app suaports browsing information from the web or library rake sure to include that in the instruction.
example, if requires searching for to include that in the task instruction.
web,
Feature-Use Task Guidelines Prompt (Computer-User Ubuntu)
For each functional tty tttt///////ar make sure to follow these daldain while generating tasks:
1. Create all possible lasks that use features shown by the desons tratinsrations. For example, there project path
the desktop then you <path> from UI or terninal", "Install an extension <extension_ nane> for auto formatting text", add the
code IDE
tasks like: "Create
"thange
settings ny editor <paran> details in "tenplate parans" in JSDN to allew creation of diverse tasks.
line-lngth <value>",
Make
2. In any instruction if there are going to ba tomplated paraneters then add it following Fornat: (paran_nane)
any infornation/evvnt/entti take sure all required entities for completing the task paraneterized/ tenplaadee....ddd.... For exanple:
3. If a task requires creating/stding/eeiin hwwpa//innenniiiinneeeeeeeeeeeee
a.) For a task that requires creating a new file in a coding IDE specify the nane of the file, parareters. Sinilarly, If
location, and content of the
requires creating
project specify the name of the project, location, and any other required delails as paraneters.
b.) If lask requires edi editing entity needs to be edited. thhnn proposing such tasks, only ask edits to existing entities shown the
details describe the exact edit you'd 'd'd like to nake, what
fror the app for such tasks. If such entities exist ask the first create one and then edit it. For example, if task requires editing a Image in image image
editing app, specify
edited, edit
nade, and any other required
details as paraneters.
c.) IF a task requires deleting an entity, describe the entlty that needs to be deleted. When preposing such lask, only ask to delete entity that slready exists shown the inages from the spo for such tasks. If no such entities exist ask the agent to first create one and then delete it.
d.) IF a task requires copying an entity, deseribe the entity that needs to be copled and copied to (ex: which fulder or date). when proposing such lask, only ask to copy an entity that already exists shown in the inages fron the app for such tasks. If no such entities exist ask the agent to first create one and then copy it.
where
18

---

Published as a conference paper at ICLR 2026
c.) paraneters are terplated any paraneser refers an entity edit. delete copy task rake sure that the list of possible values only contain entities that exists will be created.
4. Ensure that instructions
unanbiguous and clearly describes setual task that
perforned on the app.
Task instructions shauld be natural requests right actually ask capabla agent to complete on the app.
library nake sure task instruction.. For example, If task requires searching for book the web, make sure include that in the task instruction.
any supports browsing information
Feature Composition Task Guidelines Prompt (Computer-User Use: Ubuntu)
Available Prinitives:
search: sear ches for sonething using the search bar. You can optionally filter the results based the given criteria.
filter: filters the results based on the given criteria. You can compose nultiple filters to infarred using rultt_hoppreasontn properly (changing to celsius, sorting results, cosparing, nodifying the by clicking on button, etc.)
form singla filter. filter
direct,
edit: edit/nodifies
delete: deletes sonething fron the page. can also used to delece sonething fron the cart.
add: add something to the cart, You can combine multiple add prinitives, you can alse add
multiple quantities the iter.
criteria for selection/fs is nat mentioned directly, but requires frem now", "3018 repeat: repeats the results based en the given criteris. Example: add red wine, white wine. Add bottles.
cuutti_hop_reasee
reasoning be perforsed. Exanples:
incone of \$8808".
navigate: nevigales to the given URL, click link navigate to its select of the entries from list. form: fills
forn (contact, legin, enter numbers perfora calculation, filling coda; etc.). Ne can stack multiple forns to create a task.
logical operation
For each functionality/fenne
make sure to follos these guidel while generating tasks: task composition (niminun
1. Generate 18 unique tasks each with 4, prinitives
naximum 6). Hake sure the tasks are diverse and use diverse composition of primitives. Always include atleast few tasks which
pulti_hop_reaste reasening repeat, add prinitives. 2. Task instructions should be natural user requests sonecne right actually ask a capable ut agent complete
app. Tasks should notivated by daily cases.
3. For any instruction if there are going to be templated paraneters then add it in folloxing Formal: (paren_nane)
4. Ensure that instructions unanbiguous and clearly describes actual task that perforned.
Create realistic, executable tasks conhina nultiple prinitives logically meaningful sequence.
like string (e.g., "search(product, filter-(filter(priiee 19), (location, wrc)l)")
Include primitive conposition
that requtre araattnnggadddggg//dstt///////// all required entities for completing the task parameterize//eemlaatd. For example:
7.
any information/entity make sure
a.) For tasks that require adding itees, bath the iten details and quantities should be speciffed paranaters.
b.) For Lasks that require filtering, the filter criteris should be cemplated to alles diverse task variants.
c.) For tasks requiring nulti-hop reasoning, the reasoning criteria should be clearly paramaterized.
parameteri
8. IMPORTANT: Do include tasks that require accessnn/ppladdtor///aaaa content from real
world. For example, scanning documents, recording videos, taking pictures using carera.
IHPORTANT: Do generate
which require login.
18. Tasks should denonstrate corposition of prinitives working together, not just sequential execution unrelated actions.
11. Include tomplate paraneters where appropriate for task variation, with least 5 possible values each paraneter.
provided context ground task in the sereenshots. Don hallucinate any template ate paranaters.
C.2 EXPLORATION AGENT
Our explorer agent is instantiated using the implementation of the task executor agent mentioned in Appendix C.3 with two key differences. First, the task instruction for each exploration turn is a generic exploration goal of the format "Explore the APP MPME app exhaustively to access all features, functionalities and data stored on the app.". In addition, across multiple runs of exploration the explorer agent maintains an explicit memory of environment state from the past exploration turns in the same application. This memory is text representation and it is only kept in context
19

---

Published as a conference paper at ICLR 2026
when running multiple exploration turns for the same application. In order to convert exploration trajectory to the memory representation we use GPT-4o OpenAl et al. (2024) as our summarizer MLLM. Specifically, give the sequence of observations from the exploration trajectory imput to the summarizer MI.LM and ask to output a structured response that describes the functionalities of the environment observed by they agent in the exploration turn followed by description of data configs stored in the application that would be relevant for task curation. The prompt used for the summarizer MLLM is described in Appendix C.2.
Summarizer MILM Prompt (Mobile-Use: Android and Computer-Use: Ubuntu)
are capable understanding agent. You provided sequence inages app website that shows how to access different features and the data currently stored in the app Your to sunnarize actions with in detail.
features, functionalities navigated interacted
output information following format:
"action sumaary": "A bulleted list of actions taken and pages visited to explore the features funstionalities explored by agent can enable generation reaningful UI tasks. Describe the and features visited
order they explored."
explored agent generation of meeningful uI control tasks. Describe the data uncovered in the order of the they explored."
"data stored": bulleted Hist of
features
C.3 TASK EXECUTOR AGENT
Our task executor agent is instantiated modular agent that decomposes the task execution into high-level task planning using high-level planner MLLM and low-level action execution using grounding model. In addition, the high-level planner uses reflection tool which takes as input the past observation, past action taken, and current observation to describe the transition caused by action. The high-level planner MLLM takes input the task instruction, current observation, history of past actions, reflection trace past action, and outputs a high-level action. the high-level action click-based interaction then uses the grounding model localize the coordinate location.
For mobile domains, we use GPT-4o (OpenAl et al., 2024) as both the planner and reflection model, and UI-TARS-1.5 7B (Qin al., 2025) the grounding model. We provide the prompt used by the high-level planner in Appendix C.3, the reflection tool prompt in Appendix C.3, and the prompt for U1-TARS-1.5 7B grounding model in Appendix C.3.
For desktop domains, we use GPT-4o as the planner and reflection model, and GTA1-7B (Yang al., 2025) as the grounding model. We provide the prompt used by the high-level planner in Ap- pendix C.3, the reflection tool prompt in Appendix C.3, and the prompt for GTA1-7B grounding model in Appendix C.3. In the desktop setting, additionally supply the high-level policy with heuristic actions (detailed in Appendix F) to improve data collection policy success rate.
High-Level Planner MLLM Prompt (Mobile-Use: Android)
You are capable QUI assistant designed to help users navigate and interact with mobile acalications. beginning of each task, you be provided a natural language description of the task.
Then,
will provided with:
1. the screen image.
2. history actions
environment and any 3. foedback on the last action taken.
an expert critic
Your Lask to anslyge the goal, current action, think step step-by-step and generate natural language plan that clearly describes the next the far interaction. Finally, alsa
history of actions and feedback about the last
with relevant details elenent the next action deseribed in natural language single sentence. only plan for next action using actions
above. Drag action
supported,
drag.
Here are some nore guidelines:
1. If the task has conpleted, should call the terminate action.
20

---

Published as a conference paper at ICLR 2026
2. getting
sane action again. you you stuck, find aernnaaivve ways to complete the task.
trying
3. Try to accomplish task with least number actions.
4. If the previous action failed, take corrective action taking alternative action.
Goal: (TASK_INSTRUCCTON)
Action History: (ACTTON_HISTORY)
Critic Response for Last Action:
Sunnary of screen changes:
(TRANSITION,SUNARY)
Instructions: Based on the goal, current screen, history actions containing feedback about the last action, think step-by-sted and provide the plan and action.
output the action in Following format:
reason: "Step-by-step thinking
action
taken.".
action: 'The action to be taken. Choose one the available actions. eap_on__eeneet you clesent/lecatiin elenent, pnng_rress_o_eeeenee if you
long screen, If you want to tyae text in an elenent, scroll _screen if you
by the user. terninate if you want to terninate the session, savigete,bact if you want to navigate to previous screen, navigate_hhree you Mait for seconds before continuing, open_app if
question
navigate
screen,
you want specific app.".
descriptions containing visual textual details well spatial location of the UT elenent to be Interacted wfth, only sat the element description If the lag.on_elesent, ton..press.nn.eleeen.,
ceanentddsscriptinn
tepe_text_in,eemmnnt, otherwise element description to be empty string. Exanples of descriptions: circular design with pattern resembling canera shutter or nandala, in string. Select the checkbox next the
a light brown background.
Otherwise set the elenent description be label "Senenber ne' ne'.".
'The text to be entered in the UI element. Only set with value to type in the text element.".
text:
direction: direction
screen. can
[UP, DEWN LEFT, RIGHT].",
answer:
"The ansker to the question asked by the user. only set this field if the action is eapty string.",
otherwise
app opened. Only field otherwise set the app_name to be enpty string."
app_name:
open_app.
Current Diservation: (ORSERVATION)
Reflection MILM Prompt (Mobile-Use: Android and Computer-Use: Ubuntu)
You are expert in interacting and navigating mobile applications. Your task 1s to provide useful feedback For a hunan to schieve a provided gosl.
You will he given:
Image with detected elesents before
2. the description of the action the hunan takes along with any reason and references to detected
elements hefore.
3. the streen image with detected elesents efter the homen Lakes action.
task to think carefully analyze the current action, well the before and after the action. Use this information to descrtbe the changes in the screan and pravide feedback about whether
the action was successful or not.
If action changes state on screen but does not open new viea, focus on element which effected to
If the action was scroll or swipe and the uI elenents did not change, the action likely failed. If
type the field, evaluation should whether the texefield has the exact text typad in.
what do,
Feedback on action
or net.
21

---

Published as a conference paper at ICLR 2026
(TASK_ INSTRUCTTO;);
Observation before action: (PREVIOUS_ OBSERVATTONN
exacuted: (ACTION)
Observation after action:
CUURRENT.OBSERVATER
Low-Level Planner MLLM Prompt UI-TARS 1.5 7B (Mobile-Use: Android)
You
assistant.
You are GUI agent. You are given Lask and your action history, with screenshots, You need perfora action complete the as Output Fornat
Thought:
Action:
Action Space
s/peint))>
long prns_presss(ee (point- <peint>x! (point="<peinntxl y1</point>')
(conteettt)) #if you want to subsit your input. use "Wn" at the end of "content", (prontppeett y1</point>', directian= up or right or left'' ppen_app(ep_.nmee""1)
(ea[[stttt..oinn""ppintttt y1</point>', end_p press_hone
tnd.pointt'<pointtxx <point>x2 y2</point>")
press_back()
contshed "xx')) escape characters
content part ensure we
parse the content in normal python string format.
#t Note
"Toought" part. Write small plan and finally sumnarize your next action (nith its target elenent) in one part.
sentence
User Instruction TASKK_NSSTRUCTIN
(CURRENT_ (BSERAATIOON
High-Level Planner MILM Prompt (Computer-Use: Ubuntu)
which follow instruction perfarn desktop
tasks instructed.
You have good knowledge of computer and good internat connection and assusa your code will run on keyboard.
computer: for contrelling
You are on Ubuntu operating systen and the resolution of the screen is 1929x1889.
step, you observation of get:
which is the screenshot of the computer
will predict
the action the computer based on the inage.
Access following class nethods interact the
class Agent:
def click(self, instruction: str, clicckicks: int 1, button, type: str 'left', hold_keys:
[]):
"*Click on the element
Args:
instruction:str. decrthe alesent
interact detail including
visual description and function description. And make it clear and concise. For elenent like,
example you can result when you interact with it. nun_elicks.int, number
button_-tye:ste which hold_keys:list, list of keys to hold while clicking
button press be "Ieft", "middle", or "right"
done return stuun_vvlue: Union[Dict, str. List. Tuple. int, fleat, bool, NoneType] None):
End the current task with success and the required return value""
22

---

Published as a conference paper at ICLR 2026
dras_and_dreopself, caarting_descripett str, ending_description. str, held_keys:
[]):
Drag from starting description to the ending deser iption
Args:
dertiing_escrrpttionn..o a very detailed deseriation where to start the drag least full
action. This description should concise.
And make it clear
anding_descriptionsss very
description
drøg action.
This descriation should be at least full sentence. And make it clear and concise.
held.keys:List list of keys to hold while dragging
def (self):
End the current task with failure, and replan the whole task."
def tighlight..extt.spnt
starting-phrase str, ending-phrase: str):
"iighhighh text spen beiween provided starting phrase and ending phrase. Use this to highlight words, lines. and paragraphs. Args:
the phrase that highlight. If you only want to highlight one word, just pass in that single word. phrase
startingphrase:ss
the span you
span you highlight. If only want to highlight wore, just in that single word.
phrase
def (sel,,, hold_keys: List, koys: List):
* Hold list keys press list keys
Args: hold keys:Liss
keys hold
kress_keys:List, list keys
def hatkay kays: List):
Press batkey conbination
Args: keys:List keys to press in conbination
(e.g- ['etrl', (e13)
def open(self, , app_ar_ finnane:::
Open any application or file with nare apo-or_filenane, Use this action to open desktop, open manually.
applications
Args:
app_or_ fileor_fillnannsssrr the
application
to open
scroll (self, Instruction:
shift: bool False):
Scroll the elesent in the specified direction
Args:
instruction:str. very detailed description of which element to enter scroll in. This sentence, nake
description should clicks:int, the number of clicks to scroll be positive (up) negative (down). bhalt: whother to use sttscool for horizontal scrolling
least
cancise.
set_cell (sele cell_values: Dict[str, Anyl. app_name: str, Use this to set individual cell values in spreadshset.. For exarple, setting to "hella" would done by passing (C"A2"; "hella")) cell_values. sheet nust be opened used.
str):
this connand
Args:
cell_values:
values The keys are the cell coordinates in the format "Al", "B2", etc. Supported
Any., dictionary
the spreadsheel.
types include:
int, string, bool, formulas.
app_nane: str, The name of the spreadshest. application. For exanple, Some_sheeet xlax".
sheet_nase: str, The nane the sheet in the spreadsheet, For exanple, "Sheec1",
switch. switch.ssplication.. isplicctioossseel app_code): Switch to different application that is already open Args:
app_code:ste str the code nase of the appl lcation to switch to from the provided 1ist of open applications
", overarite: type(self. sexzent_descriptionn (ptional[str] Nene, False, enter: boel False): Type taxt inta specific
Args:
element despentteeecrrtiinssttte detailed description of which elenent to enter text in.
This descristion should be least full sentence.
23

---

Published as a conference paper at ICLR 2026
text:str, text to type overurite:baol, Assign it True if the text should overurite the existing text, otherwise assign to False. Using this argunent clears all text in an element. enter:beol, Assign it True if the enter key should pressed after typing the text, atherwise assign it False.
wait( time: float): Nait for specified anount of time
Args: fime:float the
tine wait in seconds
The following rules are IMPORTANT:
expested result, not repeat then, aspecially the one. Try to adjust either the coordinate or the action based the screenshot.
previous actions didn't
Do not predict multiple clicks at once. Base each action en the current screenshot; de not predict actions for elements
visible in the screenshot.
You cannot complete the task by outputting text content in your response. You must use nouse and keyboard interact with computer. call .* aggnt. ()** Function when you think can not be done.
use only nelhods.
provided
should provide detailed observation of screenshot in detail in the "Observation:" section.
based the full
Provide any information may affect the task execution, such as pog ups, notifications, error messages, loading states, etc...
possibly
achieving goal any
You HUST return the observation before the thought.
You should think step by and previde detailed thought befera generating the astion:
Thought:
Step by Step Progress Assessment:
Analyze completed parts their contribution overall goal
Reflect patential errors. unexpected results, obstacles
If previous action was incorrect, predict logical recevery step
Next Action Analysts:
List possible next actions based on eurrent state
options considering current state previous Prepose nest legical next action
Anticipate consecuances
proposed action
Your thought should returned in "Thought:" section. MUST the thought before the code.
requirad
"agent" class nathods perfarn action grounded
observation.
Return exactly ONE line of python code to perforn the action each Line. At each step (exasple: ** clickt ('Click
button', , 'Ieft') "
Remember you should only return ONE line of code, DO NOT RETURN nore. You should return the code inside block, like this:
""pythan
agent. ('Click \"Yes, trust the authors)* button 1, "left")
For your reference, you naximum (MAX_STEPS) steps, current step {CURRENT_ _SEP) out of (NAX_STEPS). you the step, you should return agagg done() agent, fail() "* according result.
guidelines you:
1. Renember to generate the correspending instruction to the code before If in connent and only code.
return
2. "agent.click click" can have nultiple clicks. For example, agent. click'llic \"Yes, trust the authors\" button' ', 2, "left") is double click.
think the task evaluating whether the task has been successfully cospleted). Return """agent.falll)"" in the you
3. Return *** "agent.c dene()d
the code bleck
(Be careful when
block
4. Whenever pessible, your grounded action should use hot-keys with the agent. hotkey] action instead clicking dragging.
5. Save sodi fied files before returning "" "gaagtnt, done()) "*. When you finish sadi file, 's'J)"" or equivalent. Tasks nay each after finishing modification.
always save it before proceeding using agent, holkey(I'
involve nultiple files.
6. If you neet "Authentication required" proupt, you can continue to elick "Cancel" to close it.
My computer's password is 'password', feel free to use it when need sudo rights.
Task Instruction:
(TASK, INSTRIINSTUCTIONN
24

---

Published as a conference paper at ICLR 2026
(D8SERVATION)
Low-Level Planner MLLM Prompt- GTA1-7B (Computer-Used Ubuntu)
You are an expert UI element locator. Given a GUI inage and user's elenent description, provide the coordinates the specified element single point. the resolution is height (HEIGHT) and width (MIDTH), For elements with area, return the center point.
Dutput the coordinate pair exactly: (x,))
Task Instruction: (TASK_ )
(CURRENT_
C.4 TASK VERIFIER
To verify if task executed by the data collection policy is executed successfully, employ MLLM as a task verifier that evaluates trajectories. The verifier an MLLM that takes as input the task instruction and the executed trajectory (represented interleaved images and actions). For each example it outputs the following in order: (i) screen_detaiks summarizing what the agent is doing in the trajectory, (ii) reasoning: producing
Sfhii--ff-Thoueee (Wei al., 2023) justification of whether the instruction has been completed, and (iii) result: issuing a final judgment of "success" or "failure." We use GPT-4o (OpenAI et al., 2024) the task verifier on expert-collected trajectories and Qwen2.5-Ve VI 32B Instruct [(Bai et al., 2025) for RL training. The prompt used by both verifier models specified in Appendix C.4.
Task Verifier Prompt (Mobile-Use: Android and Computer-Use Ubuntu)
are an assitant designed help users evaluate whether specific interaction appl fcation was successful or not, At the begining of the task will be provided:
1. description of the task
2. sequence of ut screenshats interleaved with actions taken in order to complete the specified
taken, you dot indicating where the interaction executed, and for the action Laken.
provided action type, location
screen
task carefully look all the screenshots shown, the description of the task, and actions taken to avaluate whather the specified task was completed ar not, A task is anly considered completed
intended being achieved. show any unintended changes to the state of the app then the demonstration of cask is treated failure.
only
Task instruction: (TASK, INSTRUCITT))
Observations: NNEEVAATTOS.NNTTAAACTOOO
You should output the evalustion response in the following JSON fornat:
'scrren_detatla": "A bulleted 1sst of all the changes on the screens result of all actions executed. Even if the sereen change do not carrespond to the intended actions, you should still describe the screen as a result of all the actions."
Create detailed list of all the changes that occurred the
'reasoning": "Step-by-step reasoning for the assesment of whether the agent was successful for current stop
agent
current step.",
"result": "Assessment of the task corpletion given the last screen. Choese one of the available agent successfully completed assigned fail if you think the agent was unsuccessful in performing the given task
D TASK CATEGORIZATION FOR ANALYSIS
To support the analysis in Sec. 4.2, each task is classified to multiple task categories that describe the types of skills required by agent complete the task. To annotate each task, we L.M
25

---

Published as a conference paper at ICLR 2026
Task Category
Description
1) create
creates new entity in the app.
2) edit
modifies an existing entity in the app.
3) delete
deletes entity from the app.
4)
search
searches for something using the search bar. You can optionally filter the results based on the given criteria.
5) filter
filters the results based on the given criteria. You can optionally compose multiple filters form single filter. A filter can be direct, or it needs to be inferred using multi hop reasoning. repeatedly applies certain reaate/editddelete/saacc operation multiple times to execute a task. For example, deleting multiple events in calendar or all events on single day.
repeat operation
7) information retrieval
retrieves information from the app. This can involve answering questions about certain setting or data from an app
8) multi hop reasoning
involves reasoning across multiple steps pieces of information to arrive at a conclusion.
example, answering question that requires searching for data using multi-hop reasoning.
9) edit system setting
modifies a setting at the system level on the device. modifies setting within specific application.
10) edit app setting
11) fill form
completes a form with the necessary information.
12) text editing
makes changes text, such as editing, formatting, or restructuring. involves interacting with multiple applications to complete a task. involves interacting with complex UI elements like timers and date time picker wheels.
13) cross app interaction
14) complex ui interaction
15) composition
involves executing task that requires completing multiple sub-tasks of different task categories to complete longer horizon task. For example, tasks that require adding a new contact and deleting one involves executing both create and delete operation.
Table 7. Task Categories used for categorization of mobile-use tasks Android and AndroidWorld.
(GPT-4o (OpenAl et al., 2024) in this case) and prompt it using the prompt specified in Appendix D using platform-sper -speiofiiscccccccccc categories specified in Tab. 7 for mobile-use agent tasks and Tab. 8 for computer-use agent tasks.
Task Classifier Prompt (Mobile-Use: Android and Computer-Use: Ubuntu)
You are helpful assistant that can help analyze the task can Identify the task categories which uniquely describe the types lasks and skills required by a GUI agent to corplete the task. input will previded list task instructions and task is output list of task categories that apply to the specified instructions. Next, we will list the type label
catagories you
using following categories:
(TASK_ CATEGGATTE))
For each task instruction, have
format.
A list of task catogortes that apply to the specific task instruction. response.
only list task categories listed
Here examples of task categorization.
Instructions:
"treate with (haurs) haurs, (ninutes)
and (seconds) seconds. De
tiner.",
"Add the expenses expenses. jog in Simple Gallery pro expense.", "Change the thene to (thene) in the Audio Recorder app.
Output:
with (hours) hours, (ninutes) ninules, {seconds) seconds. Do not start the timer.".
instroctiin:
"task_categories""
26

---

Published as a conference paper at ICLR 2026
Task Category
Description
1) create
creates a new entity the application. modifies existing entity in the application. deletes an entity from the application.
2) edit
3) delete
4) filter
filters search results or data to operate on based the given criteria. You can optionally compose multiple filters to form a single filter. A filter can be direct, or needs be inferred using multi hop reasoning. repeatedly applies certain create/ediitddeleeessees times to execute a task. For example, deleting multiple events in calendar all events on single day.
5) repeat operation
operation multiple
6) information retrieval
retrieves information from the app. This can involve answering questions about certain setting data from an app involves reasoning across multiple steps or pieces of information to arrive at a conclusion. For example, answering question that requires searching for data using multi hop reasoning.
7) multi hop reasoning
8) file management
involves managing files and folders the computer. involves writing code to accomplish a specific task or solve a problem. searches for information on the web using a search engine.
9) coding
10) web search
11) device search
searches for information on the computer file system.
12) cross app tasks
involves interacting with desktop multiple applications to complete a task. modifies setting within specific application.
13) edit app setting
14) edit system settings
modifies setting at the system level on the computer.
15) composition
involves executing task that requires completing multiple sub tasks of different task categories to complete longer horizon task. For example, tasks that require adding new contact and deleting one involves executing both create and delete operation.
16) content editing
tasks that require editing content such as text, images, videos, audio. tasks that require editing or manipulating data in spreadsheet application. tasks that require editing formatting documents, such as word processing files or PDFs.
17) spreadsheet editing
18) document editing
19) bash scripting
tasks that require writing executing bash scripts or commands using the terminal or code editors.
Table 8. Task Categories used for categorization of computer-use tasks Ubuntu and OSWorld.
27

---

Published as a conference paper at ICLR 2026
"create',
"coxplex of interaction"
).
instructtttt: "Add the from Simple Gallery pro expense."
catkoccate,,ssss".
"create",
"cross app interaction',
'fill form"
)
"task_instructtor"" "Change "task_cateegrrie ies": "edit app setting"
[thene) Recorder app.",
Next. you provided as input your output specified
E TASK PROPOSER ANALYSIS
In this section, we describe the prompts and setup used to synthesize data used for No Exploration and Iterative Exploration task generators for comparison with AUTOPLAY.
No Exploration: We use the prompt mentioned in Appendix E to instantiate the No Exploration method. In order provide high-quality environment context we manually write text descriptions for all 20 android applications we use for generating training data. Each of these description aims to enumerate the list functionalities accessible in an application. This information is gathered by us manually by exploring each android application manually which is a key limitation of this method. show example descriptions of two applications Appendix
Iterative Exploration: To instantiate the Iterative Exploration method we use the public implementa- tion of AgentSynth (Xie et al., 2025) as it demonstrates a effective pipeline for iterative exploration for data collection for web agents. We adapt AgentSynth (Xie et al., 2025) for mobile-use domain by using the data collection policy described in Sec. 3.3 as the task executor. We run the iterative task proposal and execution for k turns where k is randomly sampled to be between each turn can run up to 7 steps. We use steps as a limit for each subtask as we qualitatively find that subtasks proposed by such methods can be completed with 4 steps average. After all k: turns are executed the complete trajectory is hindsight relabelled using descriptions of each subtask and whether they were successfully completed not. Using this setup, we run this method generate 5k tasks and use trajectories where atleast 50% subtasks succeeded as our training dataset.
8 turns and
No Exploration Task Generator MILM Prompt
You are capable UI understanding agent. You will be provided app description for the Android app. task propose to complete. Usa the description provided to ground these tasks to the ones that are feastble. Propose as many diverse tasks as possible to cover broad range of features.
tasks
useful u1 understaneing agent
App iption: (spp_description)
For all described functionalities outout list of to (NUK, TASKS) unique tasks that can be following foreat:
app ISON
Lasks
"thought"; '<Detailed thought and reasoning for the proposed task, why is the Lask simple proposal guidelines?", "instruction"; <natural language instruction describing task with/sithout template parans name the apa?, "tag": efew words describing the of tasks, "app_nane": <name of the app?. "template parans":
enough execute
satisfies
"paran_nane"::
"descriation'; <paran description>,
28

---

Published as a conference paper at ICLR 2026
vpoues [<list randon values>]
For each Functionality ttyti rake sure to follow these guidel while generating tasks: 1. Create possible tasks. example, there worldxide clock feature then you can create tasks like: "add korldwide clock for <eity>", "Remove worldnide clock for <eily>", "Add worldwide clock for seity-l, city_2> and rearder to put <eily_2> before <city_1>", Nake
clock app the phone
add <paran> details in "template parens" JSON allow creation of diverse tasks.
any instruction if
going templated paraneters then add it following
3. If (paran_name)
format:
requires creating/adding/edtttin hetiin///ttiin/eleettee any infornation/event/entt required entities for completing the task are paraneter peranetrrized/eeee weriiied/eepplle tenp/teeeatddd For example:
5.) for a task that requires creating notes both the nate of the new note and content of the should specified
b.) Simtlarly, if task requires editing sone details deseribe the exact adit you' like to entity
be edited. when proposing entities shown in the inages from the app for such tasks. If no such entities exist ask the create
tasks, only edits existing
edit If lask requires deleting entily. describe the entily that needs to be deleted. When preposing such a task, only ask to delete an entity that already exists as shown in the inages fron the for such tasks. then delete it.
agent
such entities
first create and
requires copying entity, ibe entity where it should be copied to (ex: which fulder or date). when proposing such task, only ask inages the app and then it.
If
copied
to copy entity that already exists shown to first e.) for all paraneters that are terplated if any paraneter refers to an entity for edit. that list possible values only exists or will be created.
tasks,
such entities exist ask the
delate capy
entities that
instructions are unanbiguous clearly describes actval perforsed on the app.
world. For 6. Task instructions should be natural user requests someene right actually ask capable us agent complete the app.
5. not include tasks
require becsaing//allannngeeeettttt content exanple, scanning docunent, recording
video, taking picture using
7. If any supports browsing information from the web or 1[brary nake sure to include that in the instruction.
exanple, if requires searching for include that in the task instruction.
the web,
App Description Examples (Mobile Use: Android)
#E* Audio Recerder app
The Audio Recerder app is versatile and user-friendly application designed for recording audio range of custonizable sestings. caters personal, educational, and professional aucio recording needs offering options to select recording fornats, sasple rates, bitratas, and channel counts, The app also provides features for thene custonization, file nanagement, and tasks.
sharing, taking suitable for various aucio
parsonalize app's appearance selecting thenes such Blue Gray, Black, Teal, slue, Purple, Pink, Orange, Red, and Brown. This feature enhances the user experience by allowing visual custonization.",
"Thene Custonization:
"Recording Format Selection: Users choose between M4, Nay, and 3gp fornats. M4a recomnended for its good quelity and stall size, May is uncorgressed and takes nore space, and 3go This feature sllows
suitable for saving size to their needs.",
tailer the recording quality and file
44,1 and 48k87, anabling users to select the desired audio quality. Higher sesple rales provide better sudio quality.". choose fron kbps, kbps, 128 khps, 197 kaps, control the audio quelity and file sice. Higher bitrates result in better audio quality.".
"Sample Rate Selaction: offers options for
16KH2, 22KHz,
"Bitrate Selection: Usars
258 kbas
"Channel Count: Optiens for Stereo and None recording, providing flexibilicy in audio capture. channel.'.
Sterea offers two channels for richer sound, while
"File Hanagenent: Includes file broaser to access recorded files, opttons to renare, view detailed information (foreat, bitrate,
sample rate, duration. size, creation date), organize files by date. and a trash feature where deleted files are stored for 68 days before persanent deletion, This feature aids in efficient file organization "Recording Interface: Displays recording tine, file size, fornat, and sample rate during recording, with easy access to settings and file management. Users can start, pause, and stop recordings, view
location,
retrieval."
waveforn the audia
recorded.",
29

---

Published as a conference paper at ICLR 2026
Action
Description
click
Click on (x, y) coordinate
long_
Tap and hold on (x, y) coordinate
input_text
Types "text' in a textbox if active
open_app
Opens android application given as text argument
scroll
Scrolls screen in direction (up or down)
wait
Waits for 'time' specified in seconds Navigates back to previous screen Navigates home screen of the device
navigate_ back
navigate home
terminate
Ends the current episode
Table 9, Action Space used for mobile-use use agent evaluated on AndroidWorld
AP Simple Calendar Pro
versatile calendar application designed to help efficiently schedules for buth personel and professional use. It offers range of features including event task ranagenent, nultiple options. users can create and organize events and tasks, set reninders, and custesize their calendar experience with color notification settings. birthdays, and anniversaries, dates.
their
views, inport/export functionality, and custonszation
app supports adding holidays, prevides options for printing schedules and navigating through
"Catendar View: Displays variaus views such as daily, weekly, nonthly, and yearly, allowing users navigate through nonchs view scheduled activities. Users can customize their vsew preferances and highlight weekands.", ",
"Event Creation: Users can create new events with details such as Litle, location, description, and color customization. Events
start and end tine, reninders, repetition settings, can be added, edited, and deleted.",
their calendar, sinilar and deadlines. Tasks can be organized and viewed In different calendar viexs.", "Search Functionality: Users can search specific events or using keywords, making it to Find events quickly.",
"Task Creation:
manage to-da lists
"Inpor t/Export Events: Users can inport events fros an ics file and export their calendar events .its file, facilitating "Print Functionality: Users can print their schodules, with options to select the number copies The app supports saving schedule
sharing and backup of schedules.".
P&F printing via connected printers.", "Add Helidays and Contacts: Users can add helicays, contact birthdays, and anniversaries to their calendar, ensuring they never niss inportant dates. The app may request access contacts this Feature.",
and paper
"Event Reminders: Users can set reminders for events to receive notifications. Options include setting reminder adding birthdays
anniversaries automatically.".
"Settings Custorization: offers options to custonize colars, widget colors, language settings, (24-hour),
highlighting. Users notifications, choose audio streans for reminders, and enable vibration for notifications." "Calor Custonization: Users can change thene app feon color, with warning about potential issues with launchers."
day,
custonize
"Go to Date: Allows users to quickly navigate to specific date in the colender.".
"About: Provides information about the app.
F ACTION SPACE
For mobile-use agents, we use the low-level action space from AndroidWorld (Rawles al., 2024) benchmark. The full list of actions used by our data collection policy and AUTOPLAY finetuned models listed Tab. 9.
For training desktop-use agents, we use hybrid action space implemented in Agent-S Agashe et al. (2025) and used by prior works (Yang et al., 2025). The full list of actions used by our data collection policy and AUTOPLAY finetuned models is listed in Tab. 10. At the low-level these actions implemented using pyautogui APIs widely used methods on the OSWorld benchmark (Xie et al., 2024).
30

---

Published as a conference paper at ICLR 2026
Action
Description
click
Click on (x, y) coordinate, num num_click times, using either left or right click button, while holding keys given by 'hold keys'
hold_and hid__and_reess press
Holds list of keys 'hold_keys' and presses keys given by "press_ keys' Invokes a hotkey combination given by 'keys'
hotkey
open
Opens the file name application specified as the argument Clicks on (x, y) coordinate, scrolls in up or down direction while holding shift key if 'shift' argument is set to true Sets individual cells in a spreadsheet to certain values Switch a different application that is already open specified as argument Type specified text in an element Wait for specified amount of time in seconds Ends the current episode and returns failure response Ends current episode
scroll
set_cell_values
switch_ sppich_applications
type
wait fail done
Table 10. Action Space used for computer-us. use agent evaluated on OSWorld. We use pyautogui action space to implement the specified actions.
G USE OF LLM FOR WRITING
We use LLMS to assist with specific aspects of paper writing which includes: fix grammatical errors, sentence polishing, and paraphrasing parts of for sections 1, and 4. LLMS were used for: (1) grammar checking and improving clarity and readability of text, (2) suggestions for writing certain sentences via paraphrasing. For each section the original content was written by the authors and edited using GPT-4o OpenAl et al. (2024) LLM. Followed by this round of LLM-assisted editing, the authors verified and polished the content written by the LLM fix issues with generated and create the final text used for the paper.
31


Reviews:
[{"review_id": "7soutG4wkR", "reviewer": "Reviewer_37mc", "summary": "This paper introduces AutoPlay, a scalable pipeline that generates synthetic tasks for training UI agents without human annotation by first exploring interactive environments to discover states and functionalities, then using these exploration trajectories with task guideline prompts to generate diverse, feasible, and verifiable tasks. The method generates 20k tasks across 20 Android apps and 10k tasks across 13 Ubuntu applications, which are used to synthesize demonstrations via an MLLM executor and verifier. Training agents on AutoPlay-generated data improves success rates on AndroidWorld and OSWorld, with an additional gain when using reinforcement learning with verifier rewards. The approach outperforms prior methods that either use limited environment information or iterative exploration, demonstrating that exhaustive exploration combined with guided task generation produces higher-quality training data for UI agents.", "questions": "1. Are there comparison results with existing task generation methods?\n2. Are there evaluation results in other GUI agent benchmarks?\n3. Do you validate the accuracy of the proposed verifier?\n4. Is it possible to disclose more details concerning the task generation process?", "limitations": "", "rating": 6, "confidence": 3, "soundness": 3, "presentation": 3, "contribution": 2, "strengths": "1. The method is simple and practical to implement, following a straightforward two-stage pipeline of exploration. It provides an effective solution for large-scale synthetic task generation, demonstrating strong improvements for both SFT and RL.\n\n2. The paper excels in clarity of presentation with well-structured sections and intuitive visual examples. The writing is smooth and clear, making the core contributions immediately accessible to readers.", "weaknesses": "1. The comparison with baselines is limited to only No Exploration and Iterative Exploration methods, missing evaluations against more sophisticated task generation approaches.\n2. The paper evaluates only on AndroidWorld and OSWorld benchmarks, insufficient for demonstrating generalization across UI domains.\n3. The verifier's accuracy is never validated despite being critical for filtering trajectories and providing RL rewards - no false positive/negative rates reported.\n4. Experimental details are insufficiently specified - specific apps, exploration steps, task sampling strategies, and app selection criteria are missing, hindering reproducibility.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "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": "tCMibik5sb", "reviewer": "Reviewer_JnXJ", "summary": "The paper proposes a new method, AutoPlay, for generating agent instructions given an environment. The paper shows how this method (given a strong verifier model) can be combined with rejection-sampling or RL over these synthetic instructions to improve an agent's performance, as done in prior work. This overall pipeline yields improvements on AndroidWorld and OSWorld. The key contribution is how AutoPlay conditions instruction generation on environment exploration. The paper shows how their particular method for doing this has advantages over prior work.", "questions": "* Do you plan to release the generated trajectories?", "limitations": "", "rating": 6, "confidence": 3, "soundness": 3, "presentation": 3, "contribution": 3, "strengths": "The proposed method is intuitively compelling. Conditioning environment exploration on previous rollouts encourages diversity. Conditioning task generation on environment exploration encourages both feasibility of generated instructions and diversity. While the general idea of synthetic instruction generation conditioned on exploration is not novel, some of the specific design decisions are different from prior work and the ablations indicate these are useful.", "weaknesses": "* The main novel aspect is generation of the instructions (not post-training a model given these instructions). It would have been useful to see more head-to-head comparisons and analysis with alternative recipes and methods from prior work for instruction generation, although I understand it is hard to quantify their utility without also tuning downstream models. As a practitioner, the main take-away is what aspects of the instruction generation method should be adopted. Table 2 provides some of this analysis, although perhaps additional analysis could be useful. This shouldn't necessarily block acceptance, just a suggestion.\n* Relatedly, it seems most of the method's advantage comes from prompt engineering of the task guidelines. Perhaps ablations could be extended to consider which aspects related to exploration are most crucial.\n\nNits:\n\n* There is some prior work on web agents that is not discussed. The recipes are similar enough to mobile and compute use agents that it is certainly relevant. For example, https://arxiv.org/abs/2410.02907 and https://arxiv.org/abs/2403.08140.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "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": "q6M65xyhwA", "reviewer": "Reviewer_3kvg", "summary": "AUTOPLAY proposes a two-stage, exploration-first pipeline to synthesize large-scale, feasible and verifiable UI-agent tasks without human labels. Stage (i) uses a goal-agnostic MLLM explorer  to discover novel states and functionalities; stage (ii) conditions an MLLM task generator on exploration trajectories plus domain task guidelines to synthesize diverse, feasible, and verifiable tasks. Using an MLLM executor and verifier, the authors collect demonstrations (no human annotation) for SFT and train with RL via verifier rewards. On AndroidWorld and OSWorld, AUTOPLAY improves success rates over base Qwen2.5-VL models across sizes (e.g., +20.6% at 7B on AndroidWorld, +10.1% at 72B on OSWorld), competes with or surpasses several strong baselines, and shows an additional +5.7% from RL. Ablations indicate both exploration and task guidelines are important.", "questions": "1. Please provide formal metrics for exploration quality: e.g., UI-state/transition coverage, unique control coverage. How closely do generated tasks match natural task distributions? Report distribution comparisions against AndroidWorld/OSWorld category or other human-annotated datasets\n\n2. I recommend a rigorous evaluation of the verifier. Please report precision/recall against a small, human-audited gold set and document any calibration or abstention policy. In addition, establish multi-judge consistency by adding a second, independent judge (e.g., an open-source LLM or simple rule-based checks) and comparing accuracy and agreement; this would materially increase confidence in the generated data quality and the reliability of rewards.\n\n3. Did you enforce strict isolation so that evaluation tasks/functions never appeared during task generation? Is there an OOD split (cross-app / cross-task )? Any results under UI perturbations (resolution, locale, light/dark theme) would make the generalization claims more convincing.", "limitations": "", "rating": 6, "confidence": 4, "soundness": 3, "presentation": 3, "contribution": 3, "strengths": "1. The paper offers originality and significance. The paper targets a central bottleneck, scalable, feasible, and verifiable downstream task data for post-training MLLM agents—and proposes a  closed-loop pipeline  that delivers substantial improvements, suggesting a general recipe for building capable UI agents and enabling RL at scale.\n\n2. Results show end-to-end gains across two established benchmarks (AndroidWorld/OSWorld) and multiple model scales. Ablations carefully compare each components, supporting the design choices.\n\n3. The paper is clear and reproducible. It decomposes the method into well-scoped components,with a consistent algorithmic framing, which facilitates understanding and reproduction.", "weaknesses": "1. Quality of Exploration (systematicity, coverage, and realism) need further analysis. The paper claims the task generator yields diverse tasks, but the exploration stage lacks formal analysis of how exploration is systematic and how coverage is measured. It also remains unclear whether the synthesized task distribution aligns with real-world task distributions.\n\n2. Verifier reliability and shared-model bias. Both the executor and verifier use GPT-4o, creating a risk of style/format bias. The entire pipeline (SFT and RL rewards) hinges on an MLLM verifier, yet no human-consistency study is reported.\n\n3. Tasks are generated on the same app suites used for final evaluation (AndroidWorld/OSWorld). Without an explicit app-level or task-level split,  it is unclear how well the trained agent generalizes to hold-out, unseen apps, and there is risk of distribution leakage.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "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": "v6SROypIei", "reviewer": "Reviewer_Pkt3", "summary": "The paper implements a system where an LLM explores a (simulated) environment to generate exploration traces and these traces are hindsight relabeled by an LLM prompted to define types of tasks to provide with goals for those traces. The method is applied in the domain of graphical user interface interactions, evaluated in the Android World and OSWorld environments. The exploration process includes compression of past experiences into text summaries for use in memory to support diversity of outputs while addressing context length limitations of LLMs. Traces from the system are used for supervised finetuning of VLMs and can be combined with the generated tasks to support VLM verifiers for RL finetuning. \n\nEvaluations compare the model against baseline UI agents and ablations of the model.", "questions": "# questions\n- How do agent performance results scale with the generated dataset size?\n\t- Even with the existing dataset, it would help to show how downstream agent training improves with subsets of the total generated interactions. This could help strengthen the claims that this approach is valuable by showing that it can provide strongly improving baseline model improvements. Right now the results saturate below strong baselines.\n- How do these results scale with repetition of the whole loop? That is: explore, train the agent (SFT & RL), then explore again.\n\t- This would strengthen the claim that the method is scalable over human annotation.\n- How do the costs of AutoPlay scale?\n\t- In terms of quantities like number of LLM calls and wall-clock compute time.\n\t- Also in terms of number of interactions or diversity of tasks.\n\t- This can strengthen the scalability claims.\n- Table 1: Is there any statistical test for differences and effect sizes that could be applied to these results?\n\n\n# suggestions / smaller details\n- Table 2: Where are the data referenced in lines 416-420? I'm not sure I follow which data are referenced by the claims about the same executor feasibility vs agent training.\n\t- Why does No Exploration show such a high Pass@5 in Android World?\n\t- What does the high Pass@1 for Task Execution of Iterative Exploration indicate (56.4% vs Autoplay with 46.0%)?\n\t- I think my confusion is different terms are used in the text and the tables, with the definitions somewhere else in the text, making the results unclear. After some reviewing I believe: task execution references the fixed executor, Pass@1 means 'average success rate' (per line 344), but the 9.4% number is the percentage point (not percentage) difference between AutoPlay and No Exploration in Android World in Pass@5 (defined to be percentage of tasks where any trial is successful on lines 346-347).\n- Section 3.4: Why use a different verifier (Qwen2.5-VL-32B-Instruct; lines 307-308) for RL instead of training data generation and verification (GPT-4o; lines 275-276)?\n- Figure 3: I do not understand how to read this figure.\n\t- What are Left vs Right in the caption? The figure has 3 subfigures. (b) is labeled \"AndroidWorld Tasks\", but the legend says OSWorld for green.\n\t- Please tell me if this is the correct interpretation: dark colors are execution success rates, light colors are proportions among the total dataset. (a) shows AndroidWorld, (b) shows OSWorld, (c) is a comparison of AutoPlay to NoExploration.\n\t- I think this should be split into different figures that are clearer. The distribution would make sense as a pie chart or side-by-side bars or stacked bars. The success rates should be visulized separately as they are semantically different. Same for the ablation (ideally adding Iterative Exploration).\n- Table 1 might benefit from including a column indicating model size. Right now many results appear underwhelming as AutoPlay performs worse than many of the baselines.", "limitations": "", "rating": 2, "confidence": 3, "soundness": 2, "presentation": 1, "contribution": 1, "strengths": "# originality\nPrimarily in the form of bringing ideas for automated exploration to bear on the GUI agent domain.\n\n# quality\nEvaluates against strong baselines and in two different, relevant domains.\n\n# significance\nScalable data generation for VLM agent training is broadly relevant to agentic AI systems in general: whether digital agents (GUI-based, here) or physical agents (robots or game playing).", "weaknesses": "# originality\nFew elements of the proposal are unique on their own. The novelty is tied to idea combination.\n\n# quality\nIt is unclear how much the model improves compared to baselines, and by how much or under which conditions. See below for detailed questions. Currently it is not yet clear to me that the framework can do more than modestly improve a weak model, which sometimes is outperformed by a baseline that ablates the exploration method (at least in some scenarios). \n\nThe results seem quite mixed at the moment and the scaling and costs are not clearly addressed.\n\n\n# clarity\nIt is very difficult to follow the experiment results narrative and how it relates to the tables. Concrete points are below. Generally the definitions and abbreviations are not clear and not well-connected by the text or captions. Figure 3 is particularly cumbersome to understand.\n\n\n# significance\nThe approach is tailored to the specific GUI task domains through the task guideline prompts and perhaps a few other design decisions. This will modestly limit the scope to the GUI agent audience.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "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:

Decision: Accept (Poster)