1 Introduction↩︎

Scaling high-quality training data is a central challenge in building capable LLM agents. Post-training agents for real-world tasks require not only task instruction, but also grounded materials, executable environments, and long-horizon interaction trajectories. Producing such data at scale remains labor-intensive: practitioners must determine what the agent should practice, design representative tasks, collect appropriate materials, and package them into runnable workspaces. This process is expensive, domain-specific, and difficult to scale.

Recent task-synthesis methods have made substantial progress by deriving executable tasks from predefined repositories, tools, skills, or execution traces [1]–[8]. However, these substrate-first approaches face three fundamental scaling limitations. First, scaling is bounded by the input substrate: the volume and diversity of generated tasks are constrained by the number of available repositories, tools, or skill specifications, and expanding coverage requires costly manual curation. Second, each domain typically demands a bespoke pipeline with domain-specific infrastructure – skill libraries for terminal tasks [5], [6], repository harnesses for software engineering [7], [8], or simulated tool ecosystems [1] – making the methods expensive to transfer to new capability targets. Third, the available substrate implicitly determines the task distribution: repository-based pipelines naturally favor implementation and debugging tasks even when real-world users also require configuration analysis, data processing, or system operation, producing distributions that reflect substrate convenience rather than actual demand.

We argue that scaling agent training data require decoupling task generation from predefined substrates. Environment synthesis should instead begin with the user’s capability requirement: before any workspace is built, the system must determine both which tasks are representative of the desired capability and what diverse real-world contexts they arise in. Only then should the materials and runtime environments be constructed to match. This requirement-first formulation separates what an agent should practice from how that practice is made executable, enabling the same pipeline to scale across domains without building a new domain-specific infrastructure for each target.

To this end, we introduce NexForge, a requirement-first framework that compiles free-form capability requirements into executable agent training data. NexForge first performs research-based demand discovery to identify representative task forms and diverse real-world scenarios associated with the target capability. Then it applies distribution-aware task compilation, combining the induced task profile with concrete scenarios to determine the task directive. Finally, NexForge retrieves or constructs the required repositories, documents, datasets, files, dependencies, etc., packages them into validated executable workspaces, and collects teacher interactions as training trajectories. By doing so, NexForge controls corpus composition independently of predefined tools or repositories and applies the same synthesis pipeline across substantially different capability domains. We evaluate NexForge on two substantially different capabilities: terminal operation yields 3,600 tasks improving Qwen3.5-35B-A3B from 22.5% to 52.0% on Terminal-Bench 2.0; office work yields 2,000 tasks improving the same model from 813 to 1338 Elo on GDPval – both from the same pipeline without domain-specific engineering. Moreover, scaling for more data makes Nex-N2 models reach state-of-the-art open-source performance on both capabilities, as shown in Figure 1.

Our contributions are threefold:

• We formulate agent environment construction as a requirement-first scaling problem, identifying three bottlenecks of substrate-first synthesis: input-bounded scale, high transfer cost, and substrate-determined distributions.

• We propose NexForge, an end-to-end framework that discovers task demands via multi-source research and materializes them into executable training environments with teacher trajectories, without domain-specific infrastructure.

• We demonstrate that the same framework generates effective training data for both terminal and the office capabilities, substantially improving the performance of the downstream agent in distinct domains.

2 Related Work↩︎

2.0.0.1 Instruction and task-distribution synthesis.

Scalable data synthesis often decomposes a broad capability space before generating individual examples. Self-Instruct [9] bootstraps instruction-following data from a small seed set, while GLAN [10] organizes generation through a hierarchical taxonomy of disciplines and tasks. Task-profile-guided routing data [11] controls synthetic examples using explicit task profiles, and Benchmark Agent [12] decomposes evaluation goals into structured benchmark specifications. These studies show that explicit distribution modeling improves coverage over unconstrained generation, but they primarily synthesize text instructions or evaluation instances rather than complete executable environments. Scaling their approach to agent training would additionally require grounding each task with materials, dependencies, and runtimes—a step these methods do not address.

2.0.0.2 Agent task and environment synthesis.

Recent work has explored executable agent-data construction through tool ecosystems, simulated environments, execution traces, subtask composition, repositories, and domain-specific skills. Agent-World [1] and Agent World Model [2] synthesize stateful tool environments, while DIVE [3] derives grounded and verifiable tasks from execution evidence. AgentSynth [4] and TaskCraft [13] construct complex tasks through subtask composition and difficulty control. In software engineering, SWE-smith [7] and R2E-Gym [8] generate executable tasks from repositories, tests, and issue-like workflows. Terminal-oriented methods further specialize this paradigm: SkillSynth [5] generates tasks from structured skill specifications, Terminal-World [6] builds environments around reusable agent skills, CLI-Universe [14] constructs terminal tasks from a predefined capability taxonomy, and TerminalTraj [15], Nemotron-Terminal [16], LiteCoder-Terminal [17], and OpenThoughts-Agent [18] provide terminal interaction trajectories or training corpora.

These methods establish the importance of executable grounding but share three scaling limitations. (1) Input-bounded scale: the volume and diversity of generated tasks are capped by the predefined substrate—repositories, skills, tools, or traces—and expanding coverage requires manual substrate curation. (2) High transfer cost: each method builds domain-specific infrastructure (skill graphs for terminal tasks, repository harnesses for software engineering, simulated tool ecosystems for general agents) that cannot be directly reused for a different capability target. (3) Substrate-determined distributions: because tasks are derived from what the substrate supports, the resulting corpus tends to overrepresent convenient task types (e.g., implementation and debugging) at the expense of less substrate-friendly but equally important work (e.g., configuration, data processing, system operation). NexForge addresses all three by starting from free-form requirements rather than predefined substrates: the same pipeline scales across terminal and office domains without new domain-specific infrastructure. Terminal-Bench 2.0 [19] and GDPval [20] are used solely as external evaluation suites.

3 Method↩︎

NexForge scales a free-form user requirement into executable environments and interaction trajectories for agent post-training. As illustrated in Figure 2, the framework contains three main stages. First, it conducts multi-source research to discover representative task demands and working scenarios associated with the requested capability. Second, it composes the discovered demands into concrete task directives under an explicit task distribution. Finally, it retrieves or constructs the required materials, packages each directive into an executable workspace, and collects teacher trajectories for training. This requirement-first pipeline determines what the agent should practice before constructing the materials and runtime environments that make the practice executable, enabling the same architecture to scale across capability domains.

3.1 Problem Formulation↩︎

NexForge takes as input a free-form capability requirement \(I\), a requested task count \(N\), and optional batch-level constraints \(B\) that let the user override the naturally discovered distribution along specific dimensions such as language or difficulty. It outputs a collection \[\mathcal{T}={\tau_1,\ldots,\tau_N},\] where each \(\tau_i\) is an executable task package contains task instruction, grounded materials, workspace files, software dependencies, and a runtime configuration, designed for trajectory collection and agent training.

We represent each task using a task form \(f_i\) and a scenario \(s_i\): \[\tau_i \leftarrow (f_i,s_i).\]

The task form \(f_i=(t_i,d_i,\sigma_i,e_i,\ell_i,h_i)\) specifies the primary task type \(t_i\), expected deliverable \(d_i\), source strategy \(\sigma_i\), runtime environment \(e_i\), language \(\ell_i\), and difficulty \(h_i\). The scenario describes the concrete context in which the task occurs, such as an organization, professional role, workflow, software system, or operational event. This decomposition enables explicit control over the corpus-level task distribution while grounding each task in a realistic context.

3.2 Research-Based Demand Discovery↩︎

Given the requirement \(I\), NexForge first investigates what the requested capability entails in practice. A web-enabled research agent collects evidence from professional workflows, technical documentation, role descriptions, public examples, and other sources relevant to the domain. The collected evidence, together with the knowledge of the model, is organized into a weighted task demand profile and a diverse scenario reservoir.

3.2.0.1 Task demand profile.

The task demand profile \(\Phi(I)\) defines the intended distribution over the dimensions of the task-form: \[\Phi(I)= \{\Phi_t,\Phi_d,\Phi_\sigma,\Phi_e,\Phi_\ell,\Phi_h\},\] where each \(\Phi_k\) is a weighted categorical distribution. Candidate options are induced from research evidence and model knowledge, and are subsequently reviewed by an LLM to merge near-duplicates, remove ambiguous categories, and improve mutual exclusivity. Evidence-informed weights indicate the relative prevalence or importance of each option under the requested capability.

The profile specifies the overall composition of the generated corpus without committing to particular repositories, documents, or source files. It therefore separates the intended work distribution from the materials later used to instantiate individual tasks.

3.2.0.2 Scenario reservoir.

The scenario reservoir \(\mathcal{G}(I)\) contains concrete scenario guides (scenarios for short) that describe working contexts in which task forms can be instantiated. NexForge populates it through four branches: (1) keyword-conditioned self-instruct, which samples keywords from a domain keyword pool and prompts the model to generate scenarios; (2) keyword-conditioned research, which uses sampled keywords as web-search queries to discover real-world scenarios; (3) self-instruct, which directly prompts the model to generate scenarios, sampling from already accepted scenarios as few-shot examples to encourage novelty; and (4) knowledge-graph expansion, which iteratively expands sub-scenarios from the input requirement. The domain keyword pool is generated via web research or model knowledge. The relative contribution of each branch can be configured through the synthesis specification. All candidate scenarios undergo embedding-based semantic deduplication to ensure diversity across the reservoir.

Scenarios intentionally describe only the working context and omit task type, deliverable, source strategy, and runtime. This prevents scenarios from independently determining the task distribution.

3.3 Distribution-Aware Task Compilation↩︎

NexForge composes the task-form profile and scenario reservoir into directives. For each scenario \(g_j\in\mathcal{G}(I)\), the composer expands it into a concrete scenario, then sequentially filters profile options by compatibility with the scenario and previously selected fields.

Let \(K={t,d,\sigma,e}\) denote the ordered task-form dimensions that require compatibility decisions. For each dimension \(k\in K\), the composer obtains a compatible candidate set \[C_{j,k}=F_\theta(I,g_j,k,\Phi_k,S_{j,<k}),\] where \(S_{j,<k}\) contains fields selected in earlier steps. A field is then sampled according to the profile weights restricted to the compatible set: \[f_{j,k} \sim \operatorname{Normalize} \left( \Phi_k\vert_{C_{j,k}} \right).\] Language and difficulty are sampled according to the corresponding profile distributions and batch constraints \(B\).

The resulting directive is \[\delta_j= \langle g_j,f_j,A_j,\ell_j,h_j,R_j \rangle,\] where \(A_j\) records the retained candidate sets and \(R_j\) stores the composition rationale. The directive fixes the intended work before any repository or document is selected, constraining downstream stages to find or construct materials that realize the sampled task. The compatibility filter ensures that the resulting directive is internally consistent; its effect on directive quality is evaluated in Section 5.4.

3.4 From Task Directives to Training Trajectories↩︎

A task directive specifies the intended work but is not yet executable. NexForge converts each directive into an executable workspace and subsequently collects and distills teacher interactions into training trajectories.

3.4.0.1 Environment materialization.

Given a task directive \(\delta_j\), NexForge materializes the intended task through three successive steps: material mining, blueprint planning, and workspace generation and validation. A research agent first identifies realistic workflows and collects the resources required by the directive, including public repositories, technical documents, datasets, spreadsheets, configuration files, and other domain-relevant artifacts. When suitable external resources are unavailable, it specifies the local materials that should be generated. A planning agent then inspects the collected resources and produces a structured blueprint defining the task objective, input materials, expected deliverable, workspace organization, required transformations, software dependencies, and runtime constraints. Based on this blueprint, a coding agent constructs the executable workspace by adapting repositories, retrieving public files, generating local artifacts, installing dependencies, and configuring an unprivileged CPU-only Docker environment. Automated checks verify material completeness, source-strategy consistency, dependency availability, runtime restrictions, and the absence of leaked solutions or target artifacts. Separating research, planning, and implementation into distinct stages isolates noise introduced during resource discovery and data preparation, preventing it from propagating into downstream workspace construction.

3.4.0.2 Trajectory collection and distillation.

Each validated workspace is assigned to a teacher model under a fixed interaction budget. The teacher interacts with the executable environment using the available tools, producing a trajectory that records model responses, tool calls, environment observations, intermediate failures, and recovery behaviors. NexForge then converts the collected interactions into a standardized training format through task-independent trace cleaning, removing malformed conversations, invalid message structures, duplicate-role messages, error-only outputs, and trivially short interactions. The framework does not require manually authored reference answers or task-specific success verifiers; therefore, incomplete but meaningful attempts are retained when they contain useful long-horizon reasoning, tool-use patterns, or error-recovery signals. This process produces both controllable executable task packages and requirement-aligned training trajectories that can be directly used for agent post-training.

4 Datasets↩︎

We instantiate NexForge from two independently written capability requirements, producing Terminal-3.6K for terminal agent evaluation and Office-2K for cross-domain validation on GDPval. The two corpora differ substantially in their task forms, grounding materials, and runtime requirements, demonstrating that the same synthesis pipeline can scale to distinct user-defined capabilities without domain-specific engineering. To study data scaling, we additionally produce Terminal-2K, Terminal-43.2K, and Office-22K under the same pipeline.

4.1 Task-Set Specifications↩︎

The terminal specification covers command-line workflows such as repository inspection, software construction, configuration editing, data processing, system operation, and local validation, while the office specification includes spreadsheet analysis, document review, information aggregation, summarization, drafting, planning, and evidence-based recommendations. Both use a 50/50 Chinese–English split and balanced difficulty budgets. Terminal-3.6K contains 3,600 tasks, matching SkillSynth in task count and requested rollout budget, whereas Office-2K contains 2,000 independently synthesized office tasks. All synthesis stages use GPT-5.5.

4.2 Corpus Statistics and Rollouts↩︎

We request up to three DeepSeek V4 Pro attempts for each task. After trajectory conversion and generic trace cleaning, this process yields 8,521 trajectories for Terminal-3.6K and 5,940 trajectories for Office-2K, corresponding to 2.37 and 2.97 trajectories per task, respectively. Table 1 summarizes corpus scale, trajectory complexity, task diversity, and grounding characteristics. The two specifications induce clearly different data distributions. Terminal-3.6K realizes 24 task types and is primarily grounded through public repository adaptation, whereas Office-2K realizes 15 task types and more frequently relies on public documents, spreadsheets, and reports. The ten most frequent task signatures account for only 20.6% and 15.1% of the two corpora, respectively, indicating that scale is not obtained by repeatedly instantiating a small number of templates. Unless otherwise specified, supervised fine-tuning uses Qwen3.5-35B-A3B Base for five epochs with a maximum context length of 262K, packed bfloat16 sequences, a global batch size of 64, and a learning rate of \(10^{-5}\) with cosine decay and 5% warmup. The Qwen3-32B comparison uses Terminal-3.6K with the same recipe adapted to the dense base model.

5pt

4.3 Comparison with Existing Agent Datasets↩︎

Table 2 compares NexForge with representative agent-task synthesis pipelines. Existing methods typically start from predefined tools, repositories, traces, atomic tasks, or manually designed skill structures, each requiring domain-specific infrastructure that limits scalability and transferability. NexForge instead takes a free-form user requirement as input, uses multi-source research to identify representative task demands and their relative prevalence, and then constructs the materials and executable environments needed to realize them. This requirement-first design separates corpus-level task distribution from grounding resources and supports both terminal and office capabilities through the same synthesis pipeline.

3pt

5 Experiments↩︎

5.1 Experimental Setup↩︎

We perform full-parameter SFT on Qwen3-32B and Qwen3.5-35B-A3B Base with learning rate \(10^{-5}\), batch size 64, and 5 epochs on 128 H100 GPUs. And models are evaluated on Terminal-Bench 2.0 [21] and GDPval [20] to evaluate the ability of models on terminal and office tasks. We compare our models with frontier proprietary models and terminal-specialized 32B baselines [5], [6], [14]–[18]. The results are from published papers or public leaderboards.

\begin{table}[!t]

\end{minipage} \ \end{tabular*} \end{table}

5.2 Main Results↩︎

Table ¿tbl:tab:tb-results? presents the results on Terminal-Bench 2.0. Three observations stand out. First, Terminal-3.6K consistently improves models with substantially different initial capabilities: Qwen3-32B increases from \(5.6\%\pm0.9\) to \(32.3\%\pm2.4\), while Qwen3.5-35B-A3B increases from \(22.5\%\pm0.9\) to \(52.0\%\pm3.6\), corresponding to absolute gains of 26.7 and 29.5 points, respectively. This suggests that the synthesized data provides useful terminal interaction experience rather than merely compensating for weaknesses of a particular base model. Second, NexForge-trained Qwen3-32B achieves the highest mean accuracy among the compared terminal-specialized 32B models, despite NexForge being a general requirement-driven framework rather than a pipeline tailored specifically to terminal tasks. Third, combining Terminal-3.6K with the stronger Qwen3.5 base moves the resulting model into the performance range of several frontier proprietary systems, substantially narrowing the gap without changing the model architecture. Overall, the results show that research-grounded environment synthesis can produce high-quality training data that remains effective across model scales and competitive with domain-specific data construction pipelines.

5.3 Scaling Analysis↩︎

Beyond the primary Terminal-3.6K run, NexForge scales along two independent axes, both requiring only configuration changes rather than manual curation or domain-specific engineering.

5.3.0.1 Domain transfer.

Because NexForge is requirement-first, transferring to a new domain requires only a new capability specification—no domain-specific task generator, tool collection, or pipeline redesign. To demonstrate this, we replace the terminal requirement with an office-work specification while keeping the pipeline unchanged. NexForge constructs 2,000 tasks covering document processing, spreadsheet analysis, planning, communication, and multimodal artifact creation. As shown in Table 3, Office-2K improves Qwen3.5-35B-A3B Base from 813 to 1338 GDPval Elo, surpassing several frontier reference models. Scaling to 22K office tasks yields 1384 Elo, further closing the gap to GLM-5 (1408) to 24 Elo. The same pipeline that produces terminal data thus transfers to an entirely different capability with only a specification change.

5.3.0.2 Data volume scaling.

Within any target domain, NexForge’s data production is not bottlenecked by manually curated materials or substrate availability—scaling requires only increasing the task budget in the configuration. On Terminal-Bench 2.0, scaling from Terminal-2K (43.8%) to Terminal-3.6K (52.0%) to Terminal-43.2K (58.4%) yields continuous improvement, as shown in Table ¿tbl:tab:tb-results? and Figure 3: Terminal-2K matches Kimi K2.5, Terminal-3.6K matches Claude Opus 4.5, and Terminal-43.2K surpasses Claude Opus 4.6, confirming that NexForge-generated data remains effective at scale. The same pattern holds on GDPval: Office-2K (1338) to Office-22K (1384) shows monotonic gains. Since GDPval Elo depends on the comparison pool, comparisons with public models are treated as contextual references; the controlled base-versus-scaled comparison provides the primary evidence.

8pt

5.4 Ablation Studies↩︎

We examine whether task-form control and scenario grounding provide complementary signals during task compilation. Under the same 2,000-task budget, teacher rollout setting, and SFT recipe, we construct three variants on Qwen3.5-35B-A3B Base. Terminal-2K w/o profile retains the scenarios but removes the sampled task-form directive, allowing downstream agents to infer tasks directly from each scenario. Terminal-2K w/o scenario retains the task-form profile but replaces concrete scenarios with neutral scenario seeds. Terminal-2K corresponds to the complete NexForge pipeline, where task forms are sampled conditioned on concrete scenarios.

5.4.0.1 DATC directive quality.

On the terminal run, the compatibility filter retains on average only \(4.4\) of \(24\) task types, \(5.2\) of \(8\) deliverables, \(2.7\) of \(4\) source strategies, and \(4.5\) of \(20\) runtimes per scenario, so just \(2.0\%\) of the full \(24{\times}8{\times}4{\times}20\) task-form combination space is scenario-compatible. To evaluate whether DATC produces coherent directives under this constraint, we ask an LLM judge (Qwen3.7-Max) to assess whether each item directive’s task form is compatible with its guide scenario, and compare against a uniform-random baseline that ignores both profile weights and compatibility filters (w/o DATC). Over the full 2,000 items of Terminal-2K, DATC directives achieve a match rate of 81.0%, while random directives achieve only 7.0%, as reported in Table 4. The large gap confirms that scenario-conditioned compilation is essential for producing coherent task directives.

12pt

Table 5 shows that the full pipeline achieves the highest mean accuracy. Figure 4 (c,d) reveals the underlying mechanism: w/o profile collapses to a single dominant task type (78.5%, \(\sim\)​3 effective types), while w/o scenario broadens coverage (\(\sim\)​16 effective types) but yields a flat distribution that under-represents frequent workflows. Terminal-2K strikes an intermediate balance (\(\sim\)​6 effective types) with the longest trajectories (114 assistant messages, 149 tool calls). Task-form control preserves coverage; scenario grounding structures the training distribution.

6pt

5.5 Further Analysis↩︎

5.5.0.1 Cross-domain distribution shift.

Figure 4 (a,b) shows NexForge adapts to different requirements. The terminal corpus is dominated by software engineering (54%) but covers 23 additional types; the office corpus is more evenly distributed. Grounding differs accordingly: 45% of terminal tasks use public repositories vs.% of office tasks using web files. These shifts arise from input specifications alone, confirming cross-domain scalability.

5.5.0.2 Controlled diversity.

The scenario reservoir contains 5,600 accepted scenarios with no exact or embedding near-duplicates under a cosine-similarity threshold of 0.85. The generated corpora also avoid repeated task configurations: the ten most frequent task-form signatures account for only 20.6% of terminal tasks and 15.1% of office tasks. Meanwhile, terminal and office tasks can be separated with 0.98 nearest-centroid accuracy, indicating that NexForge preserves within-domain diversity while producing clearly differentiated distributions across capability targets.

5.5.0.3 Environment quality.

We manually inspect stratified task packages on instruction clarity, material completeness, workspace executability, difficulty calibration, and absence of solution leakage. Overall quality is high: the majority of packages score at least 4 on all five dimensions, and none receives a score below 3. Terminal-2K w/o profile and Terminal-2K obtain comparable quality, while Terminal-2K w/o scenario scores lower because its from-scratch tasks contain fewer grounded materials. However, Terminal-2K w/o scenario still outperforms Terminal-2K w/o profile on Terminal-Bench 2.0, suggesting that the ablation gap is not explained solely by package quality. Together with Figure 4 (c,d), these results indicate that task-form control and scenario grounding mainly improve training by shaping a more effective task distribution.

6 Conclusion and Future Work↩︎

We present NexForge, a requirement-first framework that scales executable agent task synthesis from free-form user needs. By decoupling task-form control and scenario grounding from predefined substrates, NexForge enables the same pipeline to produce effective training corpora across distinct capability domains without domain-specific infrastructure. Experiments on terminal and office tasks demonstrate strong cross-domain scalability. NexForge scales synthesis to tens of thousands of tasks to train the publicly released Nex-N2 model family: Nex-N2-Pro reaches 75.3% on Terminal-Bench 2.1 and 1585 Elo on GDPval, competitive with frontier proprietary systems, validating that requirement-first synthesis produces effective training data at production scale. Ablations confirm that jointly modeling task distributions and concrete scenarios is essential for producing coherent directives. Future work will extend NexForge with automatically generated reference answers and machine-checkable verifiers, enabling its use in benchmark construction, reinforcement learning, and other settings that require reliable outcome-based feedback.

Appendix↩︎

This supplementary material documents the implementation details, complete statistics, and additional analyses that support the main paper but do not fit within its page budget. It is organized as follows. We first give the formal scenario-conditioned task-compilation procedure (Algorithm 5) and then walk through a complete end-to-end case study of one synthesized terminal task, from the sampled directive to the runnable package. We next report the synthesis configuration, the two capability requirement specifications that define the pipeline inputs, and corpus-level statistics, audits of scenario-reservoir and task-description diversity, and the full training configuration. We then provide detailed evaluation results and the exact evaluation protocols behind the main-paper scores, including per-task and pass@k analyses and the terminal ablation. Finally, we include faithful English renderings of the four stage prompts and the teacher-rollout runtime prompt that drive the pipeline.

7 Scenario-Conditioned Compilation Procedure↩︎

Algorithm 5 details how NexForge composes a task directive \(\delta_j\) from the task demand profile \(\Phi(I)\) and a single scenario \(g_j\) drawn from the reservoir \(\mathcal{G}(I)\). The composer processes the ordered task-form dimensions \(\{t,d,\sigma,e\}\) (task type, deliverable, source strategy, runtime) one at a time. For each dimension \(k\), a compatibility filter \(F_\theta\) inspects the requirement, the scenario, and the fields already selected, and returns the subset \(C\) of profile options that remain coherent in this context; the realized field \(f_{j,k}\) is then sampled from the profile weights restricted to \(C\). Because earlier decisions constrain later ones, the directive stays internally consistent (for example, a chosen runtime does not admit an incompatible deliverable), while the profile weights still steer the corpus-level distribution. Language \(\ell_j\) and difficulty \(h_j\) are drawn last under the batch-level budget rather than from scenario compatibility, and the retained candidate sets \(A\) together with the per-step rationale \(R\) are recorded so that downstream stages materialize the sampled work rather than re-inferring it from whatever materials happen to be available.

8 End-to-End Case Study↩︎

To make the pipeline concrete, we trace a single terminal task from the sampled directive to the runnable package (Figure 6). The example illustrates the central claim of the paper: the work contract is fixed by the compiled directive before any material is gathered, so the substrate is selected to serve the intended task rather than the task being inferred from whatever substrate is convenient.

8.0.0.1 Scenario and directive.

The scenario describes a systems-programming context around pMARS, the portable Memory Array Redcode Simulator used to run Core War tournaments. Following Algorithm 5, the composer conditions the profile on this scenario and sequentially selects compatible task-form fields: a build, packaging, and toolchain integration task type, a command-line executable plus reproducible build script deliverable, a GitHub repository adaptation source strategy, and a shell/CLI runtime. Crucially, the same scenario could have supported a build repair, a benchmarking harness, a data-extraction task, or a cross-compilation deliverable; the sampled directive commits to one primary goal—producing an offline, statically linked cross-compilation of pMARS—so later stages do not silently drift toward the most convenient interpretation of the repository.

8.0.0.2 Material mining.

Conditioned on the directive, the mining stage performs targeted web research to recover the real workflow and candidate materials: the upstream pMARS source tree, a set of opponent Redcode warriors, and a league runner that scores warriors head-to-head. Mining records each asset with a concrete source, format, and intended role, and distinguishes solver-facing inputs from materials reserved for the runtime environment, so that the downstream package contains genuine artifacts rather than synthetic stand-ins.

8.0.0.3 Blueprint ideation.

The ideation stage consolidates the mined evidence into a single-schema blueprint. It fixes the objective (reconstruct a musl-based static pMARS binary offline and validate it by running a warrior through the league), the input materials, the expected deliverables and their success boundary, the workspace layout, and the software dependencies. Because the solver environment is a CPU-only unprivileged container, ideation resolves any environment-sensitive choices at design time—selecting an offline source archive, pinning the toolchain, and avoiding privileged or GPU-dependent steps—so the resulting task is guaranteed to be executable under the standard runtime.

8.0.0.4 Workspace generation.

The generation stage instantiates the blueprint into a solver-facing package: it lands the prepared pMARS sources and opponent programs, adds the league runner and any generated fixtures, writes a concise instruction that states the goal, starting materials, and delivery contract without leaking internal checks, and emits a CPU-only, unprivileged Dockerfile that installs the declared dependencies. Automated checks then verify material completeness, source-strategy consistency, runtime restrictions, and the absence of leaked solutions before the package is admitted for teacher rollouts.

8.0.0.5 Why the directive matters.

This example shows the difference between requirement-first and substrate-first synthesis in miniature. A substrate-first pipeline that began from the pMARS repository would most naturally emit an implementation or test-repair task, because that is what the repository most directly supports. By fixing a cross-compilation build contract before mining, NexForge instead produces a long-horizon toolchain task whose difficulty and structure are determined by the intended work, and the resulting trajectory is correspondingly deep (many build, inspection, and validation steps rather than a single edit-and-test loop).

9 Synthesis Configuration and Corpus Statistics↩︎

This section documents the configuration that drives synthesis and the corpus-level statistics of the resulting data. We first report the reviewed task-form profile and keyword pools that define the candidate space, then the scale and token/operation composition of the collected trajectories.

9.1 Reviewed Profile and Keyword Pools↩︎

The reviewed task-form profile defines the candidate space that later sampling draws from. For the first terminal synthesis run (Terminal-2K) it contains 24 primary task types, 20 runtime environments, 8 deliverable types, and 4 source strategies, supported by a domain keyword pool of 3,678 candidates; the office run contains 15 task types, 12 runtimes, 23 deliverables, and 4 source strategies with a 773-keyword pool. The terminal profile spans more task types and runtimes, reflecting the broader operational surface of command-line work, whereas the office profile enumerates more deliverable types, matching its emphasis on documents, analyses, and recommendations. All candidate lists are pruned by the LLM review step for mutual exclusivity and bounded semantics before sampling; the realized coverage and concentration of each dimension are reported in Table 16, and the per-item scene-conditioned narrowing of these pools in Table 15.

9.2 Trajectory Scale and Token Mix↩︎

Table 6 separates original teacher attempts from the framework-internal cleaned records for each task group and reports per-attempt token and tool-call averages, while Table 7 shows how tokens and operations distribute across message roles and tool classes. The terminal corpora are markedly more tool- and build-intensive, whereas the office corpus yields shorter, more read- and document-oriented trajectories.

3pt

3pt

9.3 Capability Requirement Specifications↩︎

The two corpora are generated from independently written capability requirements. Each specification is a free-form natural-language description of the target capability that serves as the pipeline input \(I\) (Section 4.1). Below are faithful English renderings of the two specifications.

9.3.0.1 Terminal capability requirement.

9.3.0.2 Office capability requirement.

10 Training Configuration↩︎

This section records the teacher-rollout and supervised fine-tuning configuration behind every trained model, so that each reported run can be reproduced from its logged provenance.

Across the experiments, teacher rollouts use DeepSeek V4 Pro. The records retain all teacher attempts that survive trace cleaning, which drops only malformed and degenerate trajectories. The same inclusion rule is used for the terminal ablation and Qwen3-32B comparison. All SFT runs use 16 nodes with 8 NVIDIA H100 GPUs per node, for 128 H100 GPUs in total.

5pt

All experimental SFT runs use full-parameter SFT for five epochs with maximum sequence length 262,144, packed sequences, bfloat16, global batch size 64, micro batch size 1, learning rate \(10^{-5}\), minimum learning rate \(10^{-7}\), cosine decay, 5% warmup, and the ignore_empty_think loss scale. The Qwen3.5-35B-A3B runs use the qwen3_5 template and MoE expert parallelism; the Qwen3-32B comparison uses the qwen3 template and pipeline parallelism. For the terminal ablations, final training-log summaries give approximately 1.61B packed train tokens for Terminal-2K, 0.97B for Terminal-2K w/o profile, and 1.72B for Terminal-2K w/o scenario. These values are computed from the logged mean packed sequence length multiplied by the logged packed train-set size. They differ slightly from the converted-record tokenizer audit in Table 6, which sums visible content, reasoning content, and serialized tool calls before training-framework packing and without chat-template overhead.

11 Detailed Evaluation Results↩︎

Table 9 reports the controlled Terminal-Bench 2.0 pass@1 statistics behind the scalar values in the main paper. All rows use the same in-house NexAU scaffold, task-suite revision, tools, inference settings, and denominator of 89 tasks per run. Unfinished trials, still-running trials, agent timeouts, verifier timeouts, nonzero exits, and verifier errors are counted as failures.

4pt

Table 10 reports available GDPval Elo confidence intervals behind the scalar values in the main paper. The scoring follows the GDPval-AA v1 methodology of Artificial Analysis: the outputs of GPT-5.1 are fixed as the 1000-point anchor; every pair of models is then compared on all 220 GDPval tasks with an LLM judge that returns a win, loss, or tie for each task; and Elo scores are fit from the full set of pairwise match outcomes. All rows are fit in one in-house NexAU-based joint comparison pool and should not be interpreted as external GDPval leaderboard scores.

4pt

Table 11 records the external Terminal-Bench reference values used for context in the main paper. These reference values come from the public leaderboard and published terminal/agent-data studies [5], [6], [15]–[18], [21].

5pt

11.1 Per-Task Outcomes and Pass@k↩︎

Beyond mean accuracy, we examine how the four independent runs distribute over individual tasks. Table 12 reports, for the base model and the Terminal-3.6K model, how many of the 89 tasks are solved in \(0,1,\ldots,4\) of the four runs. Training does not merely convert a handful of borderline tasks: the number of tasks that never pass drops from 54 to 29, while the number solved in all four runs rises from 7 to 29. Terminal-3.6K therefore adds robustly solvable tasks rather than occasional lucky passes.

4pt

Figure 7 extends this to task-level pass@k, estimating whether at least one of \(k\) sampled attempts solves each task. NexForge improves the entire pass@k curve for both base models: Qwen3.5-35B-A3B rises from 52.0% at pass@1 to approximately 68% at pass@4 and stays roughly 30 points above its base throughout, while Qwen3-32B rises from 32.3% to approximately 55% (its base reaches only about 14% at four attempts). The NexForge-trained Qwen3-32B also stays above the published terminal-specialized models across the evaluated sampling budgets. These trends indicate that Terminal-3.6K expands the set of tasks for which a valid solution can be discovered through repeated sampling, not only single-attempt accuracy; the specialized-model curves are contextual references evaluated with a different scaffold.

12 Terminal Ablation Details↩︎

The terminal ablation keeps the student, rollout budget, SFT recipe, and Terminal-Bench 2.0 target fixed while changing the synthesis controls. The Terminal-2K w/o profile variant keeps the diverse scenario reservoir but removes selected task form fields from the directive interface. In Terminal-2K w/o profile, downstream stages receive the scenario but not selected task form dimensions. The Terminal-2K w/o scenario variant keeps sampled task form fields and replaces the concrete scenario with a neutral scenario seed. In the implementation, Terminal-2K w/o scenario samples directly from the reviewed profile without scenario-conditioned filtering and uses the same neutral scenario text for all items. The Terminal-2K control is the original scenario-conditioned directive construction.

3pt

Table 13 shows the strongest distributional effect. w/o profile collapses toward software engineering tasks and almost eliminates some terminal task families, consistent with the model’s default mapping from terminal scenarios to tasks. w/o scenario is much flatter because task form fields are sampled from the reviewed profile without a concrete scenario filter. At the reconstructed construction-dimension level, w/o scenario has normalized required-task type entropy 0.875 and effective support 16.15, compared with 0.565/6.02 for w/o profile and 0.571/6.13 for Terminal-2K. These effective-support values count distinct dimension candidates available before generation; they are not the realized task-type distribution in Table 13, which is far more concentrated for w/o profile (post-hoc labeling collapses to an effective count near one) because the generator defaults to software-engineering tasks when the directive removes selected task types. w/o profile and Terminal-2K therefore share almost the same construction-level support, yet differ sharply in realized diversity and downstream accuracy. This explains why w/o scenario remains competitive at 2,000 tasks, while the scenario reservoir is still important for large-scale synthesis where repeated neutral scenarios would make concrete task contexts generic.

13 Task-Package Audits and Realized Distribution↩︎

We audit the synthesized packages along three axes: static integrity, scenario-conditioned filtering, and the realized distribution over task-form dimensions. Table 14 checks that each package contains the expected artifacts and is grounded in real sources; Table 15 reports how aggressively the scenario-conditioned filter narrows the candidate pool before sampling; and Table 16 with Figure 8 show the realized coverage and concentration of each dimension. Terminal-1.6K is an intermediate corpus produced during the filtering-table audit; it uses a narrower profile (18 rather than 24 primary task types) but otherwise follows the same synthesis pipeline.

3pt

13.1 Task Quality Audit↩︎

To confirm that the synthesized packages are coherent and feasible, we manually inspect stratified task packages sampled from each corpus and ablation variant on a rubric covering five dimensions: description clarity (D1), material completeness (D2), workspace executability (D3), difficulty calibration (D4), and absence of internal-artifact leakage (D5). Overall quality is high: the majority of inspected packages score at least 4 on all five dimensions, and none receives any score below 3. Difficulty calibration is the most frequent deduction—a few tasks pack more work than the stated hour budget—while no internal-artifact leakage is observed. The Profile-only variant scores lowest because its from-scratch tasks contain fewer grounded materials, yet it still outperforms Scenario-only on Terminal-Bench 2.0, confirming that the ablation gap is driven by task-distribution shape rather than per-task package quality.

3pt

14 Scenario Reservoir Audit↩︎

We audit scenarios with the same embedding model used by the online novelty filter. All statistics in Table 17 are computed over the accepted scenario texts before scenario mining and task form composition. Pairwise cosine is the mean cosine over all unordered scenario pairs in a branch. Nearest-neighbor (NN) median measures local redundancy within the branch. The target silhouette uses cosine distance and the two target groups, terminal and office; higher values indicate stronger separation by target. Cross-target NN is the share of scenarios whose nearest neighbor inside the same branch belongs to the other target group.

3pt

The table supports three observations used in the main text. First, self-instruct is the most target-conditioned branch: it has the highest target silhouette and the lowest cross-target nearest-neighbor rate. Second, keyword research and keyword self-instruct are close in local compactness, but keyword research separates the two target intents slightly more strongly. Third, knowledge graph expansion has the weakest target separation, which is consistent with the branch exploring reusable entities, workflows, and contexts that can appear in both terminal and office settings.

15 Task-Description Embedding↩︎

We embed the final solver-facing task descriptions of the matched Terminal-2K and Office-2K sets (4,000 descriptions, 2,000 per target, 50/50 English–Chinese) with text-embedding-3-small and analyze their geometry. The two targets separate cleanly: a nearest-centroid classifier reaches 0.980 accuracy (0.980 for the four target–language groups), and 97.8% of nearest neighbors share the target (97.2% share target and language). Separation is not template collapse, however: within-target random pairs have mean cosine 0.571 versus 0.503 across targets, a modest gap, and nearest-neighbor cosine has median 0.797 with maximum 0.910, so descriptions are semantically concentrated by target and language without duplicating one another. Figure 9 shows the PCA projection, with four visible target–language clusters.

16 Synthesis Prompt Templates↩︎

The synthesis pipeline is driven by four stage prompts: diverse (task profile), mine (scenario research), ideate (task blueprint), and gen (task materialization); teacher rollouts use the NexAU runtime prompt. The stage prompts are written in Chinese in the released code; below are faithful English renderings. Jinja variables are shown as {{name}}, and the ablation-mode conditionals (guide_only, intent_only) are collapsed to the default both-use path; where a branch changes wording we note it inline. The verbatim original templates are included in the released prompt archive under analysis/prompts/.

16.1 Planning: Task Profile (diverse)↩︎

This prompt turns a free-form task-set specification into the reviewed task-form profile \(\Phi(I)\).

16.2 Mining: Scenario Research (mine)↩︎

Conditioned on the item directive (a scenario composed with compatible task-form fields), this prompt gathers realistic workflows, terminology, resources, and candidate materials.

16.3 Ideation: Task Blueprint (ideate)↩︎

This prompt turns the directive and mined materials into a single-schema blueprint (ideation.json), preparing real sources via DownloadSourceFile / PrepareGitHubRepo. A variant (history-to-blueprint) emits the same schema from the recorded research history as an XML-like document.

16.4 Generation: Task Materialization (gen)↩︎

This prompt writes the solver-facing package (task description, materials, Dockerfile, and internal audit files) from the blueprint, using prepared sources.

16.5 Teacher Rollout Runtime (distillation)↩︎

Teacher rollouts that produce the distillation trajectories run under the NexAU runtime prompt (already in English). The base system prompt and the context-compaction prompt are shown below; tool descriptions are provided per run.

References↩︎