PaperlayerView exact revision on arXiv

Source-linked AI summary

Davinci-Tool: Scaling Agentic Tool-Use Supervision with Verifiable Executable Environments

Xiaoyang Yuan, Ji Zhao, Xingyu Hu, Wenhan Wang, Yutao Hu, Qiaosheng Zhang, Pengfei Liu, Yu Qiao, Yi Bin, Wenqi Shao

arXiv:2610.16867v1cs.LGcs.AIcs.CL

TL;DR

Reliable tool-use training needs workflow coverage and outcome verification to scale together as environments introduce distinct states, rules, and dependencies. Davinci-ToolData combines verified demonstrations with reusable executable states and verifiers, and Davinci-Tool improves its 30B backbone across three held-out benchmarks while outperforming a 480B model on all three.

  • Problem

    Scaling tool-use data requires both diverse workflow coverage and reliable outcome verification that reflects environment-specific states, rules, and dependencies.

    Source: §1 · p. 1

  • Method

    Davinci-ToolData unifies restorable states, execution traces, outcomes, and executable verifiers, using EGTS and EES for demonstrations and reusing EES states for outcome-grounded decision preferences.

    Source: §1 · p. 2

  • Results

    Davinci-Tool-30B improves Qwen3-Coder-30B-A3B-Instruct from 52.4 to 88.2 on τ 2-bench, 30.4 to 62.8 on BFCL v4 multi-turn, and 16.9 to 56.2 on MCP-Atlas, outperforming Qwen3-Coder-480B-A35B-Instruct on all three.

    Source: §1 · p. 3

  • Takeaways & Limitations

    Reusable execution and verification infrastructure supports tool-use training from demonstration construction through decision refinement.

    Source: §6 · p. 10

Abstract

from arXiv · show

Reliable agentic tool use requires training data that pair diverse multi-step workflows with executable evidence that the requested outcomes were achieved. Scaling either trajectory coverage or verification alone is insufficient as new environments introduce distinct states, rules, and dependencies that must also be reflected in the success criteria. To address this challenge, we introduce Davinci-Tool, a 30B tool-use model, and Davinci-ToolData, an execution-grounded dataset designed to scale environment coverage and outcome verification together. Davinci-ToolData preserves restorable states, execution traces, outcomes, and verifiers as a unified substrate for supervision. Two complementary pipelines populate this substrate: Execution-Grounded Task Synthesis (EGTS) derives verified demonstrations from independently authored systems, and Executable Environment Synthesis (EES) synthesizes auditable environments, state-grounded tasks, and executable verifiers across single and coordinated domains. These pipelines yield 30,395 verified trajectories spanning 2,260 invoked tool names. We first train on these demonstrations with supervised fine-tuning, then reuse EES states and verifiers to compare alternative actions and construct outcome-grounded preferences for Direct Preference Optimization. Davinci-Tool improves Qwen3-Coder-30B-A3B-Instruct from 52.4 to 88.2 on $\tau^2$-bench, from 30.4 to 62.8 on BFCL v4 multi-turn, and from 16.9 to 56.2 on MCP-Atlas, outperforming Qwen3-Coder-480B-A35B-Instruct on all three benchmarks with only 1/16 of its total parameters. Code is available at https://github.com/MassLab-SII/Davinci-Tool.

1 INTRODUCTION

Reliable tool-use training requires workflow coverage and outcome verification to scale together as environments add distinct states, rules, and dependencies. Davinci-ToolData combines complementary execution-grounded construction pipelines, and Davinci-Tool improves the 30B backbone across three held-out benchmarks.

1 INTRODUCTION

  • Scaling tool-use data requires workflow coverage and outcome verification to grow together because diverse environments introduce distinct states, rules, and dependencies.Verification must reflect those environment-specific conditions in its success criteria.Source: §1 · p. 1
  • Davinci-ToolData unifies restorable initial states, action–observation traces, environment outcomes, and executable verification across heterogeneous sources.The shared substrate supports both supervised and preference learning.Source: §1 · p. 2
  • EGTS derives task-conditioned replay demonstrations from explored outcomes in authored systems, while EES builds audited executable environments for single- and cross-domain tasks.Together they produce 30,395 verified trajectories spanning 2,260 distinct invoked tool names.Source: §1 · p. 2
  • Decision-level DPO reuses restorable EES scenarios to compare alternative decisions through bounded sibling rollouts and verified downstream outcomes.Only divergent assistant turns are optimized; the construction does not require an additional expert action generator or process evaluator.Source: §1 · p. 2
  • Davinci-Tool-30B raises its Qwen3-Coder-30B-A3B-Instruct backbone from 52.4 to 88.2 on τ 2-bench, 30.4 to 62.8 on BFCL v4 multi-turn, and 16.9 to 56.2 on MCP-Atlas.It also outperforms Qwen3-Coder-480B-A35B-Instruct on all three benchmarks with 1/16 as many total parameters.Source: §1 · p. 3

2 RELATED WORK

Related work scales tool-use supervision through synthetic data, collected trajectories, execution-derived tasks, environment synthesis, and preference learning. Davinci-Tool’s approaches build on these lines with verified replay and composed executable domains.

2 RELATED WORK

  • ToolLLM, ToolACE, MCP-Flow, and TOUCAN scale supervision through synthesis or MCP-environment trajectory collection, while execution-first methods derive tasks from observed runs.EGTS re-executes synthesized requests from the corresponding initial state; unlike AgentTrek, it derives guidance and verification evidence from the originating execution.Source: §2 · p. 3
  • EnvScaler and ASTRA synthesize executable environments or verifiable subenvironments; EES audits reusable domains before generating single- or cross-domain tasks and verifiers.EES-Cross composes audited domains through shared entities, roles, policies, and state dependencies.Source: §2 · p. 3
  • Prior preference methods use success–failure pairs or search-based alternatives, whereas this construction branches from restorable EES states and labels divergent turns with verified outcomes.It uses bounded sibling rollouts rather than recursive tree search and executable verification rather than a separate process evaluator.Source: §2 · p. 3

3 VERIFIED DEMONSTRATION CONSTRUCTION

Davinci-ToolData combines demonstrations from authored systems with tasks and verifiers generated in audited executable environments. The resulting corpus spans broad domain and tool coverage, including coordinated cross-domain compositions.

3 VERIFIED DEMONSTRATION CONSTRUCTION

  • Two complementary routes share an execution-and-verification interface: EGTS replays outcome-grounded tasks in authored systems, while EES generates tasks and verifiers in audited executable domains.EES supports individual-domain scenarios and coordinated workflows linked by shared entities, policies, and state dependencies.Source: §3 · p. 4, Figure 2 · p. 4

3.1 EGTS: FROM EXPLORED OUTCOMES TO VERIFIED DEMONSTRATIONS

  • EGTS first explores an authored system to establish an achievable outcome, then synthesizes a request and replays it from the same initial state to construct a verified task-conditioned demonstration.Exploration determines what can be achieved; replay demonstrates how to achieve it for the synthesized request.Source: §3.1 · p. 4

3.2 EES: FROM EXECUTABLE DOMAINS TO VERIFIED TRAJECTORIES

  • EES jointly constructs executable environments, state-grounded tasks, and success criteria, retaining restorable states and predicates for later preference construction.Its audited domains are instantiated as single-domain scenarios or composed domains.Source: §3.2 · p. 5

3.2.1 EES-SINGLE: AUDITED SINGLE-DOMAIN SCENARIOS

  • EES-Single grounds each task in an initialized domain state and uses executable predicates for atomic requirements to verify completion.A mutation target already satisfied in the initial state is regenerated so success requires an interaction-induced state change.Source: §3.2.1 · p. 5

3.2.2 EES-CROSS: COMPOSING DOMAINS INTO COORDINATED WORKFLOWS

  • EES-Cross composes audited domains into shared worlds with explicit entity, state, or policy dependencies before generating coordinated tasks and cross-domain predicates.Tasks can transfer observations or identifiers, enforce operation ordering, or constrain state changes through cross-domain policies.Source: §3.2.2 · pp. 5–6

3.3 ENVIRONMENT COVERAGE AND CORPUS STATISTICS

  • EGTS spans 8 authored environment families, while EES includes 191 audited domains across 19 categories, with 188 domains appearing in retained cross-domain compositions.The mean EES-Cross composition has 2.87 domains; length-controlled analysis also finds domain transitions, entity transfer, and read–write dependencies beyond interaction length.Source: §3.3 · pp. 6–7
  • The retained EES-Cross set contains 246 compositions: 77 with two domains, 124 with three, and 45 with four; 117 span multiple application categories.Another 129 compositions connect distinct systems within one application category.Source: §3.3 · p. 6, Figure 3 · p. 6
  • Davinci-ToolData contains 30,395 verified trajectories, 28,985 distinct normalized requests, and 2,260 invoked tool names across its source inventories.The corpus includes 190,410 tool calls; source-level tool counts overlap and are not additive.Source: §3.3 · p. 6

4 OUTCOME-GROUNDED MODEL TRAINING

Davinci-Tool training first learns from verified demonstrations, then reuses executable EES states and verifiers to construct preferences between alternative decisions. DPO optimizes only the assistant turns where those decisions diverge.

4.1 SUPERVISED FINE-TUNING

  • SFT fine-tunes Qwen3-Coder-30B-A3B-Instruct on 30,395 verified demonstrations, conditioning assistant-token prediction on preceding interaction while keeping tool outputs in context but outside the loss.The resulting policy is used to construct preferences.Source: §4.1 · p. 7

4.2 OUTCOME-GROUNDED PREFERENCE CONSTRUCTION

  • Preference construction branches from SFT rollouts in EES-Single and EES-Cross, using restorable states and a common verifier to compare alternative decisions from the same interaction state.Each branch begins from the same environment state and model-visible context, then continues under greedy decoding; forks are bounded and not recursively expanded.Source: §4.2 · p. 7
  • When sibling candidates have different verified outcomes, their divergent assistant turns become preferred and rejected responses, yielding 1,150 pairs from EES-Single and EES-Cross.Completed continuations, terminal states, and verification records are retained as construction provenance.Source: §4.2 · p. 7

4.3 DECISION-LEVEL PREFERENCE OPTIMIZATION

  • DPO initializes from the SFT policy and optimizes only divergent preferred and rejected assistant turns; downstream continuations determine labels but are not part of the objective.A frozen copy of the SFT policy serves as the reference policy.Source: §4.3 · p. 8

5 EXPERIMENTS

The experiments evaluate Davinci-Tool on three held-out tool-use suites, including transfer to smaller backbones and comparisons with reference models and data-source mixtures. Verified-demonstration SFT supplies the primary gains, while decision-level DPO adds aggregate improvements; the source analyses show complementary but not uniformly additive contributions.

5.1 EXPERIMENTAL SETUP

  • The evaluation uses official protocols for three held-out suites; queries and states are excluded from data construction, and MCP-Atlas includes 89 tasks not requiring external API keys.The section also evaluates training-stage gains, scale transfer, public-supervision comparisons, data-source contributions, and execution behavior.Source: §5.1 · p. 8, §5 · p. 8

5.2 MAIN RESULTS

  • 52.4/30.4/16.9 to 85.1/60.6/52.8: verified-demonstration SFT raises scores on τ 2-bench, BFCL v4, and MCP-Atlas; DPO adds 3.1/2.2/3.4 points, respectively.The category changes vary: τ 2 Retail improves by 6.1 points, BFCL Missing-Parameter by 8.0, while Missing-Function decreases by 1.5.Source: Table 2 · p. 8, §5.2 · pp. 8–9
  • With 1/16 as many total parameters, Davinci-Tool-30B exceeds Qwen3-Coder-480B-A35B-Instruct on all three aggregates; it scores 62.8 on BFCL v4 and 56.2 on MCP-Atlas.Its BFCL v4 score exceeds Qwen3-Coder-480B, Kimi-K2-Instruct, GPT-5.2, and Claude-Sonnet-4.5, while its MCP-Atlas score exceeds Qwen3-Coder-480B and GLM-4.7.Source: Table 2 · p. 8, §5.2 · p. 9
  • Qwen3-8B and Qwen3-14B improve on reported τ 2-bench and BFCL v4 results; under matched 30B settings, Davinci-ToolData beats Toucan-1.5M by 7.4, 18.7, and 30.3 points, respectively.The matched comparison uses the same backbone and SFT hyperparameters, and the Davinci-ToolData corpus is substantially smaller.Source: §5.2 · p. 9
  • Recovered trajectories associate benchmark gains with fewer explicit τ 2 tool errors, fuller BFCL call chains and output-to-argument dependencies, and fewer empty MCP-Atlas retrievals and malformed terminal outputs.MCP-Atlas tool interaction increased, so the reported patterns are not uniformly shorter trajectories.Source: §5.2 · p. 9

5.3 SOURCE-COMPOSITION ANALYSIS

  • Among single sources, EGTS has the strongest BFCL v4 result (57.4), while EES-Cross leads on τ 2-bench (83.4) and MCP-Atlas (47.2).The caption identifies Table 3 as the comparison of SFT data-source mixtures and marks the strongest evaluated mixture on each benchmark.Source: Table 3 · p. 9, §5.3 · p. 9
  • The full EGTS+EES-Single+EES-Cross mixture is strongest among six configurations, but pairwise mixtures are not uniformly additive.Adding EES-Cross to EGTS+EES-Single yields gains of 5.7, 3.0, and 21.3 points across τ 2-bench, BFCL v4, and MCP-Atlas; adding EGTS to EES-Single+EES-Cross yields 2.2, 5.0, and 2.2 points.Source: Table 3 · p. 9, §5.3 · p. 9
  • Source alignment varies by benchmark: EGTS aligns most with BFCL v4 and MCP-Atlas, EES-Single with τ 2-bench, and EES-Cross retains coordinated cross-domain structure after length and tool-call matching.The retained structure includes domain transitions, cross-domain entity reuse, and read–write dependencies.Source: §5.3 · p. 9

6 CONCLUSION

The conclusion presents Davinci-Tool and Davinci-ToolData as an execution-grounded framework for verified supervision, with EGTS and EES supporting demonstrations and decision refinement. The appendices describe a shared interface for restoration, execution, and evidence capture across construction routes.

6 CONCLUSION

  • The framework combines EGTS demonstrations from independently authored systems with audited EES single- and cross-domain supervision; verified-demonstration SFT provides primary gains and transfers to tested smaller models.Restorable EES states and executable verifiers are reused for outcome-grounded decision refinement through DPO.Source: §6 · p. 10

A SHARED EXECUTION AND VERIFICATION INTERFACE

A.1 ENVIRONMENT INTERFACE AND EVIDENCE RECORDS

  • The environment representation includes state space, tools, restoration, transitions, and observable evidence; evidence capture varies by environment type and EES scenarios retain executable verifiers.Mutation-oriented environments retain state snapshots, retrieval-oriented environments retain grounded answer evidence, and synthesized scenarios evaluate executable task predicates.Source: §A.1 · p. 14

A.2 ENVIRONMENT WRAPPING AND EVIDENCE CAPTURE

  • The harness adapts environments to callable tools, reset, outcome capture, and metadata, then records initial state, ordered interactions, execution status, terminal state, and outcome evidence.State-modifying environments can use canonical snapshots with semantically irrelevant volatile fields removed; retrieval-oriented environments retain grounded information from successful reads.Source: §A.2 · p. 14

B TRAJECTORY CONSTRUCTION DETAILS

B.1 EXECUTION-GROUNDED TASK SYNTHESIS

EGTS turns explored outcomes in authored environments into verified, task-conditioned demonstrations, while EES constructs and audits executable domains for state-grounded and coordinated tasks. The resulting EES inventory spans a broad range of domains and compositions.

B.1.1 PROGRESSIVE AND EXPERIENCE-GUIDED EXPLORATION

  • EGTS guides exploration from orientation tools to broader inventories, prioritizing under-used tools and using skill guides, prior traces, and difficulty-dependent retries or rollback.Failed runs retain the longest executable prefix ending in a successful call.Source: §B.1.1 · pp. 14–15

B.1.2 TASK CANDIDATE CONSTRUCTION

  • Task candidates derive from observed mutations or grounded retrieval evidence and are retained when specific, natural, and consistent with the recorded execution.Source: §B.1.2 · p. 15

B.1.3 EXECUTION-DERIVED REPLAY GUIDANCE

  • Replay guidance transfers procedural information from exploration into request-conditioned demonstrations, and acceptance records whether replay recovers the target outcome.The EGTS SFT partition contains 13,824 accepted replay demonstrations.Source: §B.1.3 · p. 15

B.1.4 REPLAY VERIFICATION AND TRAJECTORY AUDIT

  • EGTS verifies mutation tasks against their recorded terminal state and retrieval tasks against grounded answer evidence, then checks trajectory structure, execution, consistency, and quality.Source: §B.1.4 · p. 15

B.2.1 SINGLE-DOMAIN SYNTHESIS AND AUDIT

  • EES synthesizes runnable domains from mined concepts and constraints, then audits tool behavior, state transitions, and rule compliance against each domain contract.Detected inconsistencies trigger revisions before another audit round.Source: §B.2.1 · p. 16

B.2.2 STATE-GROUNDED TASK AND VERIFIER CONSTRUCTION

  • EES grounds tasks in initialized domain states and converts achievable requirements into executable predicates, retaining the state, trace, outcome, and verification record.For state-modifying tasks, already-satisfied targets are regenerated or revised so completion requires a state change.Source: §B.2.2 · p. 16

B.2.3 CROSS-DOMAIN COMPOSITION; B.2.4 CROSS-DOMAIN TASK CONSTRUCTION AND VERIFICATION

  • EES-Cross composes related audited domains into shared contexts with linked entities and policies, then verifies cross-system tasks against calls, state changes, outcomes, and constraints.Source: §B.2.3 · pp. 16–17, §B.2.4 · p. 17

C.1.2 EES DOMAIN TAXONOMY AND USAGE; C.1.3 EES COMPOSITION PATTERNS AND CATEGORY AFFINITIES

  • The EES inventory contains 191 domains across 19 categories; its 246 retained cross-domain compositions use 188 domains and span the full taxonomy.The most frequent category pair is Healthcare and Clinical with Personal Health and Wellness, appearing in 17 compositions.Source: §C.1.2 · pp. 17, 19, §C.1.3 · p. 19

C.1.4 STRUCTURAL ANALYSIS OF CROSS-DOMAIN SUPERVISION

Length-controlled comparisons show that EES-Cross trajectories contain coordination structures absent from EES-Single, rather than differences explained simply by longer interactions. The section also illustrates a composed environment, a cross-domain demonstration, and corpus statistics.

C.1.4 STRUCTURAL ANALYSIS OF CROSS-DOMAIN SUPERVISION

  • EES-Cross introduces domain transitions, cross-domain entity transfer, and read–write dependencies absent from EES-Single, even after matching tool-call counts and interaction lengths.The comparison concerns dependency topology, not an increase in every dimension of structural depth.Source: Table 6 · p. 19, §C.1.4 · pp. 19–20

C.1.5 RECORDED COMPOSITION: INVENTORY, PROMOTIONS, AND ORDERS

  • The recorded inventory, promotions, and orders composition requires namespace separation for duplicate interfaces and semantic links between records.Shared-context and scenario-construction stages establish these relations before task generation.Source: §C.1.5 · p. 20, Table 7 · p. 20

C.1.6 SERIALIZED CROSS-DOMAIN DEMONSTRATION

  • A serialized EES-Cross task links note retrieval and identity resolution to a reminder update and notification-preference report.The retrieved note informs the update, while identity resolution supports ownership checks and settings retrieval.Source: §C.1.6 · p. 20, Table 8 · p. 20

C.2 DETAILED CORPUS STATISTICS

  • 30,395 SFT trajectories comprise 13,824 EGTS, 8,026 EES-Single, and 8,545 EES-Cross examples; 2,260 distinct serialized tool names are invoked.The full corpus has a median serialized length of 9,284 tokens, and 957 trajectories (3.15%) exceed 32,768 tokens before training-time handling.Source: §C.2 · p. 21, Table 9 · p. 21, Table 10 · p. 21

C.3 REPRESENTATION ALIGNMENT WITH EVALUATION TRAJECTORIES

The analysis compares source trajectories with benchmark executions using normalized task, tool, and action views and equal-sized source pools. It finds benchmark-dependent source alignment rather than one source leading across evaluations.

C.3 REPRESENTATION ALIGNMENT WITH EVALUATION TRAJECTORIES

  • Alignment is mean Top-5 cosine similarity to source trajectories after normalizing executions and balancing candidate-pool sizes across the three sources.The measure describes representation-space proximity, not absolute task coverage or execution correctness.Source: §C.3 · pp. 21–22
  • EGTS aligns most closely with BFCL v4 and MCP-Atlas, while EES-Single aligns most closely with τ 2-bench; EES-Cross adds high-ranked neighbors on BFCL v4 and τ 2-bench.Equal-budget leave-one-source-out comparisons show corresponding alignment reductions when EGTS or EES-Single is removed.Source: Table 11 · p. 22, §C.3 · p. 22

C.4 EXECUTION-LEVEL ANALYSIS OF BENCHMARK GAINS

Paired analysis associates benchmark recovery with distinct execution changes, while the appendix details how same-prefix alternatives are generated, verified, and turned into preference pairs.

C.4 EXECUTION-LEVEL ANALYSIS OF BENCHMARK GAINS

  • Across 1,116 matched tasks, 441 changed from failure to success and 78 from success to failure after SFT.Transitions use the original benchmark success criterion, which can include partially correct outcomes.Source: §C.4 · pp. 22–23, Table 12 · p. 22

D SAME-PREFIX PREFERENCE CONSTRUCTION DETAILS

  • Preference construction reuses restorable EES-Single and EES-Cross scenarios after SFT to compare alternative decisions using verified downstream outcomes.The analysis is descriptive: each model contributes one recorded rollout per task, and the original benchmark scoring rule is retained.Source: D SAME-PREFIX PREFERENCE CONSTRUCTION… · p. 23, §D.2 · p. 25

D.1 FORK-STATE COLLECTION

  • For fork-state collection, the collector records up to 10 decision points along a deterministic greedy trunk, including each state, prefix, task, and visible tools.The recorded executable state is immediately before the decision.Source: §D.1 · p. 23

C.4 EXECUTION-LEVEL ANALYSIS OF BENCHMARK GAINS

  • Recovered tasks show benchmark-specific changes: τ 2-bench Retail errors fell from 11.11% to 0.99%, BFCL call coverage rose from 56.41% to 86.01%, and MCP-Atlas calls per task rose from 5.55 to 8.90.MCP-Atlas empty retrievals and protocol-fragment endings also fell from 37 to 0 and 7 to 0, respectively; the analyses do not indicate uniformly fewer tool errors or shorter trajectories.Source: §C.4 · p. 23, Figure 4 · p. 24

D.2 SIBLING GENERATION AND ROLLOUT

  • At each fork, one greedy trunk decision and two sampled alternatives run from the same restored context, with greedy continuations and at most 21 completed paths per scenario.Only fork decisions are stochastic; sibling continuations use temperature 0, and states reached within them do not become new forks.Source: §D.2 · pp. 24–25

D.3 FINAL OUTCOME EVALUATION

  • Each sibling passes runtime and tool checks before its scenario-specific verifier evaluates the completed continuation and terminal state.The collector retains the continuation, terminal state, predicate outcomes, execution metadata, and verified outcome.Source: §D.3 · p. 25

D.4 PREFERENCE-PAIR EXTRACTION

  • Preference pairs require a fully successful and an unsuccessful candidate; complete continuations set the labels, while only the divergent assistant turns form the preferred and rejected responses.Candidate turns are canonicalized, and the primary corpus retains at most one pair per fork with a minimum reward gap of 1.0.Source: §D.4 · p. 25

D.5 PREFERENCE-DATA DISTRIBUTION

The preference corpus contains short alternative decisions compared within longer contexts, and training initializes Davinci-Tool-30B from Qwen3-Coder-30B-A3B-Instruct.

D.5 PREFERENCE-DATA DISTRIBUTION

  • The 1,150 decision-level preference pairs are separate from the 30,395 demonstrations used for supervised fine-tuning.They contain 1,049 distinct prefixes averaging 3,339.8 tokens, while preferred and rejected responses average 68.4 and 69.9 tokens, respectively.Source: §D.5 · p. 25

E TRAINING OBJECTIVES

E.1 TRAINING CONFIGURATION

The training description specifies shared SFT settings, context-length constraints, the demonstration corpus and loss, and the subsequent DPO stage.

E.1 TRAINING CONFIGURATION

  • SFT runs use four epochs, a 1 × 10−5 learning rate, and a 32,768-token training limit; the SFT and DPO settings are summarized in Table 13.Examples exceeding the training limit are truncated; the runs use the same SFT hyperparameters despite varying backbones and corpora.Source: §E.1 · p. 26, Table 13 · p. 26

E.2 CONTEXT LENGTHS AND EVALUATION COVERAGE

  • The 40,960-token serving limit prevented valid MCP-Atlas scores for Qwen3-8B and Qwen3-14B before and after SFT.Accumulated interactions exceeded the limit, and SFT did not change it.Source: §E.2 · p. 26

E.3 SUPERVISED FINE-TUNING

  • The SFT corpus combines 13,824 EGTS, 8,026 EES-Single, and 8,545 EES-Cross trajectories, totaling 30,395 demonstrations.The loss is applied to assistant-token positions; tool outputs remain in context but are excluded from supervised loss.Source: §E.3 · p. 27

E.4 DIRECT PREFERENCE OPTIMIZATION

  • After SFT, 1,150 preference pairs from restorable EES-Single and EES-Cross scenarios train DPO, with only divergent preferred and rejected assistant turns entering the response loss.Complete downstream continuations establish the outcome-based preference labels.Source: §E.4 · p. 27

F ADDITIONAL RELATED WORK

  • The related-work discussion positions the workflow as connecting task-conditioned replay, reusable executable-domain composition, and same-context preference construction.Source: F ADDITIONAL RELATED WORK · p. 27

Related papers

Loading 2610.16867v1…