Paper deep dive

NexForge: Scaling Agent Capabilities through Requirement-Driven Task Synthesis for LLMs

Jiarong Zhao, Zhikai Lei, Zhiheng Xi, Rui Zheng, Hang Yan, Jie Zhou, Qin Chen, Liang He

Year: 2026Venue: arXiv preprintArea: cs.SEType: PreprintEmbeddings: 89

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%

Last extracted: 7/20/2026, 2:03:12 AM

Summary

The paper introduces NexForge, a requirement-driven framework for synthesizing diverse, executable agent tasks and expert trajectories for Supervised Fine-Tuning (SFT) of Large Language Models (LLMs). Unlike substrate-bound methods that rely on fixed tools or repositories, NexForge profiles real-world demand to create representative scenarios and task profiles, then uses distribution-aware compilation to instantiate executable workspaces. This approach generates training data for terminal and office capabilities without domain-specific infrastructure, significantly improving the performance of models like Qwen3.5-35B-A3B and the open-source Nex-N2 family on benchmarks such as Terminal-Bench 2.0/2.1 and GDPval.

Entities (11)

NexForge · framework · 98%East China Normal University · organization · 95%GDPval · benchmark · 95%Nex-N2 · model · 95%Qwen3.5-35B-A3B · model · 95%Shanghai Qiji Zhifeng Co., Ltd · organization · 95%Terminal Bench 2.0 · benchmark · 95%Terminal-Bench 2.1 · benchmark · 95%Claude Opus 4.6 · model · 90%Office-2K · dataset · 90%Terminal-3.6K · dataset · 90%

Relation Signals (13)

Nex-N2 → achievesscoreon → GDPval

confidence 95% · and 1585 Elo on GDPval

Nex-N2 → achievesscoreon → Terminal-Bench 2.1

confidence 95% · advance Qwen3.5-35B-A3B to 75.3% on Terminal-Bench 2.1

Nex-N2 → achievesscoreon → GDPval

confidence 95% · 1585 Elo on GDPval

NexForge → improvesperformanceon → Qwen3.5-35B-A3B

confidence 95% · improving Qwen3.5-35B-A3B Base from 22.5% to 52.0% on Terminal-Bench 2.0

NexForge → improvesperformanceon → Qwen3.5-35B-A3B

confidence 95% · NexForge ... improving Qwen3.5-35B-A3B Base from 22.5% to 52.0% on Terminal-Bench 2.0

NexForge → synthesizesdatafor → Nex-N2

confidence 95% · NexForge-synthesized trajectories supervise SFT of Nex-N2

NexForge → generatesdataset → Terminal-3.6K

confidence 90% · We apply NexForge to two independently written capability requirements, producing Terminal-3.6K

NexForge → generatesdataset → Terminal-3.6K

confidence 90% · producing Terminal-3.6K for terminal agent post-training

NexForge → →

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:Synthesizing training data to scale agent capabilities in LLM post-training is bottlenecked by substrate-bound task synthesis: tasks are generated from fixed tools, repositories, or skill graphs, so expanding coverage requires manual substrate engineering, transferring to a new domain demands bespoke infrastructure, and the resulting distributions inherit substrate biases rather than reflecting real-world demand. We introduce NexForge, a requirement-driven framework that synthesizes diverse, executable agent tasks and expert trajectories for SFT from high-level capability requirements. NexForge first profiles real-world demand into representative scenarios and task profiles, then samples task forms per scenario. It then performs distribution-aware compilation, automatically retrieving or constructing files, repositories, dependencies, and runtime configurations to instantiate each task, followed by synthesizing expert rollouts and distilling trajectories. The same pipeline generates 3,600 terminal tasks and 2,000 office tasks without any domain-specific infrastructure, improving Qwen3.5-35B-A3B Base from 22.5\% to 52.0\% on Terminal-Bench 2.0 and from 813 to 1338 Elo on GDPval. Scaling to 43.2K terminal tasks further improves performance to 58.4\%, surpassing Claude Opus 4.6. At scale, NexForge-synthesized trajectories supervise SFT of Nex-N2, a family of open agent models that advance Qwen3.5-35B-A3B to 75.3\% on Terminal-Bench 2.1 and 1585 Elo on GDPval -- achieving state-of-the-art open-source performance and surpassing several frontier proprietary systems. Nex-N2 models are available at this https URL.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

87,526 characters extracted from source content.

Expand or collapse full text

NEXFORGE: SCALING AGENT CAPABILITIES THROUGH REQUIREMENT-DRIVEN TASK SYNTHESIS FOR LLMS Jiarong Zhao 1 , Zhikai Lei 2,* , Zhiheng Xi 2 , Rui Zheng 2 , Hang Yan 2 , Jie Zhou 1,* , Qin Chen 1 , Liang He 1 1 East China Normal University 2 Shanghai Qiji Zhifeng Co., Ltd * Corresponding authors ABSTRACT Synthesizing training data to scale agent capabilities in LLM post-training is bottlenecked by substrate-bound task synthesis: tasks are generated from fixed tools, repositories, or skill graphs, so expanding coverage requires manual substrate engineering, transferring to a new domain demands bespoke infrastructure, and the resulting distributions inherit substrate biases rather than reflecting real-world demand. We introduce NexForge, a requirement-driven framework that synthesizes diverse, executable agent tasks and expert trajectories for SFT from high-level capability requirements. NexForge first profiles real-world demand into representative scenarios and task profiles, then samples task forms per scenario. It then performs distribution-aware compilation, automatically retrieving or constructing files, repositories, dependencies, and runtime configurations to instantiate each task, followed by synthesizing expert rollouts and distilling trajectories. The same pipeline generates 3,600 terminal tasks and 2,000 office tasks without any domain-specific infrastructure, improving Qwen3.5-35B-A3B Base from 22.5% to 52.0% on Terminal-Bench 2.0 and from 813 to 1338 Elo on GDPval. Scaling to 43.2K terminal tasks further improves performance to 58.4%, surpassing Claude Opus 4.6. At scale, NexForge-synthesized trajectories supervise SFT of Nex-N2, a family of open agent models that advance Qwen3.5-35B-A3B to 75.3% on Terminal-Bench 2.1 and 1585 Elo on GDPval—achieving state-of-the-art open-source performance and surpassing several frontier proprietary systems. Nex-N2 models are available at https://nex.sii.edu.cn/. 1INTRODUCTION Building capable LLM agents for real-world tasks is bottlenecked by the scarcity of high-quality, diverse training data. Post-training these agents requires not only task descriptions, but also grounded materials, executable environments, and long-horizon interaction trajectories. Producing such data at Figure 1: Nex-N2 performance on Terminal-Bench 2.1 and GDPval via NexForge data scaling. 1 arXiv:2607.14186v2 [cs.SE] 17 Jul 2026 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 generating executable tasks tied to predefined repositories, tools, skills, or execution traces (Dong et al., 2026; Wang et al., 2026; Chen et al., 2026; Xie et al., 2025; Fan et al., 2026; Cheng et al., 2026; Yang et al., 2025; Jain et al., 2025). However, these substrate-bound 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 (Fan et al., 2026; Cheng et al., 2026), repository harnesses for software engineering (Yang et al., 2025; Jain et al., 2025), or simulated tool ecosystems (Dong et al., 2026) – making transfer to new capabilities costly. 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 biases rather than real-world demand. We argue that scaling agent capabilities through LLM post-training requires decoupling task generation from predefined substrates. Environment synthesis should instead begin with capability requirements: before any workspace is built, the system must determine both which tasks are representative of the desired capability and the diverse real-world contexts in which they arise. Only then should the materials and runtime environments be constructed to match. This requirement-driven formulation separates what an agent should practice from how that practice is made executable, enabling the same pipeline to scale across domains without building new domain-specific infrastructure for each target. To this end, we introduce NexForge, a requirement-driven framework that synthesizes diverse, executable agent tasks and expert trajectories for SFT, all from high-level capability requirements. NexForge first profiles real-world demand into representative scenarios and task profiles, then samples task forms for each scenario. It then applies distribution-aware compilation, combining sampled task forms with concrete scenarios into a task directive for subsequent instantiation. Finally, NexForge instantiates each task into a complete, executable workspace, and synthesizes expert rollouts and distills trajectories. By doing so, NexForge controls training data composition independently of predefined tools or repositories and applies the same synthesis pipeline across substantially different capability domains. We evaluate NexForge on two disparate capabilities: 3,600 tasks for terminal operations improve Qwen3.5-35B-A3B from 22.5% to 52.0% on Terminal-Bench 2.0; 2,000 tasks for office work improve the same model from 813 to 1338 Elo on GDPval, both synthesized without domain-specific engineering. Moreover, scaling up the training data further enables Nex-N2 to reach state-of-the-art open-source performance on both capabilities, as shown in Figure 1. Our contributions are threefold: •We formulate environment scaling for agent post-training as a requirement-driven scaling problem, identifying three bottlenecks of substrate-bound synthesis: input-bounded scale, high transfer cost, and substrate-biased distributions. •We propose NexForge, an end-to-end framework that profiles real-world demand, instantiates executable training environments, and collects expert trajectories, without domain-specific infrastructure. •We demonstrate that the same framework generates effective training data for both terminal and office capabilities, substantially improving the performance of the downstream agent in distinct domains. 2RELATED WORKS Instruction and task-distribution synthesis. Scalable data synthesis often decomposes a broad capability space before generating individual examples. Self-Instruct (Wang et al., 2023) bootstraps instruction-following data from a small seed set, while GLAN (Li et al., 2024) organizes generation through a hierarchical taxonomy of disciplines and tasks. TRouter (Liu et al., 2026) controls synthetic 2 examples using explicit task profiles, and Benchmark Agent (Xiong et al., 2026) 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 benchmarks rather than complete executable environments. Extending these approaches to agent training would additionally require grounding each task with materials, dependencies, and runtimes—a step these methods do not address. Agent task and environment synthesis. Recent work has explored executable agent-data construction through simulated environments and tool ecosystems (Dong et al., 2026; Wang et al., 2026), execution traces and subtask composition (Chen et al., 2026; Xie et al., 2025; Shi et al., 2025), and domain-specific repositories and skills (Fan et al., 2026; Cheng et al., 2026; Yang et al., 2025; Jain et al., 2025). Agent-World (Dong et al., 2026) and Agent World Model (Wang et al., 2026) synthesize stateful tool environments, while DIVE (Chen et al., 2026) derives grounded and verifiable tasks from execution evidence. AgentSynth (Xie et al., 2025) and TaskCraft (Shi et al., 2025) construct complex tasks through subtask composition and difficulty control. For terminal agents, SkillSynth (Fan et al., 2026) generates tasks from structured skill specifications, Terminal-World (Cheng et al., 2026) builds environments around reusable agent skills, CLI-Universe (Hua et al., 2026) constructs terminal tasks from a predefined capability taxonomy, and TerminalTraj (Wu et al., 2026), Nemotron-Terminal (Pi et al., 2026), LiteCoder-Terminal (Peng et al., 2026), and OpenThoughts-Agent (Raoof et al., 2026) collect or curate terminal interaction trajectories and training corpora. In software engineering, SWE-smith (Yang et al., 2025) and R2E-Gym (Jain et al., 2025) generate executable tasks from repositories, tests, and issue-like workflows. These methods establish the importance of executable environments but share three scaling limitations with substrate-bound approaches. (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 libraries 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-biased 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 high-level capability requirements rather than predefined substrates: the same pipeline scales across distinct agent capabilities (terminal and office) without new domain-specific infrastructure. 3METHOD NexForge scales from a high-level user requirement to diverse executable workspaces and interaction trajectories for agent post-training. As illustrated in Figure 2, the framework contains three main stages. First, it profiles real-world demand 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-driven pipeline determines what capabilities the agent should acquire before constructing the materials and runtime environments that make the practice executable, enabling the same architecture to scale across agent capability targets. 3.1PROBLEM FORMULATION NexForge takes as input a high-level capability requirementI, a requested task countN, and optional batch-level constraintsBthat let the user override the induced distribution along specific dimensions such as language or difficulty. It outputs a collection T =τ 1 ,...,τ N ,(1) where eachτ i is an executable task package containing a task instruction, grounded materials, workspace files, software dependencies, and a runtime configuration, designed for trajectory collection and agent training. 3 Input Research-BasedDemand Discovery Output Distribution-AwareTask Compilation From Task Directivesto Training Trajectories Web SearchLLM Generation Φ(퐼) Free-Form User Requirement Task Demand Profile Scenario Reservoir 퐺퐼 Task TypeDeliverableMultipleSource File TypesInformationRuntime Env. Keyword Pool Keyword Self-Instruct Keyword Search Direct Self-Instruct Knowledge Graph Profile 푓=Φ(퐼) Scenario 푠=퐺퐼 DirectiveComposer 푓,푠→훿 Compatibility Filter Task Directive δ task formscenariolanguagedifficulty EnvironmentMaterialization Material Mining Blueprint Designing Workspace Generation & Validation Executable Workspace Trajectory Collection & Distillation Teacher Model Interact with Executable Workspace General Filter Teacher Trajectory Executable Task Packages Training Trajectories Language Difficulty Text Input Scenario Distribution Weighted Sampling Figure 2: Overview of NexForge. Given a high-level user requirement, NexForge first profiles real-world demand to construct a task demand profile and scenario reservoir, then composes distribution-aware task directives across scenarios. Each directive is subsequently instantiated into an executable workspace, where teacher interactions are collected and distilled into training trajectories. We represent each task using a task form f i and a scenario s i : τ i ← (f i ,s i ).(2) The task formf i = (t i ,d i ,σ i ,e i ,ℓ i ,h i )specifies the primary task typet i , expected deliverable d i , source strategyσ i , runtime environmente i , languageℓ i , and difficultyh 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.2RESEARCH-BASED DEMAND DISCOVERY Given the requirementI, 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 model knowledge, is organized into a weighted task demand profile and a diverse scenario reservoir. Task demand profile. The task demand profileΦ(I)defines the intended distribution over the dimensions of the task form: Φ(I) =Φ t , Φ d , Φ σ , Φ e , Φ ℓ , Φ h ,(3) where eachΦ k is a weighted categorical distribution. Candidate options are derived 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-derived weights govern the relative sampling proportion of each option for 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. Scenario reservoir. The scenario reservoirG(I)contains concrete scenario guides (scenarios for short) that describe working contexts in which task forms can be instantiated. NexForge populates it 4 through four mechanisms: (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 sampling proportion of each mechanism can be configured through the batch-level constraintsB. All candidate scenarios undergo embedding-based semantic deduplication to ensure diversity across the reservoir. Each scenario intentionally describes only the working context and omits task type, deliverable, source strategy, and runtime. This prevents scenarios from independently determining the task distribution. 3.3DISTRIBUTION-AWARE TASK COMPILATION NexForge composes the task-form profile and scenario reservoir into directives. For each scenario g j ∈ G(I), the composer instantiates it into a concrete scenario, then sequentially filters profile options by compatibility with the scenario and previously selected fields. LetK =t,d,σ,edenote the ordered task-form dimensions that require compatibility decisions. For each dimension k ∈ K, the composer obtains a compatible candidate set C j,k = F θ (I,g j ,k, Φ k ,S j,<k ),(4) whereS j,<k contains options selected in earlier steps. An option is then sampled according to the profile weights restricted to the compatible set: f j,k ∼ Normalize Φ k | C j,k .(5) Language and difficulty are sampled according to the corresponding profile distributions and batch constraints B. The resulting directive is δ j =⟨g j ,f j ,A j ,ℓ j ,h j ,R j ⟩,(6) whereA j records the compatible candidate sets andR j stores the composition rationale. The directive determines 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.4AGENT POST-TRAINING TRAJECTORY GENERATION A task directive specifies the intended work but is not yet executable. NexForge instantiates each directive into an executable workspace and subsequently collects and distills teacher interactions into post-training trajectories. Environment instantiation. Given a task directiveδ j , NexForge instantiates the intended task through three successive steps: material mining, blueprint planning, and workspace generation. 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, the research agent 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 expected deliverables. 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. 5 Trajectory collection and distillation. Each workspace is assigned to a teacher model under a fixed interaction budget. The teacher model 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 trajectory 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 trajectories 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. 4DATASETS We apply NexForge to two independently written capability requirements, producing Terminal-3.6K for terminal agent post-training and Office-2K for office agent post-training. The two corpora differ substantially in their task forms, grounding materials, and runtime requirements, demonstrating that the same synthesis pipeline can scale across distinct user-defined capabilities without domain-specific engineering. To study data scaling, we additionally produce Terminal-2K, Terminal-43.2K, and Office-22K using the same pipeline. 4.1TASK-SET SPECIFICATIONS The terminal specification covers agent command-line capabilities such as repository inspection, software building, configuration editing, data processing, system operation, and local validation, while the office specification includes agent office-work capabilities such as spreadsheet analysis, document review, information aggregation, summarization, drafting, planning, and evidence-based recommendations. Both use a 50/50 Chinese–English split and balanced difficulty distributions. Terminal-3.6K contains 3,600 tasks, matching SkillSynth in task count and interaction budget, whereas Office-2K contains 2,000 independently synthesized office tasks. 1 4.2CORPUS STATISTICS AND ROLLOUTS Table 1 summarizes corpus scale, trajectory complexity, task diversity, and grounding characteristics. We collect 3 teacher rollouts per task for all reported corpora. All synthesis agents are driven by GPT-5.5. After trajectory conversion and task-independent trajectory cleaning, this yields 8,521 trajectories for Terminal-3.6K (2.37 per task) and 5,940 for Office-2K (2.97 per task), reflecting natural failure rates. 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-form 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, SFT 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 configuration adapted to the dense base model. 4.3COMPARISON 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 scale and transfer. NexForge instead takes a high-level user requirement as input, profiles real-world demand to identify representative task demands and their relative prevalence, and then constructs the materials and 1 All synthesis stages use GPT-5.5. 6 Table 1: Corpus statistics. Task counts, trajectory scale, and ablation variants. w/o profile removes task-form sampling; w/o scenario replaces grounded scenarios with neutral seeds. StatisticTerm.-3.6KOffice-2Kw/o profilew/o scenario Executable tasks3,6002,0002,0002,000 Converted trajectories8,5215,9404,5744,541 Trajectories per task2.372.972.292.27 Avg. tokens per traj.129K107K124K154K Avg. tool calls per traj.12354116133 Chinese / English50/5050/5050/5050/50 Difficulty allocationBalancedBalancedBalancedBalanced Realized task types2415∼3∼16 Top-10 signature cov.20.6%15.1%78.5%24.9% Mean package size10.9 MB9.4 MB5.8 MB9.6 MB Table 2: Dataset comparison. Columns: requirement-driven design (Req.), scenario reservoir (Res.), distribution control (Dist.), environment materialization (Env.), and cross-capability transfer (Cap.). △: partial support. DatasetSynthesis PriorScaleReq.Res.Dist.Env.Cap. AgentSynth (Xie et al., 2025)Composable subtasks>6K– △– △ TaskCraft (Shi et al., 2025)Atomic tasks & tools∼36K– △– △ DIVE (Chen et al., 2026)Executed tool traces48K+3.2K– △– △ R2E-Gym (Jain et al., 2025)Repos & commits>8.7K–✓– SWE-smith (Yang et al., 2025)Repos & tests50K–✓– SkillSynth (Fan et al., 2026)Skill graph3.6K– △✓– Term.-World (Cheng et al., 2026)Agent skills5.7K– △✓– CLI-Univ. (Hua et al., 2026)Capability taxonomy6K–✓ △✓– NexForgeFree-form requirement5.6K / 14.5K✓ executable environments needed to instantiate them. This requirement-driven design separates corpus-level task distribution from grounding resources and enables scalable agent post-training across diverse capability domains through the same synthesis pipeline. 5EXPERIMENTS 5.1EXPERIMENTAL SETUP Training. We perform full-parameter SFT on Qwen3-32B and Qwen3.5-35B-A3B Base for five epochs with a maximum context length of 262K, packed bfloat16 sequences, a global batch size of 64, a learning rate of10 −5 with cosine decay and 5% warmup, on 128 H100 GPUs. The Qwen3-32B comparison uses Terminal-3.6K with the same configuration adapted to the dense base model. Evaluation. We evaluate on Terminal-Bench 2.0 (Terminal-Bench Team, 2026) and GDPval (Pat- wardhan et al., 2025) to assess agent capabilities on terminal and office tasks. All controlled runs of our models use the NexAU evaluation harness with consistent tools and inference settings. Baseline results are from published papers or public leaderboards and may use different scaffolds. We compare our models with frontier proprietary models and terminal-specialized 32B baselines (Peng et al., 2026; Wu et al., 2026; Raoof et al., 2026; Pi et al., 2026; Fan et al., 2026; Hua et al., 2026; Cheng et al., 2026). 5.2MAIN RESULTS Table 3 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 from5.6%±0.9to32.3%±2.4, while Qwen3.5-35B-A3B increases from22.5%±0.9to52.0%±3.6, corresponding to absolute gains of 26.7 and 29.5 points, respectively. This suggests that the 7 Table 3: Terminal-Bench 2.0 pass@1 accuracy. Left: frontier proprietary models; right: terminal-specialized 32B models. NexAU rows are our controlled runs. Baselines ModelParamsScaffoldTB 2.0 Gemini 3.1 Pro–TongAgents 80.2± 2.6 DeepSeek-V4-Pro1.6Tofficial67.9 Claude Opus 4.6–Claude Code 58.0± 2.9 MiniMax M2.7230Bofficial57.0 GPT-5.2–Terminus 254.0± 2.9 GLM 5744BTerminus 252.4± 2.6 Claude Opus 4.5–OpenHands 51.9± 2.9 Gemini 3 Flash–Terminus 251.7± 3.1 GPT-5.1–Terminus 247.6± 2.8 Kimi K2.51TTerminus 243.2± 2.9 MiniMax M2.5230BTerminus 242.2± 2.6 DeepSeek-V3.2671BTerminus 239.6± 2.8 Qwen 3 Coder480BTerminus 223.9± 2.8 Specialized ModelScaffoldTB 2.0 LiteCoder-Terminal-32B-SFTTerminus 218.5±3.4 TerminalTraj-32BTerminus 222.0±5.8 OpenThinkerAgent-32BTerminus 226.2±1.6 Nemotron-Terminal-32BTerminus 227.4±2.4 Qwen3-32B + SkillSynthTerminus 229.6±1.6 CLI-Universe-32B (DS)Terminus 231.2 Terminal-World-32BTerminus 231.5 Ours Qwen3-32BNexAU5.6± 0.9 + Terminal-3.6KNexAU32.3±2.4 Qwen3.5-35B-A3B BaseNexAU22.5±0.9 + Terminal-3.6KNexAU52.0±3.6 Base2K3.6K43.2K Training Data Scale 20 30 40 50 60 TB 2.0 Accuracy (%) Terminal Scaling 22.5 43.8 52.0 58.4 Kimi K2.5 Claude Opus 4.5 Claude Opus 4.6 Base2K22K Training Data Scale 800 1000 1200 1400 GDPval Elo Office Scaling 813 1338 1384 Gemini 3.1 Pro GLM-5 Figure 3: Data scaling in two domains. Terminal-Bench 2.0 accuracy (left) and GDPval Elo (right) as a function of NexForge data scale on Qwen3.5-35B-A3B. Dashed lines mark frontier reference models. Performance improves monotonically with data volume, and the same pipeline transfers across domains with only a specification change. synthesized data provides useful terminal interaction patterns that improve agent capabilities 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 to terminal tasks. Third, combining Terminal-3.6K with the stronger Qwen3.5 base brings 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 requirement-driven environment synthesis produces high-quality post-training data that scales agent capabilities across model scales and remains competitive with domain-specific data construction pipelines. 5.3SCALING 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. Domain transfer.Because NexForge is requirement-driven, 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 8 Table 4: GDPval Elo results. Office capability evaluation. Elo is calibrated to the GDPval-A v1 (Artificial Analysis, 2025) with GPT-5.1 anchored at 1000. GroupModelGDPval Elo Baselines GPT-5.41667 Claude Sonnet 4.61633 GLM-51408 Gemini 3.1 Pro1316 MiniMax M2.51202 Gemini 3 Flash1191 GPT-5.11000 Ours Qwen3.5-35B-A3B Base813 + Office-2K1338 processing, spreadsheet analysis, planning, communication, and evidence-based recommendations. As shown in Table 4, 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 with GLM-5 (1408) to 24 Elo. The same pipeline that produces terminal data thus enables agent post-training for an entirely different capability with only a specification change. 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 number of tasks. 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 in agent performance, as shown in Table 3 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 effectively scales agent capabilities. The same pattern holds on GDPval: Office-2K (1338) to Office-22K (1384) shows consistent 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. 5.4ABLATION STUDIES We examine whether task-form control and scenario grounding provide complementary signals during task compilation. Under the same 2,000 tasks with 3 rollouts per task and SFT configuration, 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 the teacher model to infer tasks directly from each scenario. Terminal-2K w/o scenario retains the task-form profile but replaces concrete scenarios with neutral seeds. Terminal-2K corresponds to the complete NexForge pipeline, where task forms are sampled conditioned on concrete scenarios. DATC directive quality. On the terminal run, the compatibility filter retains on average only 4.4of24task types,5.2of8deliverables,2.7of4source strategies, and4.5of20runtimes per scenario, so just2.0%of the full24×8×4×20task-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 task-form directive 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 tasks of Terminal-2K, DATC directives achieve a match rate of 81.0%, while random directives achieve only 7.0%, as reported in Table 5. The large gap confirms that scenario-conditioned compilation is essential for producing coherent task directives. Table 6 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%,∼3 effective types), while w/o scenario broadens coverage (∼16 effective types) but yields a flat distribution that under-represents frequent workflows. Terminal-2K strikes an intermediate balance (∼6 effective types) with the longest trajectories (114 assistant messages, 149 tool calls). Task-form control preserves coverage; scenario grounding structures the training distribution. 9 Table 5: Directive compatibility. LLM-judge match rate between directives and scenarios. w/o DATC replaces scenario-conditioned compilation with uniform-random task-form assignment. CorpusMethodMatch countMatch rate Terminal-2K DATC1,620 / 2,00081.0% w/o DATC140 / 2,0007.0% Table 6: Ablation studies. Asst./Tool: mean assistant messages and tool calls per trajectory. TB 2.0: pass@1 accuracy on Terminal-Bench 2.0. VariantScenarioTask FormAsst.ToolTB 2.0 Terminal-2KReservoirProfile11414943.8± 4.3 – w/o profileReservoirNone9813340.2± 5.0 – w/o scenarioNeutral seedProfile9512542.7± 4.2 Terminal Software eng. 54% System admin. 12% Data processing 9% Scienti fi c comp. 4% Systems prog. 3% Others (18) 18% Office Data analysis 21% Doc. review 17% Aggregation 14% Communication 10% Decision support 10% Others (10) 28% Terminal Office 451432 96921 (b) Source strategy GitHub repoWeb fileGeneratedNo source 15101520 Task type rank (sorted by share) 1 5 10 20 40 60 80 Share (%, sqrt) (c) Distribution shape Terminal-2K – w/o profile – w/o scenario 20406080 Top-1 task-type share (%) 35 40 45 50 TB 2.0 pass@1 (%) (d) Concentration vs. accuracy (a) Realized task types Figure 4: Distribution analysis. (a) Task-type frequencies, (b) grounding-source composition, (c) assistant message counts, and (d) tool-call counts per trajectory across ablation variants. 5.5FURTHER ANALYSIS 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. 69% of office tasks using web files. These shifts arise from input specifications alone, confirming cross-domain scalability. 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. 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 tasks generated without scenario grounding 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 performance gap between ablations is not 10 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. 6CONCLUSION AND FUTURE WORK We present NexForge, a requirement-driven framework that scales agent post-training data synthesis from high-level capability requirements. By decoupling task-form control and scenario grounding from predefined substrates, NexForge enables the same pipeline to scale agent capabilities across distinct domains without domain-specific infrastructure. Experiments on terminal and office tasks demonstrate strong cross-domain scaling of agent capabilities. NexForge scales to tens of thousands of tasks, training 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-driven synthesis effectively scales agent capabilities at production scale. Ablations confirm that combining task-form control with scenario grounding 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. REFERENCES Artificial Analysis. GDPval-A v1: Standardized elo evaluation for economically valuable tasks. https://artificialanalysis.ai/evaluations/gdpval-a, 2025. Aili Chen, Chi Zhang, Junteng Liu, Jiangjie Chen, Chengyu Du, Yunji Li, Ming Zhong, Qin Wang, Zhengmao Zhu, Jiayuan Song, Ke Ji, Junxian He, Pengyu Zhao, and Yanghua Xiao. DIVE: Scaling diversity in agentic task synthesis for generalizable tool use. arXiv preprint arXiv:2603.11076, 2026. Zihao Cheng, Hongru Wang, Zeming Liu, Xinyi Wang, Xiangrong Zhu, Yuhang Guo, Wei Lin, Jeff Z. Pan, and Yunhong Wang. Terminal-world: Scaling terminal-agent environments via agent skills. arXiv preprint arXiv:2605.20876, 2026. Guanting Dong, Junting Lu, Junjie Huang, Wanjun Zhong, Longxiang Liu, Shijue Huang, Zhenyu Li, Yang Zhao, Xiaoshuai Song, Xiaoxi Li, Jiajie Jin, Yutao Zhu, Hanbin Wang, Fangyu Lei, Qinyu Luo, Mingyang Chen, Zehui Chen, Jiazhan Feng, Ji-Rong Wen, and Zhicheng Dou. Agent-world: Scaling real-world environment synthesis for evolving general agent intelligence. arXiv preprint arXiv:2604.18292, 2026. Zhiyuan Fan, Tinghao Yu, Yuanjun Cai, Jiangtao Guan, Yun Yang, Dingxin Hu, Jiang Zhou, Xing Wu, Zhuo Han, Feng Zhang, and Lilin Wang. Toward scalable terminal task synthesis via skill graphs. arXiv preprint arXiv:2604.25727, 2026. Zhanbo Hua, Yifan Yao, Weihao Xie, Yongchi Zhao, Minghao Liu, Ruizhi Qiu, Zhewei Huang, Zun Wang, Yiyan Ji, Yunhai Ye, Letian Zhu, Xinping Lei, Han Li, Zhiyuan Ma, Zili Wang, Zhaoxiang Zhang, and Jiaheng Liu. CLI-Universe: Towards verifiable task synthesis engine for terminal agents. arXiv preprint arXiv:2606.22883, 2026. Naman Jain, Jaskirat Singh, Manish Shetty, Liang Zheng, Koushik Sen, and Ion Stoica. R2E-gym: Procedural environments and hybrid verifiers for scaling open-weights SWE agents. arXiv preprint arXiv:2504.07164, 2025. Haoran Li, Qingxiu Dong, Zhengyang Tang, Chaojun Wang, Xingxing Zhang, Haoyang Huang, Shaohan Huang, Xiaolong Huang, Zeqiang Huang, Dongdong Zhang, Yuxian Gu, Xin Cheng, Xun Wang, Si-Qing Chen, Li Dong, Wei Lu, Zhifang Sui, Benyou Wang, Wai Lam, and Furu Wei. Synthetic data (almost) from scratch: Generalized instruction tuning for language models. arXiv preprint arXiv:2402.13064, 2024. Hui Liu, Bin Zou, Kecheng Chen, Jie Liu, Wenya Wang, and Haoliang Li. Task-aware llm routing with multi-level task-profile-guided data synthesis for cold-start scenarios. arXiv preprint arXiv:2604.09377, 2026. 11 Tejal Patwardhan, Rachel Dias, Elizabeth Proehl, Grace Kim, Michele Wang, Olivia Watkins, Sim ́ on Posada Fishman, Marwan Aljubeh, Phoebe Thacker, Laurance Fauconnet, Natalie S. Kim, Patrick Chao, Samuel Miserendino, Gildas Chabot, David Li, Michael Sharman, Alexandra Barr, Amelia Glaese, and Jerry Tworek. GDPval: Evaluating ai model performance on real-world economically valuable tasks. arXiv preprint arXiv:2510.04374, 2025. Xiaoxuan Peng, Kaiqi Zhang, Xinyu Lu, Boxi Cao, Yaojie Lu, Hongyu Lin, Xianpei Han, and Le Sun. LiteCoder-Terminal: Scaling long-horizon terminal environments for learning language agents. arXiv preprint arXiv:2605.29559, 2026. Renjie Pi, Grace Lam, Mohammad Shoeybi, Pooya Jannaty, Bryan Catanzaro, and Wei Ping. On data engineering for scaling LLM terminal capabilities. arXiv preprint arXiv:2602.21193, 2026. Negin Raoof, Richard Zhuang, Marianna Nezhurina, Etash Guha, Atula Tejaswi, Ryan Marten, Charlie F. Ruan, Tyler Griggs, Alexander Glenn Shaw, Hritik Bansal, E. Kelly Buchanan, Artem Gazizov, Reinhard Heckel, Chinmay Hegde, Sankalp Jajee, Daanish Khazi, Emmanouil Koukoumidis, Xiangyi Li, Hange Liu, Shlok Natarajan, Harsh Raj, Nicholas Roberts, Ethan Shen, Nishad Singhi, Michael Siu, Ashima Suvarna, Hanwen Xing, Patrick Yubeaton, Robert Zhang, Leon Liangyu Chen, Xiaokun Chen, Steven Dillmann, Saadia Gabriel, Xunyi Jiang, Anurag Kashyap, Boxuan Li, Yein Park, Minh Pham, Sujay Sanghavi, Lin Shi, Ke Sun, Yixin Wang, Zhiwei Xu, Erica Zhang, Siyan Zhao, Wanjia Zhao, Jenia Jitsev, Alex Dimakis, Benjamin Feuer, and Ludwig Schmidt. Openthoughts-agent: Data recipes for agentic models. arXiv preprint arXiv:2606.24855, 2026. Dingfeng Shi, Jingyi Cao, Qianben Chen, Weichen Sun, Weizhen Li, Hongxuan Lu, Fangchen Dong, Tianrui Qin, King Zhu, Minghao Liu, Jian Yang, Ge Zhang, Jiaheng Liu, Changwang Zhang, Jun Wang, Yuchen Eleanor Jiang, and Wangchunshu Zhou. Taskcraft: Automated generation of agentic tasks. arXiv preprint arXiv:2506.10055, 2025. Terminal-Bench Team.Terminal-Bench 2.0 leaderboard.https://w.tbench.ai/ leaderboard/terminal-bench/2.0, 2026. Accessed 2026-06-22. Yizhong Wang, Yeganeh Kordi, Swaroop Mishra, Alisa Liu, Noah A. Smith, Daniel Khashabi, and Hannaneh Hajishirzi. Self-instruct: Aligning language models with self-generated instructions. In Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics, p. 13484–13508, 2023. Zhaoyang Wang, Canwen Xu, Boyi Liu, Yite Wang, Siwei Han, Zhewei Yao, Huaxiu Yao, and Yuxiong He. Agent world model: Infinity synthetic environments for agentic reinforcement learning. arXiv preprint arXiv:2602.10090, 2026. Siwei Wu, Yizhi Li, Yuyang Song, Wei Zhang, Yang Wang, Riza Batista-Navarro, Xian Yang, Mingjie Tang, Bryan Dai, Jian Yang, and Chenghua Lin. Large-scale terminal agentic trajectory generation from dockerized environments. arXiv preprint arXiv:2602.01244, 2026. Jingxu Xie, Dylan Xu, Xuandong Zhao, and Dawn Song. Agentsynth: Scalable task generation for generalist computer-use agents. arXiv preprint arXiv:2506.14205, 2025. Shiyun Xiong, Dongming Wu, Peiwen Sun, Yuang Ai, Bokang Yang, Wencheng Han, Xiao-Hui Li, and Xiangyu Yue. Benchmark everything everywhere all at once. arXiv preprint arXiv:2606.06462, 2026. John Yang, Kilian Lieret, Carlos E. Jimenez, Alexander Wettig, Kabir Khandpur, Yanzhe Zhang, Binyuan Hui, Ofir Press, Ludwig Schmidt, and Diyi Yang. SWE-smith: Scaling data for software engineering agents. arXiv preprint arXiv:2504.21798, 2025. APPENDIX This supplementary material documents the implementation details, complete statistics, and additional analyses that support the main paper’s claims on scalable agent post-training data synthesis. It is organized as follows. We first give the formal scenario-conditioned task-compilation procedure 12 (Algorithm 1) 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. ASCENARIO-CONDITIONED COMPILATION PROCEDURE Algorithm 1 details how NexForge composes a task directiveδ j from the task demand profile Φ(I)and a single scenariog j drawn from the reservoirG(I). The composer processes the ordered task-form dimensionst,d,σ,e(task type, deliverable, source strategy, runtime) one at a time. For each dimensionk, a compatibility filterF θ inspects the requirement, the scenario, and the fields already selected, and returns the subsetCof profile options that remain coherent in this context; the realized fieldf j,k is then sampled from the profile weights restricted toC. 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 guide the corpus-level distribution. Languageℓ j and difficultyh j are drawn last under the batch-level constraints rather than from scenario compatibility, and the retained candidate setsAtogether with the per-step rationaleRare recorded so that downstream stages instantiate the sampled work rather than re-inferring it from whatever materials happen to be available. Algorithm 1 Scenario-conditioned task compilation Input: requirement I , profile Φ(I), scenario g j Output: task directive δ j 1: S,A,R←∅,∅,∅ 2: for k ∈t,d,σ,e do 3: C ← F θ (I,g j ,k, Φ k ,S) 4: A[k]← C 5: f j,k ∼ Normalize(Φ k | C ) 6: S ← S∪f j,k 7:Append the compatibility rationale to R 8: end for 9: Sample ℓ j and h j under the batch constraints 10: return δ j =⟨g j ,S,A,ℓ j ,h j ,R⟩ BEND-TO-END CASE STUDY To make the pipeline concrete, we trace a single terminal task from the sampled directive to the runnable package (Figure 5). 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. 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 1, 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. 13 Figure 5: End-to-end Terminal-3.6K example: pMARS cross-compilation scenario composed into an executable workspace. 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. 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. 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. Why the directive matters. This example shows the difference between requirement-driven and substrate-bound synthesis in miniature. A substrate-bound 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). 14 Table 7: Trajectory signal scale per task group. Task groupPackages Distinct Attempts Records Tok. B Avg. tok/att. Calls/att. Terminal-3.6K3,6003,5018,52117,6353.350129.3K123.3 Office-2K2,0002,0005,9406,3880.693106.7K53.6 Terminal-2K2,0001,9474,6569,2141.760128.7K131.7 w/o profile2,0001,9164,5746,5551.019154.0K132.8 w/o scenario2,0001,8944,54111,0391.826123.7K116.4 Table 8: Token and operation mix in converted trajectories. Task groupSteps Tool Reason B Tool-call B Read Write Build/test Terminal-3.6K82.2 16.01.1711.574 26.451.54.7 Office-2K55.6 39.70.0720.313 42.834.11.0 Terminal-2K81.6 16.20.5260.907 24.752.24.7 w/o profile76.3 22.10.5520.837 28.545.13.2 w/o scenario68.3 30.00.2570.435 34.848.33.8 CAGENT POST-TRAINING DATA: 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. C.1REVIEWED PROFILE AND KEYWORD POOLS The reviewed task-form profile defines the candidate space that later sampling draws from. For 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 clear semantics before sampling; the realized coverage and concentration of each dimension are reported in Table 17, and the per-item scene-conditioned narrowing of these pools in Table 16. C.2TRAJECTORY SCALE AND TOKEN MIX Table 7 separates original teacher rollouts from the framework-internal cleaned records for each task group and reports per-rollout token and tool-call averages, while Table 8 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. C.3CAPABILITY REQUIREMENT SPECIFICATIONS The two corpora are generated from independently written capability requirements. Each specification is a high-level natural-language description of the target capability that serves as the pipeline inputI (Section 4.1). Below are faithful English renderings of the two specifications. Terminal capability requirement. 15 Design terminal-agent tasks that cover the distribution of multi-domain technical tasks in real command-line environments. The task scope spans software engineering, system administration, security engineering, scientific computing, data science, data processing, data querying, machine learning, model training, mathematical problem solving, optimization, code comprehension, file operations, game or strategy solving, multimedia processing, personal-assistant automation, and other primary directions, with room for further expansion based on real terminal task forms. Each item should require the agent to carry out real technical work through shell commands in a controlled terminal environment and produce deliverables with a well-defined final state, external behavior, or file-level result. Task outputs should be reproducible, executable, and machine-verifiable---for example, source-code or script changes, system configurations or environment states, SQL or structured-data results, model or numerical outputs, optimization plans, processed files or media, game/strategy solutions, automation execution results, build artifacts, or test outcomes. Generated items should vary substantially across task category, runtime environment, input content, required tool chain, operation path, boundary conditions, and success criteria. Office capability requirement. Design high-value professional work tasks situated in real organizations. The task scope covers digital knowledge work in high-output industries and large organizations, including real estate and leasing, government and public services, manufacturing, professional scientific and technical services, healthcare, finance and insurance, retail and wholesale, information and media, logistics, and operations support. Task roles should cover operations management, asset management, public services, compliance oversight, engineering and manufacturing support, procurement and supply chain, information systems, legal, accounting, project management, healthcare administration, customer service, financial analysis, sales, news editing, audio/video production, and other functions. Each item should require the agent to understand a concrete work scenario, leverage the given information, structured data, communication records, business rules, system exports, public web information, or lightweight tool environments to complete analysis, judgment, computation, planning, coordination, communication, comparison, content production, media processing, or decision support. Task outputs should be concrete deliverables directly usable in a work setting---for example, structured tables, business conclusions, replies to clients or colleagues, process schedules, decision memos, priority judgments, resource-allocation recommendations, calibration notes, updated documents, presentation materials, charts, content drafts, edit lists, subtitle files, media outputs, or audio/video processing results. Generated items should vary substantially across industry, role, objective, information carrier, constraint conditions, collaboration target, time requirements, judgment criteria, and delivery format. DAGENT POST-TRAINING: FINE-TUNING 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 rollouts 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. 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 rate10 −5 , minimum learning rate10 −7 , cosine decay, 5% warmup, and theignoreemptythinkloss scale. The Qwen3.5-35B-A3B runs use theqwen35template and MoE expert parallelism; the Qwen3-32B comparison uses theqwen3template 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 7, which sums visible content, reasoning content, and serialized tool calls before training-framework packing and without chat-template overhead. 16 Table 9: SFT run provenance from training logs. RunStudentTask setTrainValTP/EP/CP/PPTimeCkpt Terminal-2KQwen3.5-35B-A3BTerminal-2K both-use9,198162/8/8/112.2h521 w/o profileQwen3.5-35B-A3BTerminal-2K scenario-only6,539162/8/8/17.4h313 w/o scenarioQwen3.5-35B-A3BTerminal-2K profile-only11,023162/8/8/112.7h541 Qwen3-32B comp.Qwen3-32BTerminal-3.6K17,619162/1/8/46.5d997 EDETAILED EVALUATION RESULTS Table 10 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. Table 11 reports available GDPval Elo confidence intervals behind the scalar values in the main paper. The scoring follows the GDPval-A 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. Table 12 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 (Terminal-Bench Team, 2026; Fan et al., 2026; Pi et al., 2026; Peng et al., 2026; Wu et al., 2026; Cheng et al., 2026; Raoof et al., 2026). E.1PER-TASK OUTCOMES AND PASS@K Beyond mean accuracy, we examine how the four independent runs distribute over individual tasks. Table 13 reports, for the base model and the Terminal-3.6K model, how many of the 89 tasks are solved in0, 1,..., 4of 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. Figure 6 extends this to task-level pass@k, estimating whether at least one ofksampled 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. 17 Table 10: Controlled Terminal-Bench 2.0 pass@1 accuracy statistics. ModelRunsPass Mean 95% CIRange Qwen3.5-35B-A3B Base480/35622.50.9 [21.3, 23.6] Qwen3.5-35B-A3B + Terminal-3.6K4 185/35652.03.6 [48.3, 56.2] Terminal-2K4 156/35643.84.3 [39.3, 49.4] w/o profile4 143/35640.25.0 [33.7, 46.1] w/o scenario4 152/35642.74.2 [37.1, 46.1] Qwen3-32B Base420/3565.60.9[4.4, 7.0] Qwen3-32B + Terminal-3.6K4 115/35632.32.4 [30.3, 36.0] Table 11: GDPval Elo estimates from our internal joint comparison pool. ModelElo95% CI GPT-5.41667 [1639, 1697] Claude Sonnet 4.61633 [1605, 1663] GLM-51408 [1385, 1433] Qwen3.5-35B-A3B + Office-22K 1384 [1358, 1410] Qwen3.5-35B-A3B + Office-2K1338 [1312, 1364] Gemini 3.1 Pro Preview1316 [1291, 1343] MiniMax M2.51202 [1175, 1231] Gemini 3 Flash Preview1191 [1164, 1220] GPT-5.11000 [1000, 1000] Qwen3.5-35B-A3B Base813[787, 840] Table 12: Reference Terminal-Bench 2.0 scores used in the main paper. GroupModelParamsTB 2.0 ExternalGemini 3.1 Pro–80.2± 2.6 DeepSeek-V4-Pro1.6T67.9 Claude Opus 4.6–58.0± 2.9 MiniMax M2.7230B57.0 GPT-5.2–54.0± 2.9 Claude Sonnet 4.6–53.4± 2.8 GLM 5744B52.4± 2.6 Claude Opus 4.5–51.9± 2.9 Gemini 3 Flash–51.7± 3.1 GPT-5.1–47.6± 2.8 Kimi K2.51T43.2± 2.9 MiniMax M2.5230B42.2± 2.6 DeepSeek-V3.2671B39.6± 2.8 Qwen 3 Coder480B23.9± 2.8 Qwen3 BasedLiteCoder-Terminal-32B-SFT32B18.5± 3.4 TerminalTraj-32B32B22.0± 5.8 OpenThinkerAgent-32B32B26.2± 1.6 Nemotron-Terminal-32B32B27.4± 2.4 Qwen3-32B + SkillSynth32B29.6± 1.6 CLI-Universe-32B (DeepSeek)32B31.2 Terminal-World-32B32B31.5 Table 13: Per-task pass-count distribution over four runs. Model0/4 1/4 2/4 3/4 4/4 Base5412887 Qwen3.5 + Terminal-3.6K29881529 18 1234 k attempts 20 40 60 pass@k (%) Ours (NexAU) Qwen3.5 + Terminal-3.6K Qwen3-32B + Terminal-3.6K Qwen3.5 Base Qwen3-32B Base Specialized (published, Terminus-2) Terminal-World-32B Nemotron-Terminal-32B TerminalTraj-32B LiteCoder-Terminal-32B LiteCoder-Terminal-30B-A3B Figure 6: Task-level pass@k on Terminal-Bench 2.0. FTERMINAL 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. Table 14: Primary task type distribution for the terminal ablation (%). VariantLabeled Software Sys. admin Data proc. Terminal-2K200054.311.88.6 w/o profile199778.50.52.7 w/o scenario200024.99.15.5 Table 14 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 14, 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. 19 GTASK-PACKAGE AUDITS FOR AGENT TRAINING DATA QUALITY We audit the synthesized packages along three axes: static integrity, scenario-conditioned filtering, and the realized distribution over task-form dimensions. Table 15 checks that each package contains the expected artifacts and is grounded in real sources; Table 16 reports how aggressively the scenario-conditioned filter narrows the candidate pool before sampling; and Table 17 with Figure 7 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. Table 15: Static synthesis audit. Task groupTasks Scenarios Core files Real src. Terminal-3.6K 3,6003,6003,6002,292 Office-2K2,0002,0002,0001,569 G.1TASK 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. Table 16: Scenario-conditioned compatibility filtering. Task groupType pool→kept File pool→kept Terminal-2K24→4.42167→27.37 Terminal-1.6K18→4.04175→37.78 Office-2K15→6.63105→21.61 20 Table 17: Realized distribution across task-form and material dimensions. DimensionControl roleTerminal-2KOffice-2K Task typePrimary work form24/24; top 27.9%15/15; top 17.3% DeliverableOutput contract8/8; top 19.1%23/23; top 11.9% Source strategyGrounding choice4; GitHub 45.2%4; web 69.2% RuntimeExecution medium20/20; top 22.4%12/12; top 15.7% Info. carrierEvidence form8/8; top 17.1%19/19; top 14.3% Material file typeFile variety167/167; top 3.6%97/105; top 4.6% 54.2% software engineering 11.8% system administration 8.6% data processing 4.1% scientific computing 3.1% systems programming 2.5% performance engineering 2.5% security engineering 2.2% file operations 10.9% Other Terminal-2k required task type 20.6% Data Analysis and Calculation 16.6% Document Review and Verification 14.1% Aggregation and Summarization 10.4% Communication Drafting 10.2% Decision Support and Recommendation 7.0% Comparison and Prioritization 5.4% Planning and Scheduling 4.2% Compliance Mapping and Gap Analysis 11.4% Other Office-2k required task type Terminal-2k 45%14%32%8% Office-2k 9%69%21% source strategy GitHub repoWeb fileGeneratedNo source Figure 7: Task type and source-strategy distributions for Terminal-2K and Office-2K. 21 HSCENARIO RESERVOIR AUDIT We audit scenarios with the same embedding model used by the online novelty filter. All statistics in Table 18 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 (N) 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 N is the share of scenarios whose nearest neighbor inside the same branch belongs to the other target group. Table 18: Branch-level embedding audit for accepted scenarios. BranchScenariosPairNNSilh. Cross N Self-instruct1,868 0.278 0.678 0.1410.16% Knowledge graph1,868 0.314 0.655 0.0713.64% Keyword self-inst.932 0.295 0.625 0.0980.86% Keyword research932 0.310 0.622 0.1130.32% 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. ITASK-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) withtext-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 8 shows the PCA projection, with four visible target–language clusters. 22 PC1 (10.3%) PC2 (8.5%) Terminal / enTerminal / zhOffice / enOffice / zh Figure 8: PCA projection of task description embeddings for Terminal-2K and Office-2K. JSYNTHESIS 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 asname, and the ablation-mode conditionals (guideonly,intentonly) 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/. J.1PLANNING: TASK PROFILE (DIVERSE) This prompt turns a free-form task-set specification into the reviewed task-form profile Φ(I). Carry out task-planning-oriented research based on the user input and organize it into a structured task profile. User input: root_query First research and read relevant material around the user input, covering multiple reliable sources. Prefer broad taxonomies, task collections, label systems, tool/ecosystem catalogs, standards, or domain surveys to build the overall frame, then fill long-tail directions with finer material. Scope the research to the domains, workflows, tools, objects, data forms, common deliverables, and runtime environments the user input naturally points to. The goal is a comprehensive, cleanly structured profile, not a summary and not concrete items. The lists are the reusable candidate space for later generation: cover every candidate with real discriminative value while avoiding semantic overlap within a list. In particular,`task_types` is later sampled by weight for the primary task type, so it must stay same-level, mutually exclusive, and clearly bounded; cross-cutting capabilities, material forms, runtime environments, and delivery forms go in their own fields, and `task_types` keeps only the primary work type. Output requirements: - task_types: mutually exclusive primary work categories, i.e. the single kind of work the solver mainly does in one item. Not a scene, exception, material type, runtime, deliverable, verification, or difficulty source. Each item has name, description, when_applicable, and a positive weight (relative sampling weight in the real distribution, need not be normalized; spread head/mid/tail weights apart). Merge items that usually co-occur. 23 - runtime_environments: runnable, verifiable, interactive environments the task package or Dockerfile must prepare, not a business location. Each item has name, description, tools_or_services, when_applicable (e.g. shell/CLI, Python data analysis, Node/Java/Go/Rust build-test, local web service, database service, browser automation, PDF/OCR, media processing, scientific computing, container tooling, offline document review). - deliverables: abstract deliverable types the solver should ultimately produce. Each has name, description, typical_success_criteria (an internal profile field summarizing the final quality boundary, NOT a solver-facing acceptance/verification procedure). - information_carriers: carrier forms of the input information (not deliverables, not runtimes). Each has name, description, when_needed (e.g. code, logs, config, DB exports, issues, email, screenshots, API docs, contracts, policies, media assets). - material_file_types: a flat list of lowercase suffixes / common format names only (e.g. pdf, csv, xlsx, json, yaml, log, ipynb, pcap). No grouping, no descriptions. - When the input points to command line / terminal / local repo / executable terminal work, task_types and deliverables should favor runnable, editable, testable, reproducible, machine-checkable work and products. - Remove near-synonymous items in each list; keep task_types more restrained and mutually exclusive than the others. Keep abstract categories abstract and file suffixes / tool environments concrete. The final action must call GenerateIntentProfile with output_path= output_path , providing an intent_profile object containing all of: task_types, runtime_environments, deliverables, information_carriers, material_file_types. J.2MINING: 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. Do focused research around the given scene, distilling the task form, runtime environment, required knowledge, usable information carriers, and delivery boundary that fit this item, and produce a research record for blueprint design. Scene input (may contain`item_directive`): seed_scene_json Research focus: - The work the solver must actually do in the scene, its key objects and constraints. - How`item_directive.selected` (task type, runtime, deliverable, source type) shapes the task;`required_task_type` is a high-level direction, so research should clarify what it can concretely become within the original user intent, not shrink it to a fixed parameter or fixed procedure. - How`item_directive.applicable_options` (information carriers, material file types) match the scene. - The domain, tool, and workflow knowledge and the judgment needed to finish the task. - Real resources, data, code, logs, config, docs, pages, tests, or interfaces that help. If difficulty_hours is present, treat it as a lower bound on expert time and look for real complexity, edge cases, and delivery boundaries that support it. Proceed by: (1) understanding the task scene (core need, key objects, constraints, target deliverable); (2) progressive retrieval, splitting more specific queries from prior findings, covering domains, tools, environments, interfaces, data forms, deliverables, and quality boundaries; (3) curating usable resources/assets, each with a concrete name, link, format/type, purpose, and relation to the task, judging whether it is substantial enough to support reasoning, operation, construction, comparison, analysis, decision, delivery, or verification. Produce a research record with four parts: (I) task interpretation; (I) knowledge and information required; (I) execution key points and pitfalls; (IV) usable resources and asset suggestions, marking which are suited to be solver-facing inputs and which to hidden evaluation, environment dependencies, or background. Output natural-language text with accessible links. J.3IDEATION: TASK BLUEPRINT (IDEATE) This prompt turns the directive and mined materials into a single-schema blueprint (ideation.json), preparing real sources viaDownloadSourceFile/PrepareGitHubRepo. A variant (history-to-blueprint) emits the same schema from the recorded research history as an XML-like document. You are a professional task-blueprint designer. Based on the input query, scene research, task profile, and item directive, design a high-quality, high-difficulty, executable task blueprint. 24 Inputs: scene_query ; scene report scene_report ; task profile intent_profile_json ; item directive item_directive_json . Target language: target_language_label . Difficulty: an expert should need at least difficulty_hours hours (a lower bound, not a target to shrink to). Requirements: - Understand what the query wants the solver to do and the real-world scene behind it. Do not merely rewrite the guide into a task description; extract scene, role, objects, boundary conditions, final target state, and material forms, then expand into deep real work within the user-intent boundary. - Choose the task type, runtime, deliverable, source type, and asset form fitting the scene. Runtime means the internal execution environment the package/Dockerfile prepares, not a business location and not a setting to write into the prompt. If `item_directive.selected.required_ * ` fields exist they set the high-level type/deliverable/runtime/source and must be honored; optional_ * are candidates, not an output checklist; default to a single primary task type. - The final task must have one clear primary goal and one primary task type; other types or deliverables only appear as supporting dimensions. Do not stack several medium tasks or independent products to fake difficulty. - The solver environment is a CPU-only, ordinary unprivileged container. Do not plan tasks needing GPU/CUDA/NVIDIA/TPU or host-level daemons, Docker Engine/socket, docker compose, KVM, PID 1 systemd, kernel modules, loop mount, or privileged containers; container/OCI directions become file-level checks/fixes on Dockerfile/Containerfile, manifest, tar, or OCI layout. These execution facts are an internal design constraint and must NOT be written into task_description unless the task object itself is a container/OCI artifact. - Use WebSearch / WebFetch to add background and to look for publicly accessible, appropriately sized real files or GitHub repositories matching the direction. Record the final source choice in`source_selection` (prepared vs to-be-generated assets), referencing canonical tool outputs (remote_rel_path). Source priority: github_repo_adaptation > internet_file_download > generated_files > no_prerequisite_files; use generated files mainly to fill context, fixtures, edge samples, and consistency material, not to replace real data when available. - The initial solver-facing package must contain only real files and directories (no symlinks); do not materialize /proc, /sys, /dev, snapshots, infinite link trees, full .git history, or large vendor/build output. - task_description is a concise, direct, solver-facing statement (goal, background, starting materials or clean-environment contract, constraints, deliverable, paths, final state, external behavior contract). Its first sentence starts from the most distinctive information. Do not prescribe the solver's solution order, planning, debugging route, or verification steps; do not expose hidden tests, reference answers, expected value ranges, scoring details, injected bugs, or a known-root-cause list. Keep local paths relative. - Do not mention internal artifacts (blueprint, ideation, item directive, intent profile, source_selection, prepared/generated assets, manifest, research process, tool names, hidden checks, the generation stage, or "intentionally injected/constructed/simulated" meta-information) in task_description. - Derive difficulty on the spot (hard_topics, difficulty_budget.justification) from the chosen fields, materials, deliverable, sources, and difficulty_hours; do not use a preset difficulty list. After research, source preparation, field design, path/environment checks, and key value/contract self-checks, call GenerateIdeationBlueprint with output_path= output_path (a heavy final tool that regenerates the whole blueprint from the conversation; make small fixes by editing ideation.json directly). Blueprint schema requirements: schema_requirements . J.4GENERATION: TASK MATERIALIZATION (GEN) This prompt writes the solver-facing package (task description, materials, Dockerfile, and internal audit files) from the blueprint, using prepared sources. Synthesize a real task from the task blueprint. You only synthesize; an independent solver will complete it. The blueprint's task_description is a draft to align paths, add detail, and ground materials on. Prepared external files from ideate are used directly. Blueprint: ideation_json . Prepared sources dir prepared_sources_dir and manifest prepared_sources_manifest_path (read it before handling source_selection.prepared_assets). Target language: target_language_label . Generate the Dockerfile at dockerfile_output_path from environment_plan. source_selection handling: prepared_assets are already prepared by ideate; locate them via the manifest (path = remote_rel_path) and copy/trim/extend/extract them into the final package. Source priority github_repo_adaptation > internet_file_download > generated_files > no_prerequisite_files; real sources should be the core material, generated assets only fill context/fixtures/edge samples. Record used assets in generation_summary.json (name, source_type, source_path, copied_to/adapted_to, usage). 25 Solver-facing filesystem constraints: only real ordinary files and directories; no symlink of any kind; do not copy upstream symlinks, /proc, /sys, /dev, virtual filesystems, snapshots, infinite link trees, full .git history, dependency/build caches, or large vendor/build output; trim to the minimal real subset the task needs. Internal execution constraints: CPU-only (no GPU/CUDA/NVIDIA/TPU in tasks, Dockerfile, scripts, tests, or data pipelines; shrink ML/image/video/scientific work to small models, small data, CPU inference/training, or pure-algorithm substitutes). Ordinary unprivileged container (no host daemon, Docker Engine/socket, docker compose, KVM, PID 1 systemd, kernel modules, loop mount, or privileged container; container/OCI work is file-level only). Do not write these execution facts into the task description unless the task object is itself a container/OCI artifact. Landing principles: task_type is a high-level direction, not a fixed script; keep the blueprint intent, source choice, and delivery boundary; deepen one primary goal rather than stacking medium subtasks. The final task_description reads like a concise issue or benchmark instruction (starting materials or clean-environment contract, goal, constraints, deliverable, key interfaces/output schema, final state, external behavior contract); no numbered subtask checklist, no solver solution route, no hidden tests / full verification commands / reference answers / expected value ranges / scoring internals, no known-defect or preset-root-cause list. For fix/recovery/troubleshooting tasks the starting materials may contain failing tests, logs, half-done implementations, or inconsistent data, but only visible symptoms and contracts go into the description. Deliverables: (1) the task description file at task_description_path (relative paths only); (2) reference material files (reuse prepared real sources first, then create real supplementary files that are readable, parseable, and actually used in solving); (3) the Dockerfile at dockerfile_output_path (base_image matches the blueprint, installs declared dependencies, CPU-only, unprivileged-compatible, does not COPY the task files in). generation_summary.json and generation_validation.json are internal audit files at the generation root, never inside the solver package and never referenced by the task description. Workflow: understand the blueprint; read the prepared-sources manifest; land prepared assets, then generated assets and other referenced files; write the Dockerfile; align task_description paths; self-check goal/material/interface consistency and output directory; write generation_validation.json. Finish with a checklist confirming files exist, hard_topics are reflected, materials are real, prepared assets are used and logged, paths are relative and consistent, no leaked internal/execution facts, no symlinks, CPU-only, unprivileged-compatible, and difficulty >= difficulty_hours hours. J.5TEACHER 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. You are an AI agent named ' agent_name ' built on the NexAU framework. You have access to the following tools: % for tool in tools %- tool.name : tool.description % endfor % You can delegate tasks to the following sub-agents: % for sub_agent in sub_agents %- sub_agent.name : sub_agent.description % endfor % Your goal is to help users accomplish their tasks efficiently by: 1. Understanding the user's request 2. Determining if you can handle it with your available tools 3. Delegating to appropriate sub-agents when their specialized capabilities are needed 4. Executing the necessary actions and providing clear, helpful responses You have been working on the task described above but have not yet completed it. Write a continuation summary that will allow you (or another instance of yourself) to resume work efficiently in a future context window where the conversation history will be replaced with this summary. Include: (1) Task Overview -- the core request, success criteria, and constraints; (2) Current State -- what is completed, files created/modified/analyzed with paths, key outputs; (3) Important Discoveries -- technical constraints, decisions and rationale, errors and resolutions, approaches that failed and why; (4) Next Steps -- specific remaining actions, blockers, open questions, priority order; (5) Context to Preserve -- user preferences, non-obvious domain details, promises made. Be concise but complete; err on the side of preventing duplicate work or repeated mistakes. 26

Instant research discovery