Agent World Model in the Wild: Computer-Use Agent Environment Synthesis
Zhaoyang Wang, Qianhui Wu, Haorui Wang, Simon Yu, Baolin Peng, Canwen Xu, Hao Cheng, Wenlin Yao, Boyi Liu, Yite Wang, Jianfeng Gao, Huaxiu Yao
WildAWM synthesizes cross-interface computer-use environments and tasks using only open-source models to train generalist agents.
How can we synthesize diverse, multi-day computer-use environments and reliable tasks to train agents without relying on limited human-recorded data?
Training computer-use agents (CUAs) in the real world is risky and costly, while existing synthetic environments often isolate interaction modes like web browsing or terminal use, failing to capture the connected nature of a real personal computer. WildAWM constructs unified personal-computer environments that integrate graphical user interfaces (GUI), command-line interfaces (CLI), and model context protocol (MCP) services, using a multi-agent pipeline to synthesize tasks and verify them through execution-based quality gates. Training exclusively in these synthetic worlds improves agent performance across eight out-of-distribution benchmarks, narrowing the gap between open-source models and proprietary frontier models.
Paper Primer
WildAWM treats computer use as a holistic workspace where websites, local files, and services coexist. The core mechanism is a skill-enhanced generator that builds these environments by materializing sequential day plans for synthetic personas, ensuring that tasks require agents to switch between GUI, CLI, and MCP interfaces to succeed.
To ensure task quality, the pipeline employs five execution-based quality gates: it uses heterogeneous agent rollouts to confirm solvability, cross-judge consistency checks to validate verifiers, and counterfactual probes to stress-test judge robustness against sycophancy. This loop ensures that the synthesized verifiers provide reliable, dense rewards for reinforcement learning.
Training on WildAWM-synthesized worlds yields broad out-of-distribution generalization.
Performance gains were observed across eight benchmarks spanning web, claw, and computer-use agent tasks, with the 35B-A3B model improving by an average of +10.58 points. The 35B-A3B model's average score rose from 42.84 to 53.42, substantially reducing the performance gap to frontier models like GPT-5.5.
Why is this approach better than simply training on existing web-based benchmarks?
Existing benchmarks often focus on a single modality, such as browser interaction. WildAWM forces agents to coordinate across GUI, CLI, and MCP interfaces, which better reflects the multi-step, cross-application workflows required for real-world computer use.
Does this pipeline require proprietary frontier models to generate high-quality data?
No. WildAWM is entirely powered by open-source models, demonstrating that high-quality, challenging environments and reliable verifiers can be synthesized without relying on proprietary frontier models.
WildAWM demonstrates that open-source models can effectively bootstrap their own training data for complex, long-horizon agent tasks, shifting the bottleneck from data collection to scalable environment synthesis.
Introduction to WildAWM
We expose the need for scalable, multi‑interface synthetic worlds to train general computer‑use agents.
Training computer‑use agents directly in real‑world systems is costly, hard to reset, and poses security risks. Existing synthesis pipelines typically target a single interface (GUI, CLI, or MCP), limiting agents’ ability to combine visual interaction, tool use, and code execution. We therefore introduce WildAWM, a scalable open‑source pipeline that synthesizes multi‑day, persona‑driven environments supporting all three interfaces and generates tasks with execution‑based quality gates to ensure solvability, difficulty, and reliable verification.
WildAWM builds complete personal‑computer worlds from personas and daily plans, then creates cross‑interface tasks that are filtered by multi‑agent quality gates to guarantee they are solvable, challenging, and correctly verified.
How does WildAWM differ from prior single‑interface synthesis pipelines?
Prior pipelines generate environments that expose only one interaction mode (e.g., GUI only). WildAWM simultaneously synthesizes GUI, CLI, and MCP interfaces within a single executable PC world, enabling agents to flexibly combine visual, command‑line, and service‑based actions.
**Figure 1.** Overview of WildAWM. The synthesis pipeline includes two stages: (1) World Synthesis, where we use the coding agent to construct persona-driven, multi-day world states for computer environments that expose GUI, MCP, and CLI interfaces. (2) XAI Task Synthesis, where we generate cross-interface tasks through 5 designed quality gates for task solvability, difficulty, and verifier reliability. The synthesized {task, environment, verifier} triplet enables training general CUA.
**Table 1.** Comparison of existing computer-use agent synthesis methods with WildAWM.
The shift from human‑collected data to synthesized‑world interaction enables scalable, controllable training of general computer‑use agents.
Synthesizing Computer Environments
World Synthesis builds a personal‑computer state day by day, yielding diverse, verifiable environments.
Existing training pipelines struggle to obtain enough varied, trustworthy interaction data. The core trick is to synthesize a personal‑computer world incrementally, letting each day extend the previous state. This yields a rich, reproducible corpus of multimodal experiences for any Computer‑Use Agent.
We start from an empty personal‑computer snapshot and, day by day, add the persona’s activities, applications, and files, so the world grows like a diary that records every interaction.
Day 0: the coding agent creates a file “todo.txt” for persona 1 and a SQLite table “contacts” for persona 2.
World after day 0: $W(1,0)=\{ \text{todo.txt} \}$, $W(2,0)=\{ \text{contacts table} \}$.
Day 1: the agent reads $W(1,0)$, adds a web‑bookmark “research.org”, and updates “todo.txt” with a new entry.
World after day 1: $W(1,1)=\{ \text{todo.txt}, \text{research.org bookmark} \}$, $W(2,1)=\{ \text{contacts table}, \text{meeting.log} \}$.
Incremental synthesis lets later days reuse and modify earlier artifacts, producing coherent, evolving user histories rather than isolated snapshots.
How does this incremental world differ from generating a single static snapshot of a personal computer?
A static snapshot cannot capture temporal dependencies—later actions would have no prior state to modify. By building $W(c,d)$ day by day, each step can reference and evolve existing files, databases, and services, yielding realistic, verifiable histories.
A CUA is an autonomous system that can issue commands to graphical user interfaces, command‑line shells, and MCP (machine‑control‑protocol) services, allowing it to operate across the full spectrum of a personal computer.
Why is a CUA more capable than prior GUI‑only agents?
GUI‑only agents can interact only with visual elements; they cannot invoke backend services or run shell commands. A CUA can bridge the GUI, CLI, and MCP layers, enabling it to perform end‑to‑end workflows such as uploading a file via a web form, then processing it with a command‑line tool, and finally storing results in a database.
Prompt a coding agent (GLM‑5.2) to generate a persona description $c$ (occupation, contacts, favorite sites).
Compare the new persona against existing ones; if similarity exceeds a threshold, regenerate with feedback.
For each accepted persona, generate a sequence of day plans $d=1\ldots D$, each listing required applications, services, and files.
Before planning day $d$, the agent inspects the previous state $W(c,d-1)$ to ensure continuity of ongoing activities.
Materialize day $d$ by reusing existing implementations and synthesizing any missing artifacts, producing $W(c,d)$.
Verify $W(c,d)$ by replaying the generated program twice and checking for identical outcomes; if mismatched, invoke a second coding agent for correction.
Materialize a day’s state from a plan.
**Table 2.** World synthesis statistics. “touched” means the number of services or databases that are modified during the day of synthesis.
Generating Verifiable Tasks
We synthesize XAI tasks by validating them with multi‑agent rollouts and quality gates.
Designing useful XAI tasks is hard: a task must be solvable, sufficiently challenging, and have a trustworthy verifier. We solve this by running heterogeneous agents on each candidate and feeding the outcomes through a cascade of quality gates that enforce those properties.
We first propose a concrete task, then automatically verify it by having diverse agents try it and checking their outcomes against a set of binary criteria.
Compute the product: $V = 1 \times 0 \times 1 = 0$.
Since $V=0$, the task is marked failed and the verifier is sent for revision.
The individual scores reveal that the GUI step is the bottleneck, guiding the generator to strengthen that sub‑task.
The verifier’s all‑or‑nothing nature forces the generator to address every missing piece, turning a vague “failed” signal into actionable feedback.
How does this verifier differ from a simple binary pass/fail check?
A simple check would return 1 if any condition is met, discarding detailed failure modes. Our verifier requires *all* $N$ binary criteria to be true, so a single missing sub‑condition forces rejection. This yields richer feedback (which criterion failed) and a stricter training signal for the RL agent.
Generate a candidate XAI task from $W_{0}$ and produce $\tau$, $V$, $R$, $h$, and the ordered sub‑task document.
Apply the diversity gate to keep the task pool varied.
Run six rollouts per task (three with hints, three without) using the 18 model‑harness pairs.
Collect trajectories and evaluate each rollout with the verifier $V$ to obtain binary criteria $v_{i}$.
Feed the results through three judgment levels: the verifier $V$, an LLM judge, and an agent judge (OpenCode) that inspects the environments.
If any judgment flags a problem, revise the verifier or the task specification; otherwise accept the task for downstream RL training.
**Figure 2.** Progression of XAI task candidates. Direct denotes sketches that pass on the first attempt, while After feedback denotes sketches that pass after at least one feedback-driven revision at any stage of the whole synthesis, thus the funnel is monotonic.
Quality Gates for Task Validation
Quality Gates filter synthesized tasks, ensuring solvability, difficulty, and verifier reliability before agent training.
Rollouts and human judgments alone do not guarantee that a synthesized task is well‑posed or that its verifier scripts are trustworthy, so we need systematic checks before admitting a task to the training pipeline.
Quality Gates are a multi‑stage safety checklist for a task, each stage discarding candidates that fail a specific solvability or reliability criterion.
Judge Consistency: both rollouts receive verdict $V(W_0,W_j,a_j)=1$ for $j=1,2$, so the gate passes.
Initial Unsatisfaction: evaluating $V(W_0,W_0,\emptyset)$ returns 0 because no script writes any file, so the gate passes.
Task Solvability: rollout 1 succeeds ($V=1$) while rollout 2 fails ($V=0$); the sum $\sum_{j=1}^{2}V=1\ge1$, so the gate passes.
Task Difficulty: the unhinted set $U$ contains only rollout 2, which fails; thus $k=0$ and the task is labeled *hard*.
Counterfactual Probe: flipping the verdict of rollout 1 to 0 leads the agent judge to still output 0, confirming stability.
The example shows how a single failing unhinted rollout is enough to flag a task as hard, while the other gates still admit it.
How do Quality Gates differ from ordinary validation checks used in data‑centric pipelines?
Ordinary checks usually verify a single property (e.g., file existence). Quality Gates combine multiple orthogonal criteria—consistency, solvability, difficulty, and a counterfactual stability test—so a task must survive a holistic, cross‑interface audit before it is considered usable.
Read the MCP chat thread and confirm the go‑ahead message.
Write and run a CLI script that merges three local sources, ranks surge‑protectors, and writes a CSV shortlist.
Open the web storefront (GUI), compare product images, and add the correct unit to the cart.
Return to the CLI to record the carted unit in a restock note file.
Send a final MCP direct message notifying the install crew of the locked unit.
**Interface flow** (mcp>cli>web>cli>mcp, five sub-tasks that revisit CLI and MCP)
**Table 4.** XAI task statistics. SR: mean success rate over synthesis rollouts from a pool of 18 agent configs; fixes: feedback-driven revisions per task at each gate. Task execution and interface usage are measured by GLM-5.2 with OpenCode. File operations include reading, editing, and creation.
Training Agents with Synthesized Data
Training CUAs with GRPO on synthesized worlds yields large performance gains across benchmarks.
Training CUAs with GRPO on WildAWM‑synthesized worlds improves average performance on eight benchmarks by 10.58 points for the 35B model.
Table 5 shows the 35B‑A3B model’s average score rising from 42.84 to 53.42 across WebArena, CLE, OSV, and other tasks.
The larger 35B model gains more than the 4B model (+10.58 vs. +8.21), narrowing the gap to frontier systems and even surpassing GPT‑5.5 on O2W.
Agents learn to act in computer interfaces by receiving dense, outcome‑based rewards that reflect both task success and checklist compliance.
What happens if the verifier provides only sparse binary rewards instead of the dense checklist‑augmented signal?
Without the checklist contribution, long‑horizon rollouts receive the same reward for many steps, leading to near‑zero variance and preventing GRPO from computing meaningful advantages, which slows learning dramatically.
Group Relative Policy Optimization optimizes a policy by comparing groups of rollouts rather than individual trajectories, encouraging diversity across reward levels.
How does GRPO differ from standard PPO, which also uses advantage estimates?
PPO computes advantage per trajectory against a running baseline; GRPO computes advantage relative to a dynamically formed group, explicitly mixing high‑ and low‑reward samples to keep the gradient informative even when reward variance is low.
We synthesize 341 XAI tasks with WildAWM, split into 100 for supervised fine‑tuning, 208 for reinforcement learning, and 33 for in‑domain evaluation, then test on eight external benchmarks covering web, claw, and computer‑use agents.
Training runs on eight NVIDIA B200 GPUs; we warm‑start Qwen models with three epochs of SFT, then perform up to 64 RL steps using batch size eight and four rollouts per task, with a context window of 100 K tokens.
Analysis of Synthesis Quality
We evaluate synthesis quality, showing WildAWM’s environments are more diverse and verifiable.
Verifier agrees with majority judgments 95% of the time, achieving Cohen’s $\kappa$ of 0.90.
Table 6 reports 95% consistency and $\kappa$ = 0.90 across 100 sampled rollouts.
WildAWM’s nearest‑neighbor cosine distance is 0.25, higher than CUA‑Gym’s 0.20, indicating lower redundancy.
Figure 3a shows the distance curves across sampling levels.
Environment diversity is further quantified by the Vendi score, where WildAWM consistently outperforms CUA‑Gym across all sample sizes, confirming that larger token budgets translate into richer, less redundant worlds.
**Figure 3.** (a) Environment diversity using Qwen3-Embedding-8B (Zhang et al., 2025b) representations of environment artifacts. Shaded bands are 95% intervals of the Vendi score (Friedman & Dieng, 2022). (b) Task solvability across 24 model–harness configurations: the three models and six harnesses in Sec. 3.2 (Rollouts & Judgments), plus Opus-4.8. (c) Solvability with hints w/o Opus-4.8.
**Figure 4.** (a)/(b) Performance on WildAWM validation set, and proprietary model sizes are estimated. (c) Rarefaction of the 341 accepted tasks by LLM-classified task types and domains.
Environment diversity metrics (Vendi score and cosine distance) demonstrate that WildAWM generates substantially richer worlds than CUA‑Gym while keeping redundancy low.
Ablation Studies
We quantify how each gate and RL component affects agent performance.
We isolate each synthesis gate and each RL component by removing it while keeping all other settings identical.
Removing the Judge Consistency gate lowers the overall average to 22.56.
Table 7 shows the average score after this ablation.
With the Initial Unsatisfaction gate removed, the average falls to 24.08.
Table 7 reports this value.
Eliminating the Task Difficulty gate reduces the in‑domain validation score to 7.58.
Table 7 lists the validation result for this ablation.
The full set of five quality gates achieves the best overall performance.
Table 7 compares the full pipeline against each single‑gate removal.
Removing the format reward decreases the average score by 1.24 points.
Table 8: “w/o Format Reward” column.
Omitting the checklist partial‑credit reward drops the average by 2.25 points.
Table 8: “w/o Checklist Reward” column.
Skipping the SFT warm start leads to a 5.31‑point average decline.
Table 8: “w/o SFT Warm Start” column.
The format reward yields a higher CLE pass rate (69.89) but a lower CLE mean (69.45) than the full method.
Table 8 reports both CLE metrics.
Without the warm start, performance degrades the most among the three RL components.
Table 8 shows the largest drop for the “w/o SFT Warm Start” variant.
**Table 8.** Ablations on RL training with Qwen3.6-35B-A3B as the base model.
Agent Behavior Analysis
WildAWM (+SFT+RL) boosts OOD pass‑rate by up to 19.9 points.
WildAWM (+SFT+RL) improves pass‑rate over the base model by up to $19.9$ points on medium‑difficulty OOD tasks.
Figure 5(a) shows a $19.9$‑point gain in the second quartile and a $12.2$‑point gain in the third quartile compared with the base model.
RL adds long‑horizon capability beyond SFT: while SFT and WildAWM solve $34.9\%$ and $36.8\%$ of tasks within $40$ steps respectively, WildAWM gains an additional $17.0$ points between $40$ and $120$ steps, outpacing SFT’s $9.7$‑point gain. +RL also improves but lags behind, reaching only $47.2\%$ at $120$ steps versus $53.7\%$ for WildAWM.
Cross‑interface interaction is transferred from the teacher: the interface‑switch rate rises from $18.4\%$ (base) to $24.7\%$ after SFT and $25.5\%$ after RL, approaching the teacher’s $GLM\!-\!5.2$ level, whereas RFT and +RL reduce the rate to $15.8\%$ and $15.7\%$ respectively.
**Figure 5.** Behavior analysis of base model, WildAWM and its variants (+RFT, +SFT, and +RL, i.e., RL without SFT), and GLM-5.2. (a) Pass-rate gain over the base model on OOD tasks, split into four equal quartiles by how many of frontier models solve each task. (b) Fraction of consecutive tool calls that switch between interface families (e.g., GUI $arrow$ CLI). (c) Tasks solved within a step budget.
Training with SFT and RL reshapes how agents switch between interfaces, yielding richer, more human‑like tool‑use patterns.
Qualitative Case Study
Analyzes policy behavior, RL gains, and a detailed case study of a synthesized agent trajectory.
After supervised fine‑tuning (SFT), agents use more interfaces per episode (2.40 → 2.61 → 2.68) and dramatically reduce GUI calls (16.3 % → 4.3 % → 1.6 %). Reinforcement‑learning fine‑tuning (RFT) preserves the base model’s interface habits (2.36 interfaces, 17.2 % GUI).
On the WildAWM‑val benchmark, the switch‑rate drops from 26.1 % (base) to 25.8 % (RFT) but rises to 37.0 % (SFT) and 35.7 % (WildAWM). RL does not improve in‑domain pass@1 (36.0 % vs. 37.3 % for SFT) yet lifts the OOD gain from +93 to +129 tasks (+73 for RFT).
RL also curtails excessively long turns: episodes with ≥8 K output tokens fall from 24.3 % (SFT) to 9.1 % (RL) and 7.4 % (GLM‑5.2). The step‑budget advantage stems from benchmarks CUG, OSV, and WA, where RL adds 72 net tasks over SFT (30 net tasks for the base model). Gains per benchmark are CUG +18.0 vs +7.5, OSV +16.2 vs +8.1, WA +16.4 vs +12.4 points. Timeouts affect only 5.5 % of episodes before step 120.
The hardest quartile tasks (mostly OS‑2 and ALE) remain challenging: the base model solves 4–7 of them, while the strongest reference (GPT‑6‑Astra) solves 18. Future work will test larger models on this tail.
The case study introduces a synthetic world centered on a freelance AV technician named Lars Petersen. His persona, contacts, applications, and three story arcs are detailed in Table 15, and the day planner expands these arcs into 17 world states with four accepted tasks on days 5, 7, and 9.
**Table 15.** Persona and story, condensed from the persona file and the day plans. The task of Table 3 is synthesized on the world state of day 7.
World synthesis draws from a library of 83 event‑creation skills; Table 17 shows the “`book_flight`” skill, which writes consistent state changes across five applications (Google Flights, email, direct‑message, calendar, and a local notes file).
**Table 17.** World synthesis skill `book_flight`, condensed from the skill file. Each scenario specifies the state changes in one application.
Task synthesis evolves 40 final skills through 802 revisions. Table 18 categorises 20 representative skills by difficulty, interface coverage, write persistence, and verifier reliability; Table 19 traces the evolution of a hard‑multi‑interface‑recipe skill across nine revisions.
**Table 18.** Evolving task synthesis skills, grouped by the task property they address. Lessons are paraphrased from the skill text. Revisions: number of revisions made during the synthesis.
**Table 19.** Revisions of the evolving task synthesis skill `hard-multi-interface-recipe`, listed in order with the gate outcome that triggered each revision. Some intermediate revisions are omitted for brevity. The skill text is paraphrased for human readability.
Table 20 presents a six‑step excerpt from a 65‑step agent rollout on the XAI task. The agent resolves the recipient via a direct‑message service (step 2), extracts order details from a PDF (step 9), uses vision to verify product attributes (step 45), adds the product to the cart (step 59), communicates the selection (step 62), and records it in a shortlist file (step 64). GUI‑dependent steps (45, 59) occur only after the preceding browser sub‑task.
**Table 20.** Case study of agent trajectory on XAI task. Color marks the part of the request that only a shell, only the browser, or only an MCP app can proceed. Six of the trajectory’s total 65 tool calls are shown with the observation the agent received and the action it took.
The synthesized verifier (Table 21) comprises three scripts that each check a distinct outcome. Verification succeeds only if all scripts pass; they compare final and initial states using primitives like “web new rows”. A state already satisfying the request fails the initial unsatisfaction gate, ensuring the rollout must effect a change.
**Table 21.**
Implementation and Benchmarks
Implementation specifics for benchmarks, evaluation harness, and synthesis environment.
We evaluate on eight out‑of‑distribution benchmarks spanning web, CLIP‑style, and desktop agents, a scope far larger than the typical 2–4 benchmarks used in prior work.
**Table 9.** Evaluation benchmark details. For binary benchmarks, mean score equals pass rate (pass@1).
All evaluations run through the OpenCode CLI harness (v1.17.7) with NVFP4 quantization to reduce compute, and we employ GPT‑5.5 as the LLM judge where required.
Agents interact with web and desktop environments via Playwright, the browser‑use CLI, and a vision tool that converts screenshots to textual descriptions; tool availability is tuned per benchmark.
We cap agent turns at 256 (512 for OS‑2 and ALE), use a 100 K token context window, and set temperature = 1.0, top‑p = 0.95, top‑k = 20 with high reasoning effort.
A.3 World synthesis details are described in §1; the implementation follows the same modular pipeline used for all benchmarks.
Synthesis Pipeline Details
Details of how persona‑driven worlds and tasks are automatically built and verified.
The persona creator receives a constitution that forces it to build a “persona bible” anchored in the 15 WebHarbor seed databases and the shared MCP index, then publishes any new services for reuse.
To ensure variety, an LLM diversity judge rejects any candidate that repeats an occupation, core tool, or narrative arc already seen, providing diagnostic feedback for up to two revision attempts.
The day planner consumes the persona bible, prior day plans, and the cumulative world state (day N‑1) to emit a markdown plan that maps each activity to a skill and balances per‑app usage via a histogram.
The day implementer, a “god‑mode” coding agent, turns the plan into a deterministic delta.sh script; timestamps are frozen, IDs are derived as MAX(id)+1, and passwords use fixed‑salt hashes from accounts.json.
World verification runs five gated checks: static lint, replay determinism, declaration verification, live health, and an independent reviewer inspection, rejecting any world that fails any step.