FaraGen1.5: Scalable Data Pipeline for CUAs

• FaraGen1.5 is a scalable, verifier-driven data pipeline that generates high-quality trajectories for training native computer use agents.
• It integrates live web tasks and synthetic environments through a modular design featuring environments, solvers, and verifiers.
• Empirical results demonstrate improved CUA performance and robust verification across benchmarks, ensuring reliable low-level action data.

FaraGen1.5 is a scalable, verifier-driven data pipeline for computer use agents, introduced in the "Fara-1.5: Scalable Learning Environments for Computer Use Agents" paper as the data engine underlying the Fara1.5 model family (Awadallah et al., 18 Jun 2026). It is designed to generate large-scale, high-quality, verified trajectories of web and computer use, including both open-web tasks and tasks that require authentication, persistent state, or irreversible actions. Its pipeline is organized around three modular components—environments, solvers, and verifiers—and its outputs are used to train "native" computer use agents (CUAs) that take pixels as input and emit low-level actions.

1. Definition, role, and scope

FaraGen1.5 is the second-generation synthetic data pipeline in the Fara line. Its explicit purpose is to generate training trajectories for Fara1.5, a family of Qwen3.5-based CUAs at 4B, 9B, and 27B scales. These student models are trained almost entirely on FaraGen1.5-generated trajectories, supplemented by a small number of auxiliary datasets for grounding, VQA, and safety. The system is tuned and evaluated against browser and computer-use benchmarks including Online-Mind2Web, WebVoyager, and WebTailBench v1.5 (Awadallah et al., 18 Jun 2026).

The central design problem addressed by FaraGen1.5 is that human computer-use demonstrations are expensive, slow, and difficult to scale, particularly for tasks involving credentialed applications, persistent state, or irreversible side effects such as purchases, bookings, or sending messages. FaraGen1.5 addresses this by combining live websites with synthetic environments, using powerful teacher agents to generate trajectories and multiple verifiers to filter them before they are added to the training corpus.

The pipeline is explicitly aligned with the deployment setting of the downstream student agents. The generated demonstrations use the same low-level action interface that the native CUA later executes, so the data generation regime is not merely producing task solutions in the abstract; it is producing behavior directly learnable by a pixel-in, action-out policy. This suggests that FaraGen1.5 is structured not only as a synthetic data generator but also as a distillation mechanism from a stronger teacher agent into smaller native CUAs.

2. Modular architecture

FaraGen1.5 retains the three-stage structure of the original FaraGen pipeline but re-engineers each stage into a more tightly coupled teacher-data-verification stack (Awadallah et al., 18 Jun 2026). The three components are environments, a solver, and verifiers.

The environment layer is where tasks are instantiated and trajectories are executed. FaraGen1.5 supports two environment classes: live web environments on open internet sites, and synthetic FaraEnvs, which are sandboxed replicas of credentialed or high-stakes applications. Both expose the same action interface that the student model later uses, including actions such as left_click(x,y), type(text), scroll(delta), visit_url(url), and history_back.

The solver is a single-agent harness built around GPT-5.4, though the paper notes that the harness can be powered by multiple models, including strong frontier models such as GPT-5.4. The solver observes browser state through screenshots and limited metadata, iteratively invokes low-level action tools, and generates full trajectories consisting of observations, thoughts, and actions. A user simulator is integrated into the solver loop to support multi-turn interaction.

The verifier layer consists of three independent verifiers covering task correctness, efficiency, and critical-point adherence. A trajectory is accepted only if it satisfies all three criteria. In the paper’s three-phase summary, Phase 1 instantiates tasks in online environments and synthetic FaraEnvs, Phase 2 uses the GPT-5.4 solver and user simulator to execute tasks, and Phase 3 filters the resulting trajectories with the verifier suite.

Conceptually, the environment and trajectory abstractions are given as

$s_t = (x_t, u_t),$

where $x_t$ denotes screenshot(s) or DOM-rendered pixels and $u_t$ denotes the current URL, and

$$\tau = \big((o_1,h_1,a_1), (o_2,h_2,a_2), \ldots, (o_T,h_T,a_T)\big),$$

where each step contains an observation, an internal thought, and an action.

3. Environment layer

The live web component is restricted to tasks that can be completed safely without authentication or irreversible side effects. Websites are sampled from a large URL index, ClueWeb22. For each site, the pipeline conducts initial exploratory browsing to build a cached summary of content, structure, and features, and then uses that summary to generate tasks through a task-proposal LLM (Awadallah et al., 18 Jun 2026).

Task generation on the live web is controlled along structured dimensions: site category, complexity from L1 (1–5 steps) up to L6 (50–100+ steps), phrasing style, interaction type, and solvability. The generator also selects one of 15 pre-defined intent types, such as information-extraction, form-completion, shopping, booking, and compositional planning, as well as one of 8 personas, such as student, busy professional, or tourist. A coverage tracker monitors the empirical distribution across these dimensions. Tasks then pass through a deterministic filter that removes trivial or malformed instructions, followed by an LLM judge that retains plausible, goal-directed requests; ambiguous but realistic tasks are allowed.

FaraGen1.5’s key novelty is its set of six realistic synthetic environments, called FaraEnvs: Email (Mail), Calendar, Media streaming (Stream), ML experiment management (ML), Marketplaces (Stay), and Scheduling. These are intended to simulate domains that live-web generation cannot safely cover, particularly authenticated flows and tasks whose successful completion depends on an irreversible state mutation. Because the full frontend, backend, database, and seed data are controlled, these environments can be reset between episodes and instrumented at the database level.

The construction pipeline for FaraEnvs begins by recording human interaction trajectories on a real target domain. These are then provided to a coding agent, GitHub Copilot, which is instructed to build a replica with a React frontend, a FastAPI backend, a SQLite schema, and seed-data scripts derived from persona narratives. Human review identifies missing behaviors or bugs, and the coding agent refines the implementation. After approximately 3–5 iterations, the replica is described as closely matching observed human workflows.

Task generation in FaraEnvs uses an LLM that interacts with the hosted synthetic environment through MCP tool servers: a SQLite MCP server for schema inspection and entity queries, and a Playwright MCP server for browsing the UI. Training and held-out test tasks are generated separately and deduplicated so that specific intents do not leak across the split.

4. Solver, user simulation, and safety controls

A major architectural change in FaraGen1.5 is the move from the original multi-agent orchestrator, Magentic-One / Magentic-UI, to a single-agent solver built on GPT-5.4 (Awadallah et al., 18 Jun 2026). The motivation stated in the paper is twofold: the single-agent policy better matches the deployment setting of Fara1.5, reducing teacher–student distribution shift, and it is easier to upgrade to newer frontier models without re-engineering a multi-agent scaffold.

At each time step, the solver policy is described as approximating

$$\pi_\theta(a_t, h_t \mid u, \{o_{\le t}, h_{<t}, a_{<t}\}),$$

where the input includes the user task, a history of screenshots and URLs, previous thoughts, and previous actions, and the output is a natural-language thought together with a structured tool invocation. The solver is constrained to use only tools that Fara1.5 can later reproduce. It is explicitly forbidden from using high-level HTTP or URL manipulations that bypass GUI interaction, as well as from taking dangerous actions such as creating accounts, real posting, or irreversible real purchases.

The user simulator is an LLM-based component used at two points. First, when the solver reaches a critical point or needs missing user information, it can issue an ask_user_question call. The simulator then responds with realistic but fake and coherent information, approves or denies irreversible actions based on task context, and is instructed to make assumptions that unblock progress while avoiding real-world risk. Second, when a task appears complete, the simulator may either acknowledge completion or generate a natural, contextually grounded follow-up request that requires further actions. This mechanism is the primary source of multi-turn training data.

Because online tasks run on real websites, FaraGen1.5 inserts an LLM-based safety gate around ask_user_question. If the question would elicit information that could cause harmful real-world side effects, the trajectory is stopped. Forbidden categories include account registration, real login, real checkout, real messaging, public posting, subscription changes, real data mutation, identity-tier PII, and final booking steps. Harmless queries, such as those about preferences or sorting criteria, may be forwarded to the simulator, and gate decisions and reasoning are logged.

5. Verification, scoring, and acceptance criteria

FaraGen1.5 accepts a trajectory only if it passes three independent verifiers: task correctness, efficiency, and critical-point adherence (Awadallah et al., 18 Jun 2026). Formally,

$$\tau \text{ accepted} \iff \begin{cases} \text{CorrectnessVerifier}(\tau)=\text{pass} \ \text{EfficiencyVerifier}(\tau)=\text{pass} \ \text{CriticalPointVerifier}(\tau)=\text{pass}. \end{cases}$$

For online web environments, correctness is assessed using the Universal Verifier’s process reward. A task-specific rubric is first generated, including subgoals, critical steps, and success conditions, and then the trajectory is scored step-by-step to produce a process score $s_\text{process}(\tau) \in [0,1]$. FaraGen1.5 retains only trajectories satisfying

$s_\text{process}(\tau) \ge 0.8.$

For synthetic environments, correctness is more execution-based. For state-mutating tasks, the system records pre-task and post-task database snapshots, computes a row-level diff via sqldiff(D_pre, D_post), and asks an LLM judge whether the diff matches the intended mutation and nothing else. For read-only tasks, a reference answer or SQL query is precomputed during task creation and compared against the trajectory’s final answer.

The efficiency verifier is also LLM-based. It inspects trajectories for loops, repeated action patterns, and clearly unnecessary actions, and assigns an integer score

$e(\tau) \in \{1,2,3,4,5\}.$

Only trajectories with

$e(\tau) \ge 4$

are retained. The paper reports that successful trajectories are shorter than failed ones and that success rate decreases as trajectory length increases, regardless of model.

The critical-point adherence verifier formalizes when the agent must defer to the user. It classifies each task along three binary dimensions: whether permission has been granted, whether the task is fully specified, and whether required PII has been provided. These three bits define eight canonical critical-point types. During verification, red conditions require the agent to pause, ask the user, and receive an explicit reply before proceeding to submission or another irreversible action; green conditions require the agent to proceed without redundant permission checks. Any trajectory that crosses a critical point without required approval is rejected regardless of correctness or efficiency.

6. Data generation workflow and training interface

The end-to-end workflow begins with task selection. On the live web, the system samples a site and task dimensions, generates an instruction conditioned on site summary, persona, and intent, and filters the result for realism and plausibility. In synthetic environments, the task-proposal LLM queries the database and UI through MCP servers and generates tasks coherent with the environment’s schema and frontend (Awadallah et al., 18 Jun 2026).

The selected task is then instantiated in a sandboxed browser session. The solver executes a multi-turn loop in which it observes the current screen and URL, emits a thought and action, consults the user simulator if needed, and continues until it issues terminate or reaches a step cap. The resulting trajectory is then passed through the correctness, efficiency, and critical-point verifiers. Accepted trajectories are stored together with metadata such as site, complexity, intent, persona, environment type, verifier scores, and critical-point classification.

By May 2026, FaraGen1.5 and its predecessor had produced approximately 1.57M trajectory steps. The final Fara1.5 training mix is reported as 60.0% web trajectories from FaraGen1.5, 12.8% synthetic-environment trajectories, 12.5% form-filling and user-interaction trajectories, 8.8% grounding, 4.9% visual QA, 0.8% GUI drag, and 0.1% instruction-following plus safety refusal.

Fara1.5 is trained by supervised fine-tuning from Qwen3.5 backbones. The training input is a truncated trajectory prefix containing the user task, recent observations, and prior thoughts and actions; the targets are the next thought and next action tokens. Coordinates are represented as discrete tokens in Qwen3.5’s vocabulary. The loss is standard cross-entropy, masked to apply only on the last few turns for which the corresponding images are present:

$x_t$0

The paper characterizes the overall SFT recipe as a careful balancing of broad coverage, specific high-value tasks, and iterative targeting of model deficiencies.

7. Empirical impact, limitations, and comparative position

The empirical role of FaraGen1.5 is visible in both teacher performance and student performance. The GPT-5.4-based FaraGen1.5 solver scores 83.4% on Online-Mind2Web and 93.4% on WebVoyager, which the paper treats as an approximate upper bound for SFT distillation. The Fara1.5 models trained from this data then establish new state of the art for their size class (Awadallah et al., 18 Jun 2026).

Model	Online-Mind2Web	WebVoyager
Fara1.5-4B	57.3%	80.8%
Fara1.5-9B	63.4%	86.6%
Fara1.5-27B	72.3%	89.3%

The paper also reports WebTailBench v1.5 outcome success of 24.1% for Fara-7B, 32.3% for Fara1.5-9B, and 40.2% for Fara1.5-27B, with corresponding process success of 48.8%, 64.5%, and 72.9%. On the six-environment FaraEnvs test set, Fara-7B achieves 18.8%, Fara1.5-9B reaches 71.8%, and the GPT-5.4-based FaraGen1.5 solver reaches 79.4%. For four WebVoyager domains—Allrecipes, Apple, HuggingFace, and GitHub—a Qwen3.5-9B model fine-tuned on generic FaraGen1.5 data reaches 73.4% combined, the same base model plus synthetic-replica trajectories reaches 83.4%, and Fara1.5-9B with the full training mix reaches 89.8%. This suggests that the synthetic replicas are realistic enough to support synthetic-to-real transfer.

In comparative terms, the paper positions FaraGen1.5 against manually collected data such as Mind2Web, structured environments such as WebArena and VisualWebArena, and trajectory-generation frameworks such as CUA-Gym and Gym-Anything. Its distinctive properties are end-to-end alignment with a native pixel-in, low-level-action CUA architecture, the use of deep synthetic environments for credential-gated or irreversible domains, and multi-criterion verification with explicit critical-point modeling.

The paper also identifies limitations. Synthetic environments may not fully capture the diversity of real-world UIs, including ads, latency, and layout drift. LLM judges can mislabel trajectories, the $x_t$1 process-score threshold is heuristic, and critical-point classification can miss required fields or misjudge PII. Reported failure modes include selection errors, hallucination, incomplete task execution, incomplete delivery, environment failures such as captchas or login walls, fine-grained grounding errors, and intent-action mismatches. Future directions named in the discussion include expanding beyond the browser to desktop applications, enterprise software, and terminals; adding actions such as running scripts and long-running monitoring; and strengthening refusal behavior, prompt-injection robustness, and unintended-side-effect detection.