Paper deep dive
WorkRover: Scaling Long-Horizon Cowork Agent Training Via Recursive Environment Evolution
Hang He, Linting Wang, Guanming Liu, Bo Mao, Jinxiu Liu, Yiran Suo, Maosen Zhou, Zhiheng Xi, Guanting Dong, Zhou Shao, Rui Zheng, Jie Zhou, Chengcheng Wan, Tao Gui, Qi Zhang, Xipeng Qiu, Xuanjing Huang
Intelligence
Status: not_run | Model: - | Prompt: - | Confidence: 0%
Entities (0)
Relation Signals (0)
No relation signals yet.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Scaling interactive environments is important for training long-horizon agents through reinforcement learning. These environments often require further testing and refinement after initial generation, and correcting defects in a task may also require updating its work context and verifier. However, existing construction pipelines offer limited support for such iterative refinement while keeping these components aligned. We introduce WorkRover, a framework for training long-horizon cowork agents through recursive environment evolution. Its harness-driven synthesis enables construction agents to jointly build and validate semantically aligned work contexts, executable tasks, and evidence-grounded verifiers, adapting their actions to workspace state and execution feedback rather than following a fixed construction workflow. To support environment evolution, we introduce Factorial Compatibility Replay (FCR), which uses rollout feedback to evaluate combinations of component revisions through dependency-closed replay and selects the smallest validated repair among tested candidates while preserving task requirements and evaluation constraints. To provide finer-grained training signals, we propose Verifier-to-Turn Credit Assignment (VTCA), which augments trajectory-level GRPO advantages with signals from deterministic workspace-progress checks and assigns a bounded share of positive-progress credit to prerequisite turns using recorded tool-output and artifact dependencies. Using WorkRover, we post-train Qwen3.5-35B-A3B to obtain WorkRover-35B-A3B and evaluate it on several cowork-agent benchmarks. Its reported scores exceed those of Qwen3.5-35B-A3B by 26.27 percentage points on JobBench, 29.32 percentage points on OfficeQA Pro, and 413.25 Elo points on GDPval v2. These results suggest that WorkRover offers a promising foundation for scalable training of long-horizon cowork agents.
Tags
Links
- Source: https://arxiv.org/abs/2610.18067v1
- Canonical: https://arxiv.org/abs/2610.18067v1
Trouble viewing inline? Open PDF directly →
Full Text
86,217 characters extracted from source content.
Expand or collapse full text
: Scaling Long-Horizon Cowork Agent Training Via Recursive Environment Evolution Hang He ∗ , Linting Wang ∗ , Guanming Liu ∗ , Bo Mao ∗ , Jinxiu Liu ∗ , Yiran Suo ∗ , Maosen Zhou, Zhiheng Xi, Guanting Dong, Zhou Shao # , Rui Zheng, Jie Zhou, Chengcheng Wan, Tao Gui # , Qi Zhang, Xipeng Qiu, Xuanjing Huang ∗ Equal Contribution, # Corresponding Authors Fudan University, East China Normal University, Renmin University of China, Shanghai Qiji Zhifeng Co., Ltd., Shanghai Innovation Institute Abstract Scaling interactive environments has become increasingly important for training long-horizon agents through reinforcement learning. These environments often require further testing and refinement after initial generation, and correcting defects in a task may also require updating its work context and ver- ifier. However, existing construction pipelines offer limited support for such iterative refinement while keeping these components aligned. In this paper, we introduce WorkRover, a framework for training long-horizon cowork agents through recursive environment evolution. Its harness-driven synthesis en- ables construction agents to jointly build and validate semantically aligned work contexts, executable tasks, and evidence-grounded verifiers, adapting their actions to workspace state and execution feedback rather than following a fixed construction workflow. To support environment evolution, we introduce Factorial Compatibility Replay (FCR), which uses rollout feedback to evaluate combinations of component revisions through dependency-closed replay and selects the smallest validated repair among tested can- didates while preserving task requirements and evaluation constraints. To provide finer-grained training signals, we propose Verifier-to-Turn Credit Assignment (VTCA), which augments trajectory-level GRPO advantages with signals from deterministic workspace-progress checks and assigns a bounded share of positive-progress credit to prerequisite turns using recorded tool-output and artifact dependencies. Us- ing WorkRover, we post-train Qwen3.5-35B-A3B to obtain WorkRover-35B-A3B and evaluate it on several cowork-agent benchmarks. Its reported scores exceed those of Qwen3.5-35B-A3B by 26.27 percentage points on JobBench, 29.32 percentage points on OfficeQA Pro, and 413.25 Elo points on GDPval v2. These results suggest that WorkRover offers a promising foundation for scalable training of long-horizon cowork agents. Project Page: https://workrover.github.io/ 36.89 10.62 21.80 38.30 43.40 44.50 54.27 JobBench 1218 805 1069 1396 1396 1418 1572 GDPval 28.67 6.00 9.67 9.90 22.70 26.17 46.67 AutomationBench 74.13 60.50 65.65 72.18 79.57 86.05 92.51 WorkBuddy Bench (Office) 48.87 19.55 44.36 41.40 46.60 57.10 63.30 OfficeQA Pro WorkRover‐35B‐A3BQwen3.5‐35B‐A3BQwen3.6‐27BGPT‐5.5 Claude Opus 4.7GLM‐5.2Kimi K3 36.89 10.62 21.80 38.30 43.40 44.50 54.27 JobBench 1218 805 1069 1396 1396 1418 1572 GDPval 28.67 6.00 9.67 9.90 22.70 26.17 46.67 AutomationBench 74.13 60.50 65.65 72.18 79.57 86.05 92.51 WorkBuddy Bench (Office) 48.87 19.55 44.36 41.40 46.60 57.10 63.30 OfficeQA Pro WorkRover‐35B‐A3BQwen3.5‐35B‐A3BQwen3.6‐27BGPT‐5.5 Claude Opus 4.7GLM‐5.2Kimi K3 36.89 10.62 21.80 38.30 43.40 44.50 54.27 JobBench 1218 805 1069 1396 1396 1418 1572 GDPval 28.67 6.00 9.67 9.90 22.70 26.17 46.67 AutomationBench 74.13 60.50 65.65 72.18 79.57 86.05 92.51 WorkBuddy Bench (Office) 48.87 19.55 44.36 41.40 46.60 57.10 63.30 OfficeQA Pro WorkRover‐35B‐A3BQwen3.5‐35B‐A3BQwen3.6‐27BGPT‐5.5 Claude Opus 4.7GLM‐5.2Kimi K3 36.89 10.62 21.80 38.30 43.40 44.50 54.27 JobBench 1218 805 1069 1396 1396 1418 1572 GDPval 28.67 6.00 9.67 9.90 22.70 26.17 46.67 AutomationBench 74.13 60.50 65.65 72.18 79.57 86.05 92.51 WorkBuddy Bench (Office) 48.87 19.55 44.36 41.40 46.60 57.10 63.30 OfficeQA Pro WorkRover‐35B‐A3BQwen3.5‐35B‐A3BQwen3.6‐27BGPT‐5.5 Claude Opus 4.7GLM‐5.2Kimi K3 36.89 10.62 21.80 38.30 43.40 44.50 54.27 JobBench 1218 805 1069 1396 1396 1418 1572 GDPval 28.67 6.00 9.67 9.90 22.70 26.17 46.67 AutomationBench 74.13 60.50 65.65 72.18 79.57 86.05 92.51 WorkBuddy Bench (Office) 48.87 19.55 44.36 41.40 46.60 57.10 63.30 OfficeQA Pro WorkRover‐35B‐A3BQwen3.5‐35B‐A3BQwen3.6‐27BGPT‐5.5 Claude Opus 4.7GLM‐5.2Kimi K3 36.89 10.62 21.80 38.30 43.40 44.50 54.27 JobBench 1218 805 1069 1396 1396 1418 1572 GDPval 28.67 6.00 9.67 9.90 22.70 26.17 46.67 AutomationBench 74.13 60.50 65.65 72.18 79.57 86.05 92.51 WorkBuddy Bench (Office) 48.87 19.55 44.36 41.40 46.60 57.10 63.30 OfficeQA Pro WorkRover‐35B‐A3BQwen3.5‐35B‐A3BQwen3.6‐27BGPT‐5.5 Claude Opus 4.7GLM‐5.2Kimi K3 36.89 10.62 21.80 38.30 43.40 44.50 54.27 JobBench 1218 805 1069 1396 1396 1418 1572 GDPval 28.67 6.00 9.67 9.90 22.70 26.17 46.67 AutomationBench 74.13 60.50 65.65 72.18 79.57 86.05 92.51 WorkBuddy Bench (Office) 48.87 19.55 44.36 41.40 46.60 57.10 63.30 OfficeQA Pro WorkRover‐35B‐A3BQwen3.5‐35B‐A3BQwen3.6‐27BGPT‐5.5 Claude Opus 4.7GLM‐5.2Kimi K3 36.89 10.62 21.80 38.30 43.40 44.50 54.27 JobBench 1218 805 1069 1396 1396 1418 1572 GDPval 28.67 6.00 9.67 9.90 22.70 26.17 46.67 AutomationBench 74.13 60.50 65.65 72.18 79.57 86.05 92.51 WorkBuddy Bench (Office) 48.87 19.55 44.36 41.40 46.60 57.10 63.30 OfficeQA Pro WorkRover‐35B‐A3BQwen3.5‐35B‐A3BQwen3.6‐27BGPT‐5.5 Claude Opus 4.7GLM‐5.2Kimi K3 36.89 10.62 21.80 38.30 43.40 44.50 54.27 JobBench 1218 805 1069 1396 1396 1418 1572 GDPval 28.67 6.00 9.67 9.90 22.70 26.17 46.67 AutomationBench 74.13 60.50 65.65 72.18 79.57 86.05 92.51 WorkBuddy Bench (Office) 48.87 19.55 44.36 41.40 46.60 57.10 63.30 OfficeQA Pro WorkRover‐35B‐A3BQwen3.5‐35B‐A3BQwen3.6‐27BGPT‐5.5 Claude Opus 4.7GLM‐5.2Kimi K3 Figure 1 Cross-benchmark performance. Results on five cowork-agent benchmarks. 1 arXiv:2610.18067v1 [cs.AI] 13 Oct 2026 1 Introduction Cowork agents powered by large language models (LLMs) perform professional tasks across files, tools, and applications [15]. These tasks unfold over long sequences of dependent actions, requiring agents to locate relevant materials [17, 31, 37], track workspace changes, and maintain consistency across related artifacts [3, 20, 32, 33]. Training these agents through reinforcement learning (RL) depends on environments that support diverse, executable workflows and provide reliable feedback on task outcomes [5, 10, 11, 26, 41, 45, 49]. Recent work has explored automated environment and task synthesis to expand the range of workspaces and tasks available for agent training [2, 18, 30]. However, expanding the number of synthesized environments does not by itself ensure reliable training feed- back. In a cowork environment, the work context must support the task’s requirements, and the verifier must assess the requested outcomes while accepting valid alternative solutions. Agent rollouts can expose missing dependencies, inconsistent task specifications, or verification errors that remain after initial construction [47]. Such defects can make valid behavior appear unsuccessful or allow incorrect results to be rewarded. Repair- ing these defects often requires coordinated revisions within a task environment: a correction to the work context or task specification may also require updating the verifier to keep execution and evaluation aligned. Existing construction pipelines offer limited support for maintaining this alignment throughout repeated revisions. This motivates recursive environment evolution: repeatedly using execution feedback to identify defects, coordinate component revisions, and revalidate the revised environment while preserving the original task requirements and evaluation constraints. Reliable terminal evaluation also leaves a credit-assignment challenge: useful steps can occur in failed trajectories and redundant actions in successful ones, while earlier information-gathering turns may only contribute through later workspace changes [6, 34]. To this end, we introduce WorkRover, a framework for long-horizon cowork agent training that integrates harness-driven environment synthesis, recursive environment evolution, and verifier-grounded policy learning (Figure 2(b)). Its harness tracks component dependencies and enables construction agents to jointly build and validate semantically aligned work contexts, executable tasks, and evidence-grounded verifiers. These agents adapt their construction actions to workspace state and execution feedback rather than following a fixed workflow. Independent reference executions from a clean initial workspace establish task feasibility, while verifier validation tests incorrect outcomes and valid alternatives against instruction-grounded requirements rather than a prescribed solution path. For environment evolution, we introduce Factorial Compatibility Replay (FCR), which evaluates combinations of fixed repair proposals across the work context, task, harness, and verifier. Each combination is rebuilt with its dependency-induced updates and tested under matched rollout conditions. FCR selects the smallest validated repair among the tested combinations, subject to preserving task requirements and evaluation constraints and passing regression checks on affected tasks. Fresh rollouts confirm selected repairs and provide evidence for subsequent evolution. For policy learning, we introduce Verifier-to-Turn Credit Assignment (VTCA) to supplement trajectory-level GRPO advantages with finer-grained feedback. Frozen deterministic checks measure progress and setbacks in recorded workspace states, while tool-output and artifact dependencies identify prerequisite turns eligible for a bounded share of positive-progress credit. This provides turn-level learning signals without intermediate judge calls. We post-train Qwen3.5-35B-A3B with WorkRover and evaluate the resulting model on five external bench- marks spanning occupational tasks, professional deliverables, cross-application workflows, and document- grounded reasoning. WorkRover-35B-A3B exceeds the reported backbone scores on all five benchmarks, with gains of 26.27 percentage points on JobBench, 29.32 percentage points on OfficeQA Pro, and 413.25 Elo points on GDPval v2. Controlled experiments further examine the contributions of environment evolution and verifier-grounded learning. Under matched repair budget caps, FCR improves task-package synthesis pass rate by 6.0 percentage points over full regeneration. A separate maintenance evaluation shows that FCR also resolves naturally occurring defects more reliably while reducing unintended changes to task intent. Construction ablations also show that following file dependencies and matching files with compatible skills improve task yield and executability, beyond assembling workspaces through topical similarity alone. With the supervised fine-tuning (SFT) initialization, task and seed schedules, and rollout budget fixed, VTCA out- performs episode-only GRPO across all five benchmarks. These findings support improving both environment reliability and turn-level learning signals for long-horizon cowork agent training. 2 (a) Challenges(b) 1 Scaling Harness-driven adaptive joint synthesis 2 EvolvingFCR (Factorial Compatibility Replay) 3 Training VTCA (Verifier-to-Turn Credit Assignment) Components can misalign CTV Missing inputs and ungrounded checks. C Work Context Files, skills, and apps Resettable state T Long-horizon Task Goals and deliverables Clean-state demo V Verifier Contract and evidence Executable checks Check dependenciesDemonstrate feasibilityCalibrate verifier Local edits break bindings CTHʹV Harnessedit One fix can regress shared tasks. Diagnose Confirmed mismatch vs policy-onlyfailure Freeze One Δper factor Fixed intent & eval rules Replay 2ᵈ Dependency-closed Matched trials Select Smallest validated repair among tested candidates Fresh-seed confirmation → Promote / retain parent → New rollouts ↺ Sparse, delayed feedback FindDraftFailReward 0 Useful prerequisites get no credit. Trajectory reward Verifier & Trace Frozen checks Signed Δφon states Verified links Bounded positive credit ! 푨 풕 =푨 풕풓풂풋 +휶푯휹 풕 −휼풄 풕 ContextTaskVerifier ΔCΔTΔHΔV Group normalizationR → A traj Negative stays local to prerequisites H: hard-constraint gate δₜ: allocated progress cₜ: local trace cost ∆T∆H∆V Figure 2 Cowork agents: challenges and approaches. Our main contributions are: 1. Harness-driven construction of semantically aligned environments. We introduce a Harness-driven syn- thesis pipeline that jointly constructs semantically aligned work contexts, executable tasks, and evidence- grounded verifiers at scale. The Harness explicitly tracks their dependencies and validates task feasibility and verifier consistency. 2. Recursive environment evolution. We introduce Factorial Compatibility Replay (FCR) to support iter- ative environment repair under explicit component dependencies. FCR evaluates coordinated revisions, identifies minimal validated repairs, and propagates changes across affected components while preserving task intent and evaluation constraints. 3. Training from verifier-grounded progress. We introduce Verifier-to-Turn Credit Assignment (VTCA) to augment terminal-reward GRPO with workspace-grounded advantage shaping. Deterministic checks provide progress proxies, with bounded positive allocations to prerequisite turns through recorded tool and artifact dependencies, without intermediate Judge calls. 2 Related Work Executable environments and verification. Prior work scales executable environments [2, 7, 30, 36, 40] and validated task synthesis [4, 12, 18, 22]. Shared specifications and state help align tasks and verifiers [13, 29], while adversarial audits test verifier reliability [47]. WorkRover jointly constructs Work Contexts, Tasks, and Verifiers, tracking their dependencies under a versioned Harness. Environment evolution and repair. Recent work studies task-bundle revision and execution-driven environ- ment repair [10, 23, 39]. Program repair also studies patch minimization [38]. FCR replays combinations of fixed repair proposals, including dependency-induced changes. It selects the smallest validated repair among those tested, preserving task requirements and evaluation constraints and checking affected tasks for regressions. Long-horizon learning and progress attribution. Local credit assignment draws on state comparisons and planning hierarchies [8, 24], progress estimates, or evidence attribution [9, 34, 42–44, 46]. VTCA shapes GRPO advantages [27] with frozen checks of workspace progress and setbacks. It assigns a bounded share 3 PhaseII: Long-HorizonTaskSynthesis Capability Packages Tools MCP Reference Script Exact Profiled File Instances Filter & Map GeneralFiles (100k+) Domain Files (200k+) PhaseI: WorkContextConstruction ç√ Project repositories Documents & artifacts DeepResearchtrajectories (a) Filesystem Construction (b) Capability Library Construction PhaseIII: Verifier Synthesis and Validation Context-GroundedTask Synthesis ØEdit Scope (# Files) ØRollout Length (#Turns) Admitted Package푷 풊 Task Instruction Starter WorkEnv Reference State Rubric Evidence Rubric-Guided Verification &Admission Rewriter Layered Verifier푽 풊 Infrastructure Validity Canonical State Diff Functional Checks Semantic Judge Evidence Bindings Pass/Fail/Invalid Evaluation Contract ExpectedOutcomes AllowedEdits Protected State Critical Criteria EvidenceBindings Pass? Y N Calibration mismatch FilePool (c) App Environment Construction ç√ Installed skills Plugins ç√ Mock applications Installed applications Executable App WorkEnvs UI-Observe Runtime ResetInterface Instru- ment SemanticsRelations EditableType App Pool CapabilityPool Notes Sources App WorkEnvs (2k+) ExtensionConnectorAdd-on Skill Matcher AtomicContext & Instance Profiling WorkEnv Assembly Semantics & Relations& Executability Task Candidate푻 풊 Task Instruction Starter WorkEnv Reference State Compose coherent files, apps& resources Job Skills Fit task scope to WorkEnv App Skills File Skills FilesApps FileContext CapabilityContext App Context Harness-Driven ExecutionH(Phase I--I) Accepted Traces흉 풊 ... s 1 s t s 0 AgentRuntime MemoryPlannerToolsContext Multi-turn Interaction ퟐ 풅 ClosedReplay 훤휒=퐶푙표푠푒(,) FrozenProposals ΔC/ΔT/ΔH/ΔV SmallestSafe흌 ∗ Min versions · Closure RolloutEvidence Mismatch Verifier Validation TestCases Starter Reference NegativeCases ValidAlternatives Recalibrate Reject Cowork Agent Work Context Action Observation (§ 3.1.1) (§ 3.1.2) (§ 3.1.3) Rollout‐driven Recursive Evolution (Factorial Compatibility Replay, FCR) (§ 3.2) Task‐construction profile Skill Complexity WorkEnv Noise Ratio Cross‐Env Dependency App skills (21k+) File skills (5k+) Job skills (36k+) Figure 3 Environment construction and recursive evolution in WorkRover. The Harness coordinates Work Context construction, Task synthesis, and Verifier synthesis and validation. FCR repairs compatibility mismatches under frozen safety gates; verified trajectories support policy learning. of positive credit to prerequisite turns using recorded tool-output and artifact-version dependencies, without intermediate Judge calls. Checker coverage [48] and dependency quality limit these signals. See Appendix A. 3 Method In this section, we present WorkRover (Figure 3), a framework for training long-horizon cowork agents through recursive environment evolution. We first introduce harness-driven synthesis of semantically aligned work contexts, tasks, and verifiers (Sec. 3.1). We then present Factorial Compatibility Replay (FCR) for rollout-driven recursive evolution (Sec. 3.2) and Verifier-to-Turn Credit Assignment (VTCA) (Sec. 3.3). 3.1 Harness-Driven Environment Synthesis We organize the training environments into N task packages: L =P i =⟨C i ,T i ,V i ⟩ N i=1 . The Work Context C i provides files, capabilities, and application environments; the Task T i specifies goals, deliverables, and constraints; and the Verifier V i checks task completion. The Harness H coordinates con- struction, tracks dependencies, and manages execution across the three phases in Figure 3. 3.1.1 Work Context Construction Phase I constructs a reusable Work Context C i comprising File Context C file i , Capability Context C cap i , and App Context C app i . We collect files from project repositories and DeepResearch trajectories, along with documents and artifacts. After filtering, we profile their semantics, cross-file relations, type, and editability to form general-purpose and domain-specific collections. We package installed skills and plugins with their MCP interfaces, tools, scripts, and references. These packages form job, file, and app skill libraries. We 4 instrument mock and installed applications to create executable App WorkEnvs with a runtime, UI observa- tion, interaction interfaces, and reset support. Together, these resources supply the three Contexts used for WorkEnv assembly and task synthesis in Phase I. Figure 4 summarizes skill-library coverage. Appendix B.1 provides construction details and complexity analysis; Appendix B.2 reports resource coverage. Figure 4 Skill-library coverage. Six largest cat- egories; others aggregated. Tile sizes show shares of skills (a, c) or category memberships (b). 3.1.2 Long-Horizon Task Synthesis Phase I synthesizes task T i from the three Contexts in C i (Figure 3). A construction profile sets the target edit scope (files), interaction horizon (turns), skill complexity (number and types of combined skills), distractor ratio, and cross-environment dependencies (Table 4; Appendix B.4). We profile selected file and app instances for task-relevant semantics, relations, and executability. The Harness H then assembles compatible files, apps, and capabilities into a WorkEnv. Starting from a job skill, the Skill Matcher fits the task scope to the WorkEnv’s available resources and combines job, file, and app skills into an internal workflow whose stages depend on earlier outputs or state changes. Its dependency graph guides preparation of the Starter WorkEnv x v i , including all required resources and marking editable and protected state. Task instructions specify goals, materials, deliverables, and constraints. An independent Demonstrator Agent executes the task from x v i ; success confirms feasibility and yields a Reference State x ⋆ i . The Task Instruction, Starter WorkEnv, and Reference State form the candidate, with state differences providing evidence of completion. The workflow and reference execution must not add requirements or exclude other valid solutions. We remove inputs to test dependency necessity; independently confirmed compatibility problems trigger FCR (Section 3.2). Candidates passing construction checks proceed to Phase I for Verifier synthesis and validation. 3.1.3 Verifier Synthesis and Validation Phase I synthesizes and validates the Verifier V i (Figure 3). We derive an Evaluation Contract from the task instructions and agent-visible workspace conditions, fixing its criteria before inspecting the Reference State. The Contract specifies expected outcomes, allowed edits, protected state, critical criteria, and admissible evidence. We use it to generate a rubric and verification rules, binding each criterion to evidence from files, application states, or state differences. Infrastructure Validity returns invalid when infrastructure faults prevent evaluation; Canonical State Diff checks state changes against the Contract; Functional Checks test artifact content and consistency; and Semantic Judge assesses criteria unresolved by executable checks. Valid evaluations pass only if the weighted outcome score meets its threshold and all mandatory checks pass; otherwise they fail. We calibrate V i to reject the Starter State and negative cases that violate the Contract, while accepting the Reference State and independently obtained valid alternatives. Independently confirmed compatibility problems may trigger FCR, followed by recalibration under the same fixed Contract. We then freeze V i for a separate, one-time admission test; candidates that fail are rejected without feedback for further repair. Passing candidates become admitted packages P i containing the Task Instruction, Starter WorkEnv, Reference State, rubric, and evidence, with accepted execution traces τ i retained for training. See Appendix C.1 for scoring and validation details. 3.2 Recursive Environment Evolution The Work Context, Task, Harness, and Verifier must work together for a task to run and be evaluated correctly. Factorial Compatibility Replay (FCR) repairs mismatches revealed during construction or later 5 agent rollouts. Since changing one component can affect the others, FCR tests proposed changes both individually and jointly, then selects the smallest validated repair that preserves the task’s original intent. Diagnosis and proposals. Independent diagnostics first distinguish environment problems from mistakes in the agent’s decisions. Agent mistakes alone do not trigger environment changes. For an environment problem, the Harness records the affected versions and dependencies, keeps task requirements and validation checks fixed, and freezes one proposed repair per eligible component: ∆C, ∆T, ∆H, and ∆V as applicable. The Evaluation Contract remains fixed once grounded in the task requirements. Edits visible to the agent must preserve information boundaries, including keeping hidden evaluation evidence hidden. These edits must also pass checks by a fixed panel of solvers for unintended task simplification. Harness screening and replay. For d≤ 4 eligible components, each combination χ∈0, 1 d specifies which proposals to apply: 1 applies a proposal and 0 omits it. This gives 2 d combinations, at most 16. Before rebuild- ing packages or running rollouts, the Harness removes combinations with confirmed conflicts in dependencies, resource bindings, or requirements; uncertain cases proceed to validation. Each remaining combination is expanded into a dependency-closed update set Γ(χ) = Close(χ). This set includes the selected repairs and all additional updates needed to keep dependent components compatible, even if those components were not directly selected for repair. The rebuilt packages are then replayed with the same agent policies, execution budgets, and random seeds. Comparing individual and joint repairs reveals whether some changes work only when applied together. If only the Verifier changes, all alternatives evaluate the same recorded evidence. Repair selection. Independent checks must confirm that the original problem is resolved, required outcomes and information boundaries are preserved, and the repair introduces no new problems in affected task pack- ages. These checks do not use agent success or scores from the proposed Verifier as evidence of resolution. Once a Verifier exists, the repair must also pass the fixed Contract checks and tests confirming that the Verifier rejects known failures and accepts valid alternative solutions. Among the tested repair combinations that pass these checks, FCR selects χ ⋆ whose full update set Γ(χ ⋆ ) changes the fewest component versions, counting updates required by dependencies. Ties favor fewer rebuilt dependencies, then lower cost. Confirmation and update. Fresh rollouts with new random seeds confirm the selected repair. A candidate that has not yet been admitted to the training collection repeats validation from the earliest affected construc- tion step and must pass initial admission. For an already admitted package, all validated changes take effect together after confirmation. If repair selection or confirmation fails, FCR discards an unadmitted candidate or keeps the previous admitted version. Later rollouts can reveal new mismatches and initiate another repair cycle. See Appendices C.2 and C.3 for details. 3.3 Verifier-to-Turn Credit Assignment Terminal rewards score an entire rollout but provide little guidance about which turns made progress. VTCA adds feedback from verified workspace changes and recorded dependencies (Figure 5). Trajectory supervision. We initialize the policy with verified demonstrations using SFT, then sample RL rollouts for the same task and initial state. Among rollouts with valid evaluations, terminal rewards combine Verifier outcome scores and trace scores. Rewards are zero if any critical criterion or integrity, protected-state, or safety check fails. We standardize rewards within each group to obtain the trajectory advantage A traj i,r for task i and rollout r. Measuring progress. Frozen deterministic checks [34] score supported criteria before and after each turn. We subtract the earlier score from the later one, so increases indicate progress and decreases regression. If either score is unavailable, we emit no local signal. Missing observations are never treated as zero completion. Checks run on recorded states without intermediate Judge calls. 6 RolloutSamplingTerminal Evaluation 푡 ! !"# t 0 t 1 t ... 흉 풊,ퟏ 흉 풊,풓 푡 ! !"# t 0 t 1 t ... 흉 풊,푴 풊 푡 ! !"# t 0 t 1 t ... (푻 풊 ,풙 풗 풊 ) 푴 풊 ≥ퟐ AgentTurn Trajectory advantage 흅 휽 풐풍풅 Same task + initial workspace state.One Verifier pass per trajectory. Verifier-to-Turn Credit Assignment t 0 t 1 t 2 푡 ! !"# t 3 ... Turn-level tracecost 푯 휹 ퟎ 푯 휹 ퟏ 푯 휹 ퟐ 푯 휹 ퟑ ... 푯 휹 푻 풓#ퟏ Progress Shaping Trajectory r has T r agent turns. 0000 c 2 ... H=0 : Progress shaping disabled. ❸ ShapedAdvantageandPolicyUpdate UpdatePolicy 흅 휽 푨 풕풓풂풋 ... 푨 풕풓풂풋 푨 풕풓풂풋 푨 풕풓풂풋 푨 풕풓풂풋 ❶ ❷ 푽 풊 Gate푮 풓 ProcessScore 푺 푨,풓 Criterion Scores 풑 풓,풌 휺 풓 OutcomeScore:푺 푩,풓 =* 풌 +풘 풊,풌 풑 풓,풌 Reward:푹 풓 =푮 풓 ퟏ−흀푺 푩,풓 +흀푺 푨,풓 ❹ ' 퐴 (,),* =푠푔푨 풊,풓 풕풓풂풋 +휶푯 풊,풓 휹 풊,풓,풕 풄풓풊풕 −휼풄 풊,풓,풕 Trajectory-level advantageProgressshaping Turn-leveltrace cost Turn-BalancedGRPO Token→Turn→Rollout 흅 )*+ =흅 ,-. next：휽 풐풍풅 ←휽 maximize퓙 푽푻푪푨 (휽) maximize Figure 5 Overview of VTCA. Same-task rollouts yield terminal rewards and checked progress. Bounded prerequisite allocations and local trace costs shape turn-balanced GRPO advantages. Assigning turn credit. At least half of each positive increment stays with the turn that produced it. The rest is divided equally among earlier turns whose tool outputs or exact artifact versions were directly used to produce that progress, as confirmed by recorded dependencies. For example, a turn that reads a table may share credit when a later turn uses that returned table to compute a checked result. Merely opening a file does not qualify. If no earlier turn qualifies, all credit stays local. Negative increments remain entirely with the turn that produced them. Policy update. We combine these allocations using normalized criterion weights ̄w i,k to obtain criterion- based credit δ crit i,r,t for turn t. We add this credit to the trajectory advantage and subtract a local trace cost c i,r,t for tool errors or unproductive repetition: b A i,r,t = sg h A traj i,r + αH i,r δ crit i,r,t − ηc i,r,t i , α,η ≥ 0,(1) Here α and η weight progress credit and local trace cost, and sg stops gradients. The gate H i,r is 1 only when integrity, protected-state, and safety checks pass. An unfinished rollout can retain progress credit, while violations disable it for every turn. Clipped GRPO [27] averages token contributions within each turn, then turns within each trajectory, so lengthy turns do not dominate the update. Setting α = η = 0 recovers our episode-only baseline. The reliability of this shaping signal depends on checker coverage and dependency records (Appendix C.4). 4 Experiments 4.1 Experimental Setup Model and training data. We post-train Qwen3.5-35B-A3B [25] to obtain WorkRover-35B-A3B. Super- vised fine-tuning (SFT) uses 30,115 trajectories generated by Qwen3.5-397B-A17B in synthesized workspaces; all pass task verification and quality checks. For reinforcement learning (RL), we independently synthesize 20,000 task–Verifier pairs and screen each pair with four Qwen3.5-35B-A3B pilot rollouts. Consistency filter- ing retains 3,200 pairs for training. Starting from the SFT checkpoint, the model collects online rollouts on these tasks and learns with VTCA-GRPO (Sec. 3.3). Subset-selection details are in Appendix D.1. Evaluation. We evaluate transfer to five external benchmarks: JobBench [16] for occupational tasks, GDP- val [1] for professional deliverables, AutomationBench [28] for cross-application workflows, WorkBuddy Bench (Office) [35] for office workflows, and OfficeQA Pro [21] for document-grounded question answering. We use 7 Table 1 Benchmark results. Bold and underlinedmark the best and second-best scores per model group. Subscripts show changes from Qwen3.5-35B-A3B:↑ increases and↓ decreases (Elo or percentage points). Higher scores are better. Details in Appendix D.1. Model JobBench (%) ↑ GDPval (Elo) ↑ Automation Bench (%) ↑ WorkBuddy Bench (Office) (%) ↑ OfficeQA Pro (%) ↑ Proprietary Models GPT-5.538.30 ↑27.68 1395.85 ↑591.10 22.70 ↑16.70 86.05 ↑25.55 57.10 ↑37.55 Claude Opus 4.744.50 ↑33.88 1395.78 ↑591.03 9.90 ↑3.90 92.51 ↑32.01 46.60 ↑27.05 Gemini 3.1 Pro Preview15.90 ↑5.28 903.94 ↑99.19 37.54 ↑31.54 –39.10 ↑19.55 Open-Weight Models (>400B total parameters) Kimi K3 54.27 ↑43.65 1572.42 ↑767.67 46.67 ↑40.67 72.18 ↑11.68 63.30 ↑43.75 DeepSeek-V4-Pro54.10 ↑43.48 1493.31 ↑688.56 31.80 ↑25.80 78.71 ↑18.21 65.40 ↑45.85 GLM-5.243.40 ↑32.78 1417.62 ↑612.87 26.17 ↑20.17 79.57 ↑19.07 41.40 ↑21.85 MiniMax-M3–1303.96 ↑499.21 15.90 ↑9.90 76.30 ↑15.80 45.10 ↑25.55 Open-Weight Models (27–35B total parameters) Qwen3.6-27B21.80 ↑11.18 1068.87 ↑264.12 9.67 ↑3.67 65.65 ↑5.15 44.36 ↑24.81 Granite-4.2-30B1.64 ↓8.98 721.01 ↓83.74 0.02 ↓5.98 54.18 ↓6.32 12.03 ↓7.52 Muse-Glimmer-30B11.82 ↑1.20 892.72 ↑87.97 6.83 ↑0.83 57.45 ↓3.05 24.06 ↑4.51 Nex-N2-mini3.82 ↓6.80 1097.03 ↑292.28 5.70 ↓0.30 25.87 ↓34.63 26.32 ↑6.77 Occamy-1.034.27 ↑23.65 1128.00 ↑323.25 27.60 ↑21.60 66.65 ↑6.15 48.10 ↑28.55 Qwen3.5-35B-A3B10.62804.756.0060.5019.55 WorkRover-35B-A3B (Ours) 36.89 ↑26.27 1218.00 ↑413.25 28.67 ↑22.67 74.13 ↑13.63 48.87 ↑29.32 each benchmark’s official evaluator and aggregate metric, reporting GDPval in Elo and the other four scores as percentages. Table 1 compares WorkRover with its backbone, other 27–35B open-weight models, open- weight models above 400B, and proprietary models. Published reference scores retain their original task subsets, evaluators, and harnesses. Our training and evaluation setup is described in Appendix D.1. 4.2 Main Results WorkRover-35B-A3B improves on its Qwen3.5-35B-A3B backbone across all five external benchmarks (Ta- ble 1). Among the percentage-based scores, the largest gains are on OfficeQA Pro (+29.32 percentage points) and JobBench (+26.27 points), followed by AutomationBench (+22.67 points) and WorkBuddy Bench (Of- fice) (+13.63 points). GDPval v2 increases from 804.75 to 1218.00 Elo, a gain of 413.25. These improvements span document reasoning, occupational tasks, professional deliverables, and application workflows, supporting transfer beyond the synthesized training workspaces. Among the listed 27–35B open-weight models, WorkRover has the highest reported score on every bench- mark. Occamy-1.0 has the second-highest reported score in this group on each benchmark. The largest percentage-point gap between the two models is on WorkBuddy Bench (Office): 74.13% versus 66.65%, a margin of 7.48 points. The JobBench margin is 2.62 points (36.89% versus 34.27%), while the leads on AutomationBench and OfficeQA Pro are smaller, at 1.07 and 0.77 points, respectively. Compared with larger and proprietary models, WorkRover’s relative performance varies across benchmarks. It exceeds GLM-5.2 and MiniMax-M3 on both AutomationBench and OfficeQA Pro, and Kimi K3 on Work- Buddy Bench (Office) (74.13% versus 72.18%). Gaps remain on occupational work and deliverable quality: its JobBench score of 36.89% is below GPT-5.5 (38.30%) and Kimi K3 (54.27%), and its GDPval score of 1218.00 Elo is below all listed open-weight models above 400B (1303.96–1572.42 Elo). WorkBuddy perfor- mance also remains below GPT-5.5 (86.05%) and Claude Opus 4.7 (92.51%). Comparisons with reference models use their reported scores under source-specific evaluation settings. 4.3 Ablations and Analysis 8 4.3.1 Verifier-to-Turn Credit Assignment With the SFT checkpoint, task and seed schedules, and rollout budget fixed, we compare VTCA with episode- only GRPO (E-GRPO; Figure 6). Both RL methods improve on SFT across all five benchmarks. VTCA further outperforms E-GRPO on every benchmark. The largest percentage-point gains are on Automation- Bench (+5.7) and OfficeQA Pro (+5.4), while GDPval v2 improves by 43 Elo. These results support giving individual turns feedback beyond the final trajectory outcome. Protocol and component controls are in Appendices D.2 and C.4. Score (%) 0 10 20 30 40 10.6 25.0 19.0 33.5 36.9 Δ +3.4 JobBench Elo 0 400 800 1200 1600 805 1060 960 1175 1218 Δ +43 Elo GDPval v2 Score (%) 0 5 10 15 20 25 30 35 6.0 15.5 11.5 23.0 28.7 Δ +5.7 AutomationBench Score (%) 0 20 40 60 80 60.5 68.0 65.0 71.5 74.1 Δ +2.6 WorkBuddy (Office) Score (%) 0 10 20 30 40 50 60 19.6 34.0 28.0 43.5 48.9 Δ +5.4 OfficeQA Pro BackboneSFTBackbone + E-GRPOSFT + E-GRPOSFT + VTCA Figure 6 35B-A3B comparison under matched rollout budgets. Backbone denotes Qwen3.5-35B-A3B before our SFT or RL. Gains compare SFT + VTCA with SFT + E-GRPO. GDPval v2 uses Elo; other scores are percent- ages. 4.3.2 Recursive Environment Evolution We compare repair methods using Qwen3.5-35B-A3B under matched proposal and replay budget caps. Safe Resolution Rate (SRR) measures how often a defect is fixed without causing new failures in related tasks; repairs must also pass fresh-seed confirmation and a held-out audit. FCR raises SRR on naturally occurring defects from 60.7% with full regeneration to 70.3% (Figure 7(b)). It also reduces changes to task intent from 14.3% to 1.3% while using fewer model tokens (relative cost: 1.00 versus 1.34). Choosing compatible edits. With repair proposals fixed, Table 2 tests selection separately from proposal generation. Compared with applying all edits (Apply-all), FCR raises SRR by 9.0 percentage points on natural defects and 10.4 points on injected defects, and reduces cross-task regression from 7.0% to 0.7%. Testing edit combinations thus improves repair reliability, at a higher model-token cost (1.00 versus 0.59). Joint repair and repeated evolution. With proposals fixed, 48–74% of safely resolved cases require joint edits, depending on the component pair: no smaller subset of the selected edits passes the same repair checks (Figure 7(a)). Across three generations, SRR stays at 70.3–72.4% and audit pass rate at 93.8–94.6% (panel c), showing little change in repair quality across these rounds. FCR’s task success rate also increases over five repair iterations (panel d). Repairing initial candidates. FCR also improves initial construction. With the candidate set and repair budget caps fixed, synthesis pass rate reaches 74.8%, compared with 49.8% before repair and 68.8% with full regeneration. Repair therefore recovers more tasks that pass validation from the same initial pool. 4.3.3 Construction Pipeline We remove one construction component at a time (Table 3). Task yield measures the fraction of initial candidates that pass validation. The largest drops come from removing relation-aware expansion (74.8% to 52.6%) or validation-guided rewriting (74.8% to 49.8%). These results highlight the value of following file dependencies and repairing construction errors. Reference execution and agent success decline as well. Removing relation-aware expansion lowers them from 95.1% and 58.7% to 77.9% and 41.8%, respectively. Removing file–skill grounding also reduces both measures, 9 CTCHCVTHTVHV 0 0.5 1 Joint necessity Frozen proposals 0.64 0.71 0.48 0.67 0.55 0.74 ParentLocalSeqRegenFCR 0 0.5 1 Fraction of triggers 3.0 39.3 55.0 60.7 70.3 Safe resolutionNot safely resolved 123 Construction generation 60 80 100 Rate (%) 70.3 72.4 71.8 93.8 94.6 94.2 SRRAudit Pass 012345 Repair iteration 20 40 60 80 Rollout success (%) FCRGreedyLocalRegen (a) Joint revision necessity(b) Safe repair outcomes(c) Repair reliability across generations (d) Task success across repair iterations Figure 7 FCR mechanism, stability, and evolution. (a) Pairwise joint necessity (C: Context; T: Task; H: Harness; V: Verifier). (b) Natural-trigger outcomes. (c) Repair reliability across three generations, measured by SRR and sealed-audit pass rate. (d) Task success across five repair iterations. supporting the need to match each file with operations that can use it. The semantic-only baseline performs worse on all three measures, suggesting that topical similarity alone is insufficient for assembling executable workspaces. Success rates use the same frozen agent but are measured on each variant’s retained workspaces, so they can also reflect differences in which tasks are admitted. Table 2 Maintenance with shared frozen proposals. Matched budget caps; rates (%); model-token cost rela- tive to FCR. Table 3 Construction ablations (%). Mean ± workspace- clustered 95% interval half-width. Method Natural SRR↑ Controlled SRR↑ Task reg.↓ Rel. cost↓ Local-only42.045.43.20.43 Greedy-sequential58.063.12.70.78 Apply-all64.070.87.00.59 FCR73.081.20.71.00 Construction Task yield Reference exec. Success Rate WorkRover (full)74.8 ±2.20 95.1 ±1.10 58.7 ±2.60 w/o Job–Skill67.2 ±2.38 91.7 ±1.48 53.1 ±2.78 w/o File–Skill60.9 ±2.47 84.2 ±2.06 47.4 ±2.92 w/o Relation Expansion52.6 ±2.53 77.9 ±2.52 41.8 ±3.11 w/o Validation Rewrite49.8 ±2.53 80.6 ±2.47 44.5 ±3.22 Semantic-only48.7 ±2.53 73.6 ±2.78 38.6 ±3.19 Rewriting on the same initial tasks. To control for differences in task selection, we compare filtering with and without rewriting on the same 10,000 initial task intents. Both variants preserve the required outcomes and use the same frozen agent. Adding rewriting raises admission from 49.8% to 74.8% and end-to-end success from 22.2% to 43.9%. Reference execution also rises from 80.0% to 92.0%, and Verifier validity from 70.0% to 87.0%. Unconstructed, rejected, and budget-exhausted intents remain in the denominator and contribute no successful completion. The resulting gains therefore measure the full pipeline, from initial construction through agent execution, on the same starting task set. 5 Conclusion WorkRover uses execution feedback to improve both long-horizon cowork agents and the environments used to train them. The Harness keeps work contexts, tasks, and verifiers aligned during construction and repair. FCR revises inconsistent components while preserving task requirements, and VTCA uses verified workspace progress to guide learning at individual turns. Experiments show that FCR increases the share of tasks that pass validation and repairs defects with fewer unintended changes to task intent and fewer regressions on related tasks. Under matched rollout budgets, VTCA outperforms episode-only GRPO on all five benchmarks. These findings support recursive environment evolution as a practical foundation for reliable long-horizon cowork agent training. 10 References [1] Artificial Analysis. GDPval v2 leaderboard, 2026. URL https://artificialanalysis.ai/evaluations/ gdpval-a. GDPval v2 reference scores frozen to the September 12, 2026 snapshot (Asia/Shanghai); model configurations and source records documented in Appendix C.1. [2] F. Bai, H. Song, S. Sun, D. Cheng, Y. Yang, C. Hao, R. Li, F. Chang, Y. Wei, R. Tao, B. Dai, J. Yang, W. X. Zhao, and J.-R. Wen. ClawGym: A scalable framework for building effective Claw agents, 2026. URL https://arxiv.org/abs/2604.26904. [3] H. He, L. Wang, H. Chen, Y. Shao, Y. Shi, L. Wang, P. Liu, G. Lin, Z. Wang, H. Sun, T. Su, and C. Wan. CheckerBench: Can Long-Horizon Agents Synthesize Static-Analysis Checkers?, 2026. URL https://arxiv.or g/abs/2610.07557. [4] H. Chen, Z. Hu, J. Chai, H. Yang, H. He, X. Wang, W. Lin, L. Wang, G. Yin, and Z. Zhao. ToolForge: A Data Synthesis Pipeline for Multi-Hop Search without Real-World APIs, 2025. URL https://arxiv.org/abs/2512.1 6149. [5] Z. Cheng, A. Mishra, S. Sahu, and W. Campbell. Efficient reinforcement learning for long-horizon tool-use agentic tasks, 2026. URL https://arxiv.org/abs/2608.10357. [6] C. Dong, C. Yue, H. He, Y. Liu, F. Tang, S. K. Zhou, X. Wang, J. Chai, and G. Yin. TAPO: Tool-Aware Policy Optimization via Credit Transfer for Multimodal Search Agents, 2026. URL https://arxiv.org/abs/2606.057 84. [7] G. Dong, J. Lu, J. Huang, W. Zhong, L. Liu, S. Huang, Z. Li, Y. Zhao, X. Song, X. Li, J. Jin, Y. Zhu, H. Wang, F. Lei, Q. Luo, M. Chen, Z. Chen, J. Feng, J.-R. Wen, and Z. Dou. Agent-World: Scaling real-world environment synthesis for evolving general agent intelligence, 2026. URL https://arxiv.org/abs/2604.18292. [8] L. Feng, Z. Xue, T. Liu, and B. An. Group-in-group policy optimization for LLM agent training, 2025. URL https://arxiv.org/abs/2505.10978. [9] S. Gandhi, S. Goyal, K. Kate, and Y. Rizk. DRACO: Fine-grained credit assignment with dynamic rubrics for long-horizon agent training, 2026. URL https://arxiv.org/abs/2609.04094. [10] B. Mao, H. He, L. Wang, L. Lin, M. Zhou, G. Liu, J. Liu, T. Huai, C. Zhang, B. Li, K. Lei, G. Dong, Z. Shao, R. Zheng, H. Yan, J. Zhou, C. Wan, T. Gui, L. He, and X. Qiu. WEFT: Scaling Tool-Use Post-Training for General-Purpose Agents, 2026. URL https://arxiv.org/abs/2609.36887. [11] Y. Hao, Z. Jin, H. Liao, K. Liu, and J. Zhao. Why multi-step tool-use reinforcement learning collapses and how supervisory signals fix it, 2026. URL https://arxiv.org/abs/2606.26027. [12] Z. Hua, Y. Yao, W. Xie, Y. Zhao, M. Liu, R. Qiu, Z. Huang, Z. Wang, Y. Ji, Y. Ye, L. Zhu, X. Lei, H. Li, Z. Ma, Z. Wang, Z. Zhang, and J. Liu. CLI-Universe: Towards verifiable task synthesis engine for terminal agents, 2026. URL https://arxiv.org/abs/2606.22883. [13] M. Ivanov and A. Rana. Anchor: Mitigating artifact drift in agent benchmark generation, 2026. URL https: //arxiv.org/abs/2605.26321. [14] JobBench Team. JobBench: Official leaderboard, 2026. URL https://job-bench.github.io/. JobBench-Main; OpenCode v1.14.18 and Grok 4.3; accessed September 6–7, 2026. [15] M. Li, E. Song, Y. Zuo, X. Liu, R. Wen, Q. Fu, G. Antichi, J. He, J. Tie, Z. Shao, X. Xue, X. Xiao, L. Zhong, S. Zhang, J. Zhao, J. Lu, S. Zhang, X. Sun, C. Zheng, Z. Fan, H. Li, T. Pan, X. Wu, Y. Song, X. Li, B. Lyu, M. Li, H. Dai, G. Chen, and S. Zhu. Scalable LLM Agent Tool Access in the Cloud, 2026. URL https: //arxiv.org/abs/2607.15593. [16] Y. Li, Y. Feng, Z. Xu, Z. Ma, K. Zheng, F. Jiang, X. Sun, R. Shao, Z. Chen, Y. Huang, X. Han, B. Lee, K. Xu, S. Zeng, H. Hua, X. Zhang, B. Alomair, R. Krishna, L. Zettlemoyer, P. W. Koh, B. Ramasubramanian, L. Niu, X. Yue, and R. Poovendran. JobBench: Aligning agent work with human will, 2026. URL https: //arxiv.org/abs/2605.26329. [17] H. He, C. Yue, C. Dong, M. Tian, H. Chen, Z. Liu, J. Chai, X. Wang, Y. Zhang, Q. Liao, G. Yin, W. Lin, C. Wan, H. Sun, and T. Su. LocalSearchBench: Benchmarking Agentic Search in Real-World Local Life Services. In Proceedings of the 32nd ACM SIGKDD Conference on Knowledge Discovery and Data Mining, 2026. doi: 10.1145/3770855.3817466. URL https://doi.org/10.1145/3770855.3817466. [18] H. Chen, S. Zhou, Z. Hu, J. Chai, H. He, H. Yang, X. Wang, W. Lin, T. Wang, Z. Zhao, and G. Yin. ToolForge: A Data Synthesis Pipeline for Multi-Hop, Multi-Turn, and Self-Reflective Tool-Use Data. In Proceedings of the 2026 Conference on Empirical Methods in Natural Language Processing, 2026. URL https://openreview.net /forum?id=vFFehO66Y0. [19] A. Y. Ng, D. Harada, and S. Russell. Policy invariance under reward transformations: Theory and application to reward shaping. In Proceedings of the Sixteenth International Conference on Machine Learning, pages 278–287. Morgan Kaufmann, 1999. URL https://ai.stanford.edu/~ang/papers/shaping-icml99.pdf. 11 [20] Z. Niu, Y. Zhao, J. Zhang, X. Shen, J. Si, H. Tian, C. Xu, Y. Song, J. Mao, Y. Gao, Y. Li, J. Wu, L. Yan, S. Wang, and D. Yin. DuMateBench: Evaluating autonomous agents in complex real-world workflows, 2026. URL https://arxiv.org/abs/2608.26546. [21] K. Opsahl-Ong, A. Singhvi, J. Collins, I. Zhou, C. Wang, A. Baheti, O. Oertell, J. Portes, S. Havens, E. Elsen, M. Bendersky, M. Zaharia, and X. Chen. OfficeQA Pro: An enterprise benchmark for end-to-end grounded reasoning, 2026. URL https://arxiv.org/abs/2603.08655. [22] Z. Pan, J. He, K. Zhang, Y. Han, Z. Liu, Y. Zhao, Y. Ye, and Z. Yang. Meta-Task: Turning terminal task synthesis into a terminal task for scalable agent training, 2026. URL https://arxiv.org/abs/2607.27929. [23] Y. Pandya, S. Gupta, S. Harne, A. Yadav, K. Chourasia, H. Mozannar, V. Vineet, S. Abdali, C. Rosset, Y. Lara, A. Awadallah, E. Kamar, and A. Nambi. Echoverse: Deep, evolving environments for training computer-use agents at scale, 2026. URL https://arxiv.org/abs/2607.28074. [24] J. Peng, Y. Liu, R. Zhou, C. Fleming, Z. Wang, A. Garcia, and M. Hong. HiPER: Hierarchical reinforcement learning with explicit credit assignment for large language model agents, 2026. URL https://arxiv.org/abs/ 2602.16165. [25] Qwen Team. Qwen3.5: Towards native multimodal agents, Feb. 2026. URL https://qwen.ai/blog?id=qwen3.5. Official citation recommended by the Qwen3.5-35B-A3B model card; accessed September 11, 2026. [26] J. Chai, G. Yin, Z. Xu, C. Yue, Y. Jia, S. Xia, X. Wang, J. Jiang, X. Li, C. Dong, H. He, and W. Lin. RLFactory: A Plug-and-Play Reinforcement Learning Post-Training Framework for LLM Multi-Turn Tool-Use, 2025. URL https://arxiv.org/abs/2509.06980. [27] Z. Shao, P. Wang, Q. Zhu, R. Xu, J. Song, X. Bi, H. Zhang, M. Zhang, Y. K. Li, Y. Wu, and D. Guo. DeepSeekMath: Pushing the limits of mathematical reasoning in open language models, 2024. URL https: //arxiv.org/abs/2402.03300. [28] D. Shepard and R. Salimans. AutomationBench, 2026. URL https://arxiv.org/abs/2604.18934. [29] K. Shi, Z. Wang, Q. Su, S. Huang, Z. Zhang, Z. Fang, Q. Ren, J. Liu, Y. Zeng, Y. Zhao, L. Chen, Z. Chen, and F. Zhao. FACET: Preserving source intent and executable state in terminal task synthesis, 2026. URL https://arxiv.org/abs/2608.18580. [30] X. Song, H. Chang, G. Dong, Y. Zhu, J.-R. Wen, and Z. Dou. EnvScaler: Scaling tool-interactive environments for LLM agent via programmatic synthesis, 2026. URL https://arxiv.org/abs/2601.05808. [31] J. Su, Z. Zhao, H. Wang, and H. Chen. CoAL-RAG: A Complexity-Aware Legal Retrieval-Augmented Generation Method, 2026. URL https://arxiv.org/abs/2608.17536. [32] X. Sun, Z. Shao, X. Shi, S. Xiao, C. Ma, X. Xue, J. Lu, S. Zhang, E. Song, S. Yang, X. Li, C. Fang, C. Fang, B. Lyu, and S. Zhu. Enabling Black-box RPC-API Testing with Multi-Agent Reinforcement Learning and LLMs: An Industry Case Study. In Proceedings of the IEEE/ACM 48th International Conference on Software Engineering: Software Engineering in Practice, pages 81–93. ACM, 2026. doi: 10.1145/3786583.3786855. URL https://doi.org/10.1145/3786583.3786855. [33] Z. Tang, X. Zhou, Y. Liu, L. Li, Y. Wu, W. Wang, H. Huang, W. Zhou, J. Zhou, J. Song, S. Yu, J. Wang, Z. Zhou, H. Zhou, Y. Lv, J. Li, J. Liu, R. Chen, C. Liu, G. Li, J. Kang, and F. Wu. Workspace-Bench 1.0: Benchmarking AI agents on workspace tasks with large-scale file dependencies, 2026. URL https://arxiv.org/abs/2605.03596. [34] L. Tao, B. Peng, W. Yao, T. Ge, H. Cheng, M. H. Wang, J. Gao, and S. Li. TRACE: Turn-level reward assignment via credit estimation for long-horizon agents, 2026. URL https://arxiv.org/abs/2607.13988. [35] Tencent WorkBuddy Bench Team. Tencent WorkBuddy Bench: A multi-domain coding-agent benchmark with contamination-resistant task construction, 2026. URL https://arxiv.org/abs/2607.20911. [36] H. Trivedi, T. Khot, M. Hartmann, R. Manku, V. Dong, E. Li, S. Gupta, A. Sabharwal, and N. Balasubramanian. AppWorld: A controllable world of apps and people for benchmarking interactive coding agents, 2024. URL https://arxiv.org/abs/2407.18901. [37] H. He, C. Yue, C. Dong, C. Wan, T. Su, H. Sun, J. Chai, X. Wang, and G. Yin. VistaHop: Benchmarking Long-Horizon Visual DeepSearch, 2026. URL https://arxiv.org/abs/2606.03273. [38] W. Weimer, T. Nguyen, C. Le Goues, and S. Forrest. Automatically finding patches using genetic programming. In Proceedings of the 31st International Conference on Software Engineering, pages 364–374. IEEE, 2009. doi: 10.1109/ICSE.2009.5070536. URL https://profsforrest.github.io/homepage/data/publications/2009-i cse-genprog.pdf. [39] X. Wu, C. Yang, H. Liu, X. Lin, Z. Shi, H. Zhou, X. Jiang, C. Xu, J. Li, and J. Guo. Envs-FORGE: Frontier- optimized reward-grounded environment synthesis for agent RL, 2026. URL https://arxiv.org/abs/2608.143 12. [40] Z. Xi, Y. Ding, W. Chen, B. Hong, H. Guo, J. Wang, X. Guo, D. Yang, C. Liao, W. He, S. Gao, L. Chen, R. Zheng, Y. Zou, T. Gui, Q. Zhang, X. Qiu, X. Huang, Z. Wu, and Y.-G. Jiang. AgentGym: Evaluating and training large language model-based agents across diverse environments. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 27914–27961. Association for 12 Computational Linguistics, 2025. doi: 10.18653/v1/2025.acl-long.1355. URL https://aclanthology.org/202 5.acl-long.1355/. [41] Z. Xi, J. Huang, C. Liao, B. Huang, H. Guo, J. Liu, R. Zheng, J. Ye, J. Zhang, W. Chen, W. He, Y. Ding, G. Li, Z. Chen, Z. Du, X. Yao, Y. Xu, J. Chen, T. Gui, Z. Wu, Q. Zhang, X. Huang, and Y.-G. Jiang. AgentGym-RL: Training LLM agents for long-horizon decision making through multi-turn reinforcement learning, 2025. URL https://arxiv.org/abs/2509.08755. [42] Z. Xi, C. Liao, G. Li, Y. Yang, W. Chen, Z. Zhang, B. Wang, S. Jin, Y. Zhou, J. Guan, W. Wu, T. Ji, T. Gui, Q. Zhang, and X. Huang. AgentPRM: Process reward models for LLM agents via step-wise promise and progress, 2025. URL https://arxiv.org/abs/2511.08325. [43] K. Xu, H. Xu, X. Chen, Y. Wang, Z. Li, X. Liu, C. Wu, J. Xia, and Y. Li. STAMP: Provenance-guided credit assignment for deep search agents, 2026. URL https://arxiv.org/abs/2607.11172. [44] C. Yue, C. Dong, Y. Gao, H. He, J. Chai, W. Lin, and G. Yin. Promoting Efficient Reasoning with Verifiable Stepwise Reward. Proceedings of the AAAI Conference on Artificial Intelligence, 40(41):34530–34538, 2026. doi: 10.1609/aaai.v40i41.40752. URL https://doi.org/10.1609/aaai.v40i41.40752. [45] W. Zeng, J. Zhang, H. Chen, Z. Hu, Y. Liang, J. Chai, D. Liu, Z. Liu, S. Yan, M. Xue, X. Wang, W. Lin, and G. Yin. RecRM-Bench: Benchmarking Multidimensional Reward Modeling for Agentic Recommender Systems, 2026. URL https://arxiv.org/abs/2605.11874. [46] H. Zhang, M. Chen, D. Zhou, C. Lv, H. Chang, S. Cui, F. Wu, and S. Zhou. TRCA: Transition-wise rubric credit assignment for long-horizon LLM agents, 2026. URL https://arxiv.org/abs/2608.16156. [47] Z. Zhong, I. Segal, I. Bercovich, S. Saxena, K. Zhang, and A. Raghunathan. Hardening agent benchmarks with adversarial hacker-fixer loops, 2026. URL https://arxiv.org/abs/2606.08960. [48] C. Zhou, Q. Jiang, S. Wu, and X. Zhou. Coverage, not targeting: A structural regime in multi-turn agent credit assignment, 2026. URL https://arxiv.org/abs/2609.02417. [49] S. Zhou, H. Chen, T. Wang, G. Lin, Z. Wang, and H. Zhao. RAG-Stress: Probing the Limits of Evidence Reliance in Retrieval-Augmented Generation, 2026. URL https://arxiv.org/abs/2610.11183. 13 A Extended Related Work Executable environments and task synthesis. Professional agent training requires executable tasks, recov- erable state, and observable outcomes across related artifacts. AppWorld provides controllable application environments; EnvScaler supports programmatic environment construction, while ClawGym materializes workspaces around task and capability requirements [2, 30, 36]. Agent-World uses capability diagnostics to expand tool/database environments [7]. ToolForge constructs virtual-tool tasks, and MetaTask and CLI- Universe emphasize executable validation [4, 12, 18, 22]. These approaches organize synthesis around task bundles, environment expansion, or capability requirements. WorkRover grounds task construction in file relations and professional skills, then assembles Tasks and Verifiers within recoverable Work Contexts under a versioned Harness. Shared contexts also make dependency tracking and revalidation necessary when one component changes. Grounded acceptance and verifier reliability. Acceptance checks must agree with the instruction and the ev- idence available in the workspace. ANCHOR constructs instructions, environments, solutions, and verifiers from a shared workflow specification [13]. FACET grounds artifacts in shared state and repairs inconsistencies while preserving source intent [29]. Hacker–Fixer audits tests and environments with adversarial cases while checking legitimate solutions [47]. Stronger rejection checks therefore need to be considered alongside false re- jection of valid alternatives. WorkRover freezes instruction-grounded requirements and criterion–evidence bindings, then evaluates implementations using violating mutants and independently valid solutions. Refer- ence artifacts supply recomputable anchors without adding requirements. Infrastructure-invalid episodes are distinguished from policy failures. Validation remains limited to the declared Contract and the coverage of the controls. Environment evolution and repair selection. Envs-FORGE studies joint revision of instructions, fixtures, so- lutions, tests, and environments, while EchoVerse studies executable environment evolution [23, 39]. FACET routes failed validation to implicated artifacts and repeats validation from a clean state [29]. Program repair likewise studies patch minimization: GenProg reduces test-passing patches through structural differencing and delta debugging [38]. FCR freezes component-level proposals over Context, Task, Harness, and Verifier before replaying their combinations. Materialization includes dependency-induced changes, and promotion checks affected retained tasks for regressions under fixed requirements. The selected repair is the smallest admissible closed edit set among the tested combinations; bounded enumeration does not establish a global minimum over all possible repairs. This separates proposal generation, compatibility selection, and validation of a shared environment revision. Local progress in long-horizon learning. Methods differ in the evidence used to assign local feedback. GiGPO uses state comparisons, while HiPER uses a planning hierarchy [8, 24]. TRACE forms temporal differences in frozen-model reference-answer likelihoods, with bounded look-ahead for delayed tool effects [34]. TRCA combines deterministic transition-rubric scores with increments in cumulative condition coverage [46]. VTCA instead evaluates successive observable workspace states with frozen checkers. Signed progress can register both completion and setbacks in persistent, mutable artifacts. Unsupported or unavailable evidence supplies no local signal, while terminal evaluation remains applicable to supported task outcomes. These differences concern the feedback source and its coverage; they do not by themselves establish the comparative effectiveness of individual components. Evidence attribution and shaping limits. STAMP maps verified citations to first-exposure actions; DRACO uses judge-attributed steps with sign-preserving GRPO advantage redistribution [9, 43]. VTCA follows recorded direct use of exact tool outputs or artifact versions, assigning at most half of positive progress to eligible prerequisite turns and leaving negative increments local. Access alone creates no dependency edge. Incorrect provenance can misallocate credit, and missed links leave prerequisites unrepresented. Recorded use therefore does not establish causal necessity. Potential-based reward shaping preserves optimal policies under stated assumptions [19]; VTCA is formulated as workspace-grounded advantage shaping. Conservation 14 of checker increments before gating, costs, and clipping establishes neither policy invariance nor an unbiased policy-gradient estimate. B Data Construction and Case Studies B.1 Work Context Construction For each source workspace w, the index I(w) stores a typed graph G w = (V w ,E w ) with files or versions as nodes and semantic, structural, temporal, provenance, and workflow edges. Directory co-location is only a weak structural signal. A job skill specifies its professional setting, workflow, materials, and deliverables. The Skill Matcher retrieves related file regions, then expands them through file and application skills with compatible inputs, outputs, and interfaces. The Harness validates dependencies, permissions, bindings, reset, recovery, and evidence capture. Recorded lineage and derived task branches stay in one data split. Construction complexity. Let J be the number of job skills, W the number of source workspaces, k the number of shortlisted regions per job skill, and M ≤ Jk the number of candidates retained for environment assembly. Let C index and C retrieve denote per-workspace indexing and per-job-skill retrieval costs; C agent , C match , and C env denote per-candidate agent inspection, skill matching, and environment-assembly costs. Excluding source collection and one-time pool construction, the total cost of indexed Work Context construc- tion is O(WC index ) + O(JC retrieve ) + O(Jk(C agent + C match )) + O(MC env ).(2) Agent inspection covers the Jk shortlisted candidates, with cost O(JkC agent ), whereas exhaustive job– workspace inspection incurs O(JWC agent ). This comparison concerns agent inspection; indexing, retrieval, skill matching, and environment assembly remain separate costs. The index is reusable across job-skill queries, so its construction cost is paid once for a fixed source collection. B.2 Synthesis Resources and Coverage The inventory contains 21,444 app skills, 5,918 file skills, and 36,064 job skills covering 317 roles. App and job skills receive one category label across 15 and 10 categories; file skills have 11,273 memberships across 22 categories. Figure 4 shows the six largest categories per library and groups the remainder as Other. Construction profiles describe artifact diversity, file relations, workflow horizon, cross-root dependencies, and noise; empirical difficulty is calibrated separately. B.3 Workspace Construction from Deep Research Sessions In this route, a source workspace is the exported file collection associated with one research record. Historical research supplies materials; new tasks require fresh Demonstrator execution and independent admission (Figure 8). Inventory and source identity. Files are inventoried by relative path, format, size, and content hash. Bounded previews expose headings, workbook sheets, or archive members for selective reading. Captured sources and independently retained, readable notes, tables, or reports may enter the Starter State after relevance and leakage checks. Raw conversations, tool logs, internal analysis caches, provenance directories, and unsupported web caches are excluded. The original query informs construction only and is not Solver evidence. Source pointers support audit; a URL cannot replace a required local file. Citations in notes must be checked against their sources. Co-occurrence, retrieval order, and model assertions do not establish dependencies; missing lineage is unresolved. Freezing files does not make historical searches or services replayable. Unavailable required sources lead to revision or rejection; permitted new retrieval follows the Harness contract and records its evidence separately. Branch plans and answer leakage. A job skill’s requirements guide eligible-file retrieval within one source collection. File skills bind the required operations; app skills bind any instrumented application capabilities. Branches must differ in professional decisions, operations, or principal products, and cannot import unselected files or combine source collections. A feasible Branch Plan becomes a workspace and Task Blueprint specifying 15 From Deep Research Files to Verified Task Workspaces Context-grounded task synthesis from research files WorkRover admission 1 Index source workspace 2 Match capabilities 3 Plan task branches 4 Assemble Starter State 5 Execute and verify Exported research files Shared file index File metadata Document structure Source relations Eligibility Eligible files One source collection Job Skills Professional goal File Skills File operations App Skills When required AnnotateReconcile Revise Branch Plan File roles Operation dependencies Branch gate Branch workspace Task Blueprint Deliverables Preservation rules Outcome checks New instruction Goal and outcomes Starter State Selected files EditableProtected Required app state Solver-visible inputs File selection Fresh Demonstrator Reference State Recomputable anchors Instruction and visible invariants Evaluation Contract Compiled Verifier Acceptance tests Starter state Reference state Violating mutants Valid alternatives Admitted task Bind App Context Original query: construction context onlyInternal records and hidden evaluations stay outside Solver inputs Proposed task from case 1781 Output layout Household totals IPSS workbook 1 Age and family groups IPSS workbook 2 Both inputs unchanged Compare single-person households Align years and cross-check totals Comparison workbook 202020302050 Count Share Units and source sheets recorded Figure 8 From Deep Research files to verified task workspaces. Instructions and visible invariants define requirements; the dashed green arrow supplies recomputable Reference State anchors. Case 1781 uses two IPSS workbooks; shaded cells mark output values to populate. file roles, dependencies, deliverables, and modification/preservation constraints. Every required outcome has an observable criterion. A write acknowledgment or readback excerpt alone is not an editable artifact. Retained notes require evidence for their claims; inputs that already complete the new task cause revision or rejection. Hidden plans, solution keys, and evaluation records stay outside Solver inputs and cannot supply unstated requirements or inaccessible task evidence. Fresh execution, verification, and lineage. The instruction and selected files/application state define a frozen Starter State. A fresh Demonstrator establishes feasibility and a Reference State; historical session comple- tion cannot substitute. The Contract uses only the instruction and visible invariants, with independently recomputable anchors. Admission requires rejection of the Starter State and violating mutants, acceptance of valid Reference States and alternatives, and protected-state checks. Branches retain collection, session, and file-version lineage. Sessions, retained collections, candidates, and admitted tasks are counted separately; branch count alone does not establish independent diversity. B.4 Task Synthesis and Quality Control Each package contains an instruction, resettable snapshot, environment specification, metadata, and a fresh Demonstrator realization with available terminal artifacts. Instructions state outcomes and constraints with- out prescribing tools or action sequences. Core files require defensible relations; input ablation removes unnecessary bindings, and distractors cannot change the dependency closure. Table 4 controls scale and interaction horizon. Empirical difficulty is the valid-rollout failure rate of a frozen reference panel under matched snapshots, tools, permissions, and budgets. Panel membership, aggregation, and band thresholds are fixed on development data; evaluated systems do not contribute to these labels. Gates check instruction clarity, readable inputs, sufficient dependencies, reproducible restoration, and outcome anchors. Unobservable core outcomes are rejected. External capabilities require declared Harness tools with recorded versions, seeds, permissions, and 16 Table 4 Target task-construction profiles. The profiles control scale and interaction horizon. DimensionP1P2P3 Edit scope (files)∼10∼20> 30 Demonstrator horizon target (turns)5–1015–30> 30 Skill composition target2 job + ≥ 1 file3 job + ≥ 3 file4 job + ≥ 5 file App skillsAs requiredAs requiredAs required WorkEnv noise ratio10%20%30% Cross-env dependencies234 Distractor tiersObviousObvious + near-topicAll three initial-state identities. B.4.1 Task Design and Review The Blueprint binds each outcome to extractable or independently recomputable artifact/application evidence (Table 5). The manifest distinguishes required inputs, history, distractors, and protected artifacts. Review checks opening/parsing, formulas, merged cells, annotations, version history, layout, and embedded objects; visually specified outcomes also require rendered inspection. Table 5 Representative workflow requirements and observable outcome evidence. WorkflowInputs and dependenciesOutcome evidence Artifact revisionSource versions, comments, approvals Required edits, consistent versions, pre- served review history/protected content Data reconciliationDatasets, formulas, source records, peri- ods Recomputed aggregates, formulas, units, de- clared missing-value handling Structured contentReports, templates, charts, mediaRequired content/layout and preserved un- affected elements Cross-artifact deliveryLinked files, output specifications, ex- ports Complete outputs, formats/order, source– export consistency CollaborationCalendar, email, drive, approval state Required state changes, consistent records, satisfied workflow conditions B.5 Case Studies: Recorded Deep Research Examples Figures 9 and 10 pair recorded research workflows with their exported file collections. m i is the zero-based trace message index. The proposed file tasks illustrate Appendix B.3. Shaded cells indicate output fields to populate. Source-page references associate these files with the research but do not establish per-file downloads in the recorded traces. New tasks still require fresh Demonstrator execution and counterfactual Verifier checks; raw traces and internal provenance remain outside Solver inputs. B.6 Case Study: Quarterly Executive Handoff Record 0805:comp_018554 belongs to the 5,000-trajectory pool and the 3,200-trace subset described in Appendix D.1. Figure 11 follows its Hermes execution. The agent verifies five regional revenue rows, registers the vendor, amends the Q2 access policy, retires the archived Q1 policy, and checks five exports. Revenue values match the source; the workbook adds totals, growth, and evidence references. The final report retains the database lock wait and stale export alias as follow-ups. All four archived goal groups pass (score 0.946); file validation covers structure/content, with visual review unavailable. C Verifier, Repair, and Training Details 17 Case 1875 Prompt-engineering course design 118 messages Research request Design course readings, practical experiments and grading rubrics Recorded researcher branch Find papers m8–m36 Search method papers Read papers and docs Check evidence m37–m100 Evaluation datasets Failure cases Teaching constraints Draft and inspect m101–m110 Write teaching notes Read four note segments Correct citations m111–m116 Add BBH paper citations Three successful edits Paper sources and teaching evidence support a structured course-design note Retained paper sources Proposed file task Chain of Thought Worked reasoning examples Skeleton of Thought Outline and parallel expansion DSPy Modules and metric-guided compilation Three frozen paper source archives Reuse Method matrix MethodSource evidence CoT SoT DSPy Lab briefs Three experiments Baselines Grading rubrics Preserve papers and cite local sections Teaching note not exportedm117 No completion result Figure 9 Recorded example 1875: prompt-engineering course design. This researcher branch writes teaching_- design.md, inspects four segments, and adds the BIG-Bench Hard paper citation in three places. The proposed task reuses captured CoT, SoT, and DSPy paper-source archives to produce a method comparison workbook and three lab briefs with baselines and grading rubrics. Claims cite local source sections; the original archives remain unchanged. Case 1781 Policy research on older adults living alone 69 messages Research request Use Japan’s solitary-death experience to assess risks, interventions and policy transfer Recorded research Assign research m8–m16 3 initial assignments 4 deeper assignments Recover and read m17–m42 HTTP 500 at m17 Note completion reported after retry at m24 Write and revise m47–m56 Memo creation reported Reviewer feedback Revision reported Read revised memo m59–m67 Inspect and search files Read revised content Coordinator reads four notes in two batches Source-page references observed at m39 Retained filesProposed file task 5 IPSS workbooks Select household totals and age tables 5 vital-statistics CSVs Not solitary-death measures CSVs excluded from the proposed task Select two Single-person household comparison 202020302050 Count Share Preserve inputs and record units and source sheets Memo not exportedm68 No session completion result Figure 10 Recorded example 1781: policy research on older adults living alone. The proposed task selects hprj2024_gaiyo_kekka1.xlsx and hprj2024_gaiyo_kekka2.xlsx, retaining category definitions, units, and source- sheet references. The revised policy_memo.md is observed through tool readbacks. Source-page references at m 39 cite IPSS and MHLW. 18 Quarterly Executive Handoff Hermes · 56 Turns · 55 Tool Calls Task T i Prepare the Q2 handoff from live chart, workspace and ledger evidence. Use authoritative revenue; verify every checklist item and export; keep claims traceable. 4 Working Files to Complete + 3 New Deliverables · 3 Required Skills (a) Work Context C i File Context C file q2_revenue_workbook.xlsxQ2 Values Unverified dashboard_readiness.docxChecks Incomplete vendor_registry.xlsxNot in Ledger export_inventory.xlsx5 Exports Unverified App Context C app Chart Catalog: Regional Revenue + Chart Renders Workspace: DB Health + Storage Exports JSON Ledger: Vendor, Policies and Incident Chart Defaults: Dark · SVG · 1200×700 Capability Context C cap Required Procedures and Recorded Outcomes Data Validation Read via skill_view · t 1 Verify sources and timestamps Check totals and growth rates Cross-check reported values 6 / 6 Rows Match ( Turn 50 ) Gap Analysis Read via skill_view · t 2 Compare requirements with state Classify gaps by severity Plan fixes and verification 4 Gap Findings ( Turn 50 ) Report Builder Read via skill_view · t 3 Summarize key metrics Add charts and supporting tables Include findings and next steps Handoff Report ( Turn 44 ) (b) Recorded Execution τ i,r Collect Evidence Turns 6–26 get_dataset render_chart 5 Regions; 3 Chart Renders DB Health + Storage Listing 5 Exports · 957,160 Bytes Align Records Turns 27–38 save_json_doc delete_json_doc Vendor Created + Read Back Q2 Access Policy Amended Archived Q1 Policy Removed Produce Files Turns 41–44 terminal patch Q2 Total + Regional Growth 4 Working Files Updated 3 New Deliverables Created Check and Report Turns 47–56 execute_code terminal 7 Files Open with Parsers 16 Readiness Checks Complete 4 Structured Gap Findings (c) Evidence and File Dependencies Chart Catalog → Workbook → Reconciliation Q1 $5,168,000 → Q2 $5,498,500 +$330,500 (+6.40%) · 6/6 Rows Match · t11, t41, t50 Policy Before (t29) q2-revenue-export Storage Evidence (t25) exports/q2-revenue/ Policy After (t33, t54) exports/q2-revenue/ Export Inventory and Handoff Report Reuse the verified bucket, prefix and evidence IDs (d) Deliverables and Evaluation q2_reconciliation.xlsx gap_findings.docx executive_handoff_report.docx Recorded Evidence E i 7 Files Parsed · 6/6 Rows Matched 16 Checks Complete · 5/5 Exports Found Archived Evaluator V i 4/4 Goal Groups Passed · Score 0.946 Revenue · Workspace · Ledger · Report Follow-Ups and Validation Limit DB Lock Wait; Stale Incident Export Alias Structure / Content Checked; No Visual QA Figure 11 Recorded quarterly executive handoff. (a) File, capability, and app context. (b) Selected rollout stages. (c) Revenue and export-path evidence supporting consistent updates. (d) Deliverables, archived evaluation, retained follow-ups, and validation scope. C.1 Verifier Specification and Calibration Criteria derive from the instruction, Starter State, and visible invariants; Reference artifacts only instan- tiate independently recomputable anchors. The frozen Contract specifies editable/protected state, allowed transitions, and each criterion’s predicate, evidence, checking mode, weight w k , threshold γ k , and critical flag b k . Unresolved requirements prevent admission. Adapters and canonical diffs provide stable evidence IDs. Executable checks read both snapshots; at most one batched Judge call receives frozen criterion-tagged evidence, has no live tools, and cites evidence or abstains. For scores p i,k ∈ [0, 1], set y i,k = 1[p i,k ≥ γ i,k ] and 19 ̄w i,k = w i,k / P j w i,j : S B,i = X k ̄w i,k p i,k , H i = g integrity i g protected i g safety i , G i = H i Y k:b i,k =1 y i,k .(3) Healthy evaluation passes iff G i = 1 and S B,i ≥ τ B . Missing required state implies failure; infrastructure- unavailable evidence implies invalidity. Policy errors under healthy infrastructure are not invalid. Partial credit cannot offset gates. Auxiliary S A ∈ [0, 1] uses frozen trace checks. Admission requires the Starter– Reference contrast, protected-state checks, no unresolved invalid controls, and frozen thresholds for criterion agreement, worst-family mutant detection, and valid-alternative acceptance. Task-level negatives must vio- late the Contract. Calibration, initial admission, reporting, and promotion use disjoint recipe–seed banks. Unsupported semantic criteria retain terminal supervision without local progress signals. C.2 FCR Mechanics and Promotion Freeze one direct proposal per available Context/Task/Harness/Verifier factor before replay: at most 16 cells, or eight before compilation. Each cell χ applies the dependency-closed update set Γ(χ), including dependency-induced updates; changed tasks require fresh execution/compilation, and shared Harness edits require affected-task checks. Established conflicts make cells unavailable; uncertain cells proceed to material- ization. Candidate repair returns to the earliest affected gate; maintenance freezes the admitted parent. Both preserve intent, outcomes, transitions, and applicable Contract weights, thresholds, flags, and gates. Hid- den evidence cannot leak into visible edits; new tools require separate releases and semantic changes create new candidates. Blinded equivalence review and a frozen solver panel apply development-fixed simplification margins. Matched Context–Task–Harness seeds produce evidence reused by Verifier variants. Health uses all seeds; outcome contrasts use common healthy seeds on complete compatible subcubes, without imputation. Verifier contrasts use sealed label agreement. Selection requires a proposal-independent defect/health predicate, proposal-disjoint replay, equivalence, no affected-task regression, and compiled-Verifier calibration plus a one- use binary promotion shard. Reporting audits never select repairs. The smallest validated closed edit set Γ(χ ⋆ ) among tested cells receives fresh-seed confirmation (Section 3.2); failure discards candidates or retains maintenance parents and quarantines unresolved triggers. C.3 FCR Evaluation Protocol Frozen stratified screening of the 10K pool targets 300 natural mismatches, classified by two blinded reviewers with third-reviewer adjudication. The separate controlled cohort injects 260 concealed Contract-preserving defects: 80 single-, 120 pair-, 40 triple-, and 20 four-factor cases. Candidate-controlled comparisons share proposals; end-to-end comparisons allow independent proposals under matched caps. Each distinct Context– Task–Harness configuration uses five matched seeds; compatible Verifiers reuse evidence. Confirmation seeds and generation-specific promotion shards are disjoint. Joint necessity excludes passing strict proposal subsets. Triggers are statistical units; seeds/cells are nested measurements. C.4 Verifier-to-Turn Credit Assignment Canonical traces retain ordering, call/result IDs, tool definitions, versions, and state metadata. SFT super- vises agent tokens; invalid rollouts receive no training signal. For valid rollout r, R i,r = G i,r [(1− λ)S B,i,r + λS A,i,r ], A traj i,r = R i,r − ̄ R i max(sd r ′ R i,r ′ ,σ R,min ) ,0≤ λ≤ 0.1.(4) The denominator floor is development-fixed. Deterministic progress ∆ i,r,t,k = φ i,k (x i,r,t+1 ) − φ i,k (x i,r,t ) requires both endpoints evaluable; otherwise record zero increment and a missing reason. Missing intervals are not bridged or treated as zero completion. No intermediate Judge is called. Prerequisite set P i,r,s,k deduplicates earlier producer turns whose exact outputs/versions are directly consumed at s, with criterion- compatible immutable IDs and call/result links. Stale, ambiguous, inferred, and unrecorded uses are excluded. 20 With ρ i,r,s,k = ρ1[|P i,r,s,k | > 0] and 0≤ ρ≤ 1/2, b i,r,s,t,k = 1− ρ i,r,s,k ,t = s, ρ i,r,s,k /|P i,r,s,k |, t∈P i,r,s,k , 0,otherwise, δ crit i,r,t = X k ̄w i,k T i,r −1 X s=t b i,r,s,t,k max(∆ i,r,s,k , 0) + min(∆ i,r,t,k , 0) . (5) Allocation is direct; negatives and empty-set increments stay local. Weights are not renormalized over ob- served criteria or centered across turns. Equation 1 gates progress by H, terminal reward by G. Trace cost c t ∈ [0, 1] covers malformed/error calls, redundant state-preserving actions, and attributable protected- state/safety violations. GRPO averages tokens within turns, turns within trajectories, then trajectories within task groups, using fixed behavior policy, SFT reference, and detached advantages. Before gating/- cost/clipping, P t δ crit i,r,t = P k ̄w i,k P t ∆ i,r,t,k ; only complete observations telescope. Write–revert cycles and wrong provenance can still alter updates. D Evaluation Details Referenced in the Main Text D.1 Experimental Setup Training and visualization data. Qwen3.5-35B-A3B is the post-training backbone; 397B-A17B supplies 30,115 Verifier-accepted SFT trajectories passing structural/lineage QA. Collection allows three retries per rejected turn with exact prefix restoration. Four 35B-A3B pilots per candidate retain 3,200 RL pairs from 20,000 candidates; splits are by Work Context. RL starts from SFT with turn-balanced GRPO, KL coefficient 0.01, and matched tools, permissions, states, and budgets. Trajectory analysis separately selects 3,200 of 5,000 successful traces: 40 < deduplicated assistant turns < 100, eval.score> 0.8, passed evaluation, com- plete segments, and normal termination. Ranking uses named skill calls, score, then deterministic hash. This subset does not estimate online RL; valid failures still train. The Harness allocation is OpenCode/Claude Code/Codex/Hermes 60/20/10/10%. Controlled evaluations. Matched runs fix release, split, evaluator, Harness, and budget, charging invalid/re- tried attempts under frozen caps. Tasks cluster by Work Context. GDPval Elo and percentages are not averaged. Controlled OfficeQA Pro uses 133 questions at 0.0% numerical tolerance. Benchmark configuration. GDPval v2 uses the September 12, 2026 (Asia/Shanghai) A snapshot and Stirrup [1]. JobBench Main uses 65 tasks, OpenCode v1.14.18, and Grok 4.3 [14]. For OfficeQA Pro, WorkRover uses Claude Code, temperature 0.7, top-p 0.95, top-k 40, 1,800 seconds. D.2 Matched VTCA Comparison Figure 6 matches checkpoints, task/seed schedules, groups, rollout/token/update budgets, and interac- tion/Verifier/Judge caps; all attempts are charged. VTCA uses one terminal Verifier pass and at most one Judge call; checker/capture/CPU costs are separate. Controls cover aggregation, local-only progress (ρ = η = 0), matched random/verified recipients, and trace cost. Random recipients preserve producer mass, budget, and count. Inference resamples training replicas and task/Context clusters; GDPval refits ratings from matched judgments. E Data Construction and Case Study Summaries The following tables consolidate the material boundaries and admission process in Appendices B.3 and B.4, and distinguish proposed tasks from the recorded execution in Appendices B.5 and B.6. 21 Table 6 Source materials, construction roles, and Solver visibility. Eligibility does not establish factual authority or evidence sufficiency. MaterialConstruction roleSolver visibility Captured source filesReadable source documents, code, or ta- bles. Selected files are frozen in the Starter State. Retained working files Editable files; factual claims require sup- porting sources. May be selected if they do not reveal the completed answer. Original research query Background for job skills and task intent. Construction only; never Solver input or evi- dence. Logs and internal analy- sis Audit context; readbacks are not editable artifacts. Excluded from selectable inputs. Provenance and source pointers Lineage/source identity; URLs cannot replace local files. Internal manifests remain outside Solver in- puts. Table 7 Task construction stages and admission checks. Each new task requires fresh execution and verification, independently of historical session completion. StageRecorded outputAcceptance check Index the sourcePaths, formats, sizes, hashes, structural previews, and available file relations. Selected inputs are readable; claimed depen- dencies have support and unresolved lineage is recorded. Plan a task branchJob/file/app skill bindings and a Branch Plan selecting files from one collection. The objective is feasible; branches differ in de- cisions, operations, or products; no unselected files are imported. Assemble the Starter State Frozen files and app state, permissions, capability bindings, and a role/protection manifest. Dependencies are available; reset/recovery works; task-relevant structures survive; no completed-answer leakage. Specify and execute Instruction, Task Blueprint, fresh Demon- strator trace, and Reference State. Required outcomes and preservation con- straints are observable and achievable under the declared Harness. Compile and calibrate Frozen Contract, recomputable anchors, evidence bindings, and counterfactual con- trols. The Starter State fails; valid Reference States and alternatives pass; violating mutants and protected-state changes are detected. Record lineage and split Source/session/file-version identities and separate collection, candidate, and admis- sion counts. Connected lineage and derived branches re- main in one split; branch count is not treated as independent diversity. Table 8 Case study inputs, work products, and evidence scope. The two Deep Research cases illustrate proposed derivative tasks; the handoff case is a recorded execution. CaseInputs and requested work productsEvidence and verification scope 1875: course designCaptured CoT, SoT, and DSPy paper archives support a method comparison work- book and three lab briefs with baselines and grading rubrics. Claims cite local source sections; archives remain unchanged. The historical teaching note was not exported. Fresh task execu- tion and admission are still required. 1781: household pro- jections Two IPSS workbooks support a comparison of single-person household counts/shares for 2020, 2030, and 2050, retaining definitions, units, and source-sheet references. Both input workbooks remain unchanged. Historical memo evidence is limited to tool readbacks; source-page references do not prove individual downloads. Fresh admission is required. Quarterly executive handoff Revenue sources, working files, chart/- workspace state, and the ledger support up- dated files, a reconciliation workbook, gap findings, and an executive handoff report. Record 0805:comp_018554: all four goal groups passed, score 0.946. Structure/con- tent were checked; visual review was un- available. Lock-wait and stale-alias follow- ups remain. 22