Sage-A1.5: From Long-Horizon Execution to Scientific Exploration with Capability Composition
Wenjie Lou, Tianshuo Peng, Shiyang Feng, Shengji Tang, Runmin Ma, Ruizhe Chen, Jinxin Shi, Haoyang Peng, Fangchen Yu, Zhijie Zhong, Yuhao Zhou, Yue Fan, Yixin Chen, Yiming Wu, Yiheng Wang, Yigeng Jiang, Yichen Jiang, Yi Xie, Xu Guo, Xiaohan He, Tao Hu, Songtao Huang, Siyu Zhou, Shuaiyu Zhang, Shangheng Du, Qinglong Cao, Kun Li, Jingqi Ye, Hongbin Zhou, Guohang Yan, Zongsheng Cao, Ziyi Wang, Zhuo Liu, Zhiyin Yu, Zhiwang Zhou, Zelin Tan, Yuqing Zhu, Yaoze Zhang, Yang Chen, Xuming He, Xiuliang Liang, Xingjian Guo, Xiang Zhuang, Weiping Shen, Weida Wang, Tianyuan Zhou, Tianlin Ye, Tengyuan Fan, Siyu Yan, Shuo Li, Shuchen Pu, Shengyuan Xu, Shao Zhang, Ran Wei, Qinyuan Qin, Qingyu Yang, Nianchen Deng, Meng Dai, Kuikun Liu, Kaitao Chen
Sage-A1.5 is a 35B MoE agent model that improves long-horizon problem solving through learned orchestration and verification.
How can we train agentic models to move beyond simple task-solving toward composing complex, long-horizon capabilities for scientific and engineering research?
Long-horizon tasks often fail because agents repeat unproductive searches, build on unsupported assumptions, or struggle to manage growing contexts. Sage-A1.5 introduces two learned capabilities: Agentic Orchestration, which allows the model to decompose tasks and delegate work to parallel subagents, and Agentic Verification, which enables the model to autonomously review evidence and revise its strategy mid-execution. These capabilities allow the model to outperform significantly larger systems on complex scientific and engineering benchmarks while maintaining a compact 35B parameter scale.
Paper Primer
Sage-A1.5 treats execution organization as an explicit training target rather than a fixed framework rule. The model learns to coordinate parallel subagents—using exploratory composition to compare hypotheses or constructive composition to integrate sub-problem solutions—and to trigger internal verification points that consolidate history and prune ineffective search paths.
Sage-A1.5 achieves superior performance on complex agentic benchmarks despite its smaller 35B parameter count.
The model outperforms larger models like Kimi-K3, GLM-5.3, and GPT-5.6-sol on FrontierScience-Olympiad, CMT, PinchBench, and IFBench. It consistently matches or surpasses the equally sized Agents-A1 and Ornith-1.5 across all twelve evaluated benchmarks.
The training pipeline integrates multi-domain supervised fine-tuning with mixed-reward reinforcement learning. By using role-specific teacher models to generate trajectories that include intermediate reflections and subagent delegation, the model learns to treat verification and orchestration as native reasoning steps rather than external tool calls.
Why is this model's approach to verification different from standard agent frameworks?
Unlike frameworks that rely on external supervisors or predefined rules to trigger checks, Sage-A1.5 learns to recognize when progress has stalled or conclusions need validation, performing verification within its own reasoning and tool-use process.
What is the primary scope of the "Agentic Orchestration" capability?
It enables the model to manage multiple concurrent subagents with isolated contexts, allowing it to decompose complex tasks into parallel sub-problems and synthesize their findings into a unified result.
Sage-A1.5 demonstrates that scaling agentic performance is achievable by training models to explicitly manage their own execution structure and self-correction, rather than relying solely on parameter scaling or external harness logic.
Introduction: From Coverage to Composition
We expose the need to move from static skill scaling to dynamic capability composition.
Current agentic research emphasizes expanding domain coverage—adding more static skills—yet long‑horizon tasks demand that models dynamically organize and adapt their problem‑solving steps during execution. Without such dynamic composition, agents struggle with growing context, slow exploration, and error accumulation that can derail later decisions.
Capability composition is the ability of an agent to rearrange, delegate, and revise its own sequence of actions as new information arrives, rather than following a fixed, pre‑planned script.
Sage‑A1.5 builds on the earlier Agents‑A1 model by adding two key capabilities. Agentic orchestration lets the model decide how to split work, delegate subtasks to parallel subagents with separate contexts, and merge their findings toward a shared goal. Agentic verification enables the model to detect stalled progress, review the available evidence, and revise its next actions—all within the model’s own reasoning loop, without an external supervisor.
The core shift is from static skill expansion toward dynamic capability composition, enabling agents to self‑organize and self‑correct during long‑horizon problem solving.
Adaptive Agentic Execution
We introduce Agentic Orchestration and Verification to enable dynamic task composition during execution.
Domain‑specific training expands capability coverage, but without a mechanism to organize work the model cannot solve long‑horizon problems efficiently.
Coverage measures how many distinct task domains the agent can address after training.
Orchestration teaches the model to decide *what* work to split, *how* to split it, and *how* to merge the results, turning execution itself into a learnable target.
Subagent 1 returns answer “RESTful JSON API”, status ok, evidence URL 1, no unresolved issues.
Subagent 2 returns answer “PostgreSQL schema with users and orders”, status ok, evidence URL 2, no unresolved issues.
Subagent 3 returns answer “Docker container with Nginx”, status ok, evidence URL 3, no unresolved issues.
The main agent integrates the three pieces into a coherent design document and proceeds to the next phase.
Orchestration lets the model treat parallel design components as independent learning targets, turning a monolithic reasoning problem into a set of coordinated subtasks.
How does Agentic Orchestration differ from naïvely running several agents in parallel?
Naïve parallelism simply executes independent agents and discards their coordination. Orchestration explicitly learns a policy that selects *which* subtasks to run, *what* context to give each, and *how* to merge their structured feedback, turning coordination itself into a trainable capability.
The main agent formulates a high‑level goal and decides whether to act directly or to delegate.
If delegating, it creates a batch of subagents, each receiving a specific subtask description and the shared context.
Subagents execute independently, performing search, reading, or tool calls, and return a structured feedback tuple (answer, status, evidence, unresolved issues).
The main agent aggregates the feedback, resolves conflicts, and either produces a final answer or issues a follow‑up delegation based on the new evidence.
**Figure 4.** Agentic Orchestration in execution and task construction. (a) Independently executing subagents return structured feedback for the main agent’s next decisions. (b) Multiple relation chains are built around a selected answer and combined into one question, with identifying details masked. Their clues provide complementary constraints for parallel investigation.
Verification equips the model with a learned ability to pause, assess its current evidence, and redirect its search when progress stalls or when critical conclusions need confirmation.
After the first search, the model notes “no new evidence” and continues to a second search with a different keyword.
The second search also returns generic material; the model detects a stagnation pattern.
Agentic Verification triggers: the model extracts the current evidence, flags the lack of domain‑specific citations, and issues a verification subtask “Find regulatory documents from FAA or EASA”.
The verification subtask succeeds, returning a PDF of the FAA safety guidelines, which the model then incorporates into the final answer.
Verification turns a dead‑end search into a targeted evidence‑gathering step, preventing the model from wasting budget on irrelevant results.
Why not simply attach an external verifier after the main reasoning instead of learning verification inside the model?
External verification would require a separate harness, introduce latency, and cannot adapt its trigger to the model’s internal state. Learned verification is invoked exactly when the model’s own trajectory signals a problem, keeping the loop tight and fully differentiable.
**Figure 5.** Delegation interface and structured subagent feedback.
Automating Machine Learning Engineering
Automated pipeline builds MLE tasks and trains models via staged fine‑tuning and reinforcement learning.
Large‑scale agentic training suffers from a lack of systematic, reproducible engineering tasks. The pain is that without a curated pipeline, each competition must be hand‑engineered, limiting scalability and consistency. The solution is an end‑to‑end automated MLE pipeline that turns historic Kaggle contests into ready‑to‑train tasks.
The factory is a multi‑agent assembly line that ingests a Kaggle competition, extracts its description and data, and emits a self‑contained task with hidden test splits and a unified evaluator.
Step 1: Competition selector chooses the “Titanic” contest.
Step 2: Data acquisition copies the 8‑row CSV into a workspace directory.
Step 3: Task analysis writes a JSON spec describing “predict survival” and lists the hidden rows (indices 6‑7).
Step 4: Code generator emits a Python script that loads the CSV, trains a logistic model on rows 0‑5, and evaluates on rows 6‑7.
Step 5: Execution runs the script; the evaluator returns 0.85 accuracy on the hidden split.
Step 6: Validation records the result and flags the task as ready for trajectory collection.
The factory guarantees that every generated task has a reproducible hidden test set, enabling unbiased evaluation of long‑horizon solutions.
How does Kaggle‑MLE Factory differ from a standard data‑pipeline script that simply downloads a dataset?
Standard scripts stop at data download; the factory adds three extra layers: (1) it synthesizes a formal task specification, (2) it automatically generates a hidden test split and an evaluator, and (3) it runs a validation step that only passes tasks whose hidden‑test performance meets a quality threshold. These steps are essential for training agents that must learn to reason about unseen test data.
The harness is a tree‑structured experiment manager that records every code revision, its execution result, and the branching decisions that led to it, enabling the model to backtrack, compare alternatives, and persist context across long‑horizon interactions.
Why not just log a linear sequence of code‑execution pairs instead of a tree?
A linear log cannot represent divergent hypotheses; when the model tries alternative fixes, the tree preserves both branches, allowing later comparison of their rewards. Without branching, the model would have to overwrite previous attempts, losing the ability to reason about why one path succeeded while another failed.
Trajectory selection trims noisy tails by cutting off a trajectory at the last successful tool interaction before performance degrades, preserving useful exploration while discarding persistently failing continuations.
Run the interaction harness on a generated task and record all code‑execution pairs.
Identify the best‑performing submission (highest validation score).
If the next submission’s score drops below a threshold, truncate the trajectory at the boundary of the last successful tool interaction.
Otherwise, keep the trajectory through the final submission.
Store prefixes that executed successfully and meet quality criteria as supervised prefixes.
Include full‑horizon optimization trajectories and analysis‑sub‑agent traces for later fine‑tuning.
Two‑stage supervised fine‑tuning first teaches generic coding and tool use, then specializes the policy on MLE‑specific trajectories combined with scientific‑task experiments.
Windowed Interaction Reinforcement Learning (WIRL) groups consecutive experiment results into windows, assigns each window a reward based on solution quality and improvement, and updates the policy after each window.
Automated pipeline construction for MLE tasks enables scalable, reproducible training of agents that can solve long‑horizon engineering problems.
Science-Enhanced Teacher Training
We detail the three‑stage pipeline that builds a science‑enhanced teacher model.
Long‑horizon scientific tasks demand deep reasoning, reliable tool use, and stable multi‑step planning, yet existing models often collapse when required to coordinate these abilities.
**Figure 6 |** Overall framework of the three-stage science-enhanced teacher model training pipeline, comprising capability-guided scientific problem selection, scientific research harness optimization, and trajectory distillation and training to enhance long-horizon scientific research capabilities.
A teacher model trained on curated long‑horizon scientific demonstrations, where problem selection, tool‑augmented reasoning, and trajectory distillation are tightly coupled.
How does the Science‑Enhanced Teacher differ from a standard fine‑tuned model?
Beyond ordinary fine‑tuning, it is trained on trajectories that include explicit tool calls generated by a sandboxed harness, and those trajectories are filtered for tool‑call success and deep reasoning. This injects reliable tool‑use behavior that a vanilla fine‑tuned model never sees.
Epoch 1, Problem 1: the model selects tool S, retrieves a web snippet, then proceeds to answer correctly.
Epoch 1, Problem 2: the model selects tool C, executes a short script, and obtains the correct numeric result.
Filtering keeps both trajectories because they have correct answers and successful tool calls.
Epoch 2 repeats the same two problems; the model now sees both tool‑augmented demonstrations twice, reinforcing the pattern.
The example shows that even with a tiny corpus, the pipeline forces the model to associate specific tool actions with problem types, laying the groundwork for robust long‑horizon behavior.
Collect a diverse pool of scientific problems across domains.
Assess each problem on difficulty, task type, and tool‑benefit; keep medium‑to‑high difficulty items.
Run the strong model with the four‑tool harness inside a sandbox, recording tool calls and observations.
Replay recorded tool results for identical queries to ensure reproducibility.
Filter generated trajectories for answer correctness, reasoning depth, and tool‑call success.
Perform multi‑epoch supervised fine‑tuning on the filtered trajectories to produce the final teacher model.
Recursive Task Evolution
Iteratively expand a few seed tasks into a large, verified task pool.
Open‑source search datasets give only a single fact per query, leaving large‑scale, open‑ended tasks without concrete supervision. This scarcity makes it hard for agents to learn to gather and synthesize evidence across many steps.
Recursive Task Evolution supplies a self‑reinforcing pipeline that turns a handful of high‑quality seed tasks into a thousand‑plus pool of professional‑grade environments, each vetted by separate agents. The process supplies the missing supervision while keeping the reward signal clean.
Think of a biological evolution experiment: a few organisms are placed in a petri dish, random mutations generate offspring, and a selection filter keeps only the viable ones for the next generation. Here the “organisms” are task specifications, the “mutations” are builder‑generated variations, and the “selection filter” is a trio of reviewer‑judger checks that guarantee correctness.
Builder assembles S₁: adds CSV ingestion step, updates report template, and runs the workflow to produce a hidden reference PDF.
Reviewer checks S₁’s package for completeness (all files present, version pins) and flags no missing components.
Judger runs the grader: the produced PDF matches the hidden reference exactly, so S₁ passes.
S₁ is added to the seed pool for the next round; the pool now contains S₀ and S₁.
The example shows how a single mutation can expand the task pool while the reviewer‑judger duo guarantees that the new task remains solvable and professionally realistic.
How does Recursive Task Evolution differ from a naïve self‑generated task pipeline?
In a naïve pipeline the same model both creates a task and judges its answer, which can let the model reinforce its own mistakes. Recursive Task Evolution separates the roles: a builder creates candidates, a reviewer audits them without seeing the builder’s intent, and a judger validates them against an independently generated hidden reference. This three‑agent split breaks the feedback loop and ensures that only objectively correct tasks survive.
Trajectory Collection and Verification
We describe how agents collect trajectories, compress context, and train with unified outcome‑process supervision.
Long‑horizon tasks routinely outgrow a model’s context window, forcing a choice between truncation (losing early steps) and naïve padding (wasting capacity). The resulting loss of crucial early reasoning hampers success on complex problems.
How does Agentic Verification differ from standard reinforcement‑learning reward signals?
Standard RL rewards are typically dense or shaped by the environment at every step. Agentic Verification, by contrast, is a binary outcome check applied only after the trajectory finishes, and it is used together with a separate process‑only loss that still trains the intermediate steps.
To expose the model to both full‑context and compressed‑context experiences, we first collect diverse trajectories, then train with a two‑stage pipeline that mixes outcome‑only and process‑only signals.
Stage I: Gather demonstrations from strong teacher models across multiple harnesses (Claude Code, Codex, internal). Each demonstration is stored as a trajectory $\tau$.
Filter demonstrations with domain‑specific checks, canonicalize tool calls, and retain harness metadata.
Apply token‑masked negative log‑likelihood (Eq 2) to all teacher tokens, ignoring tool outputs.
Sample batches from the mixed distribution $q_{\text{task}}$ (task‑oriented) and $q_{\text{proto}}$ (protocol‑focused) according to mixing weight $\rho$ (Eq 3).
Stage II: From the SFT‑initialized policy, generate student rollouts $x=(d,h,\tau)$.
Compute outcome‑only loss $L_{\text{RL}}$ using the reward $R_{\text{out}}$ (Eq 5) when verification succeeds.
Compute process‑only loss $L_{\text{OPD}}$ via reverse KL between student and teacher token distributions for the same context.
Combine the two losses with sample‑level weights $\lambda_{\text{out}}(x)$ and $\lambda_{\text{proc}}(x)$ (Eq 4).
Compute the student log‑probabilities: $\log\pi_\theta(y_1\mid c_1) = -0.2$, $\log\pi_\theta(y_3\mid c_3) = -0.5$.
Apply the mask: keep only the two teacher tokens, sum the logs: $-0.2 + -0.5 = -0.7$.
Normalize by $N_\tau=2$: $\ell_\theta(\tau) = -\frac{1}{2}(-0.7) = 0.35$.
The loss penalizes the student only for the tokens it is expected to predict, ignoring tool outputs entirely, which keeps the training signal focused on language modeling rather than API semantics.
Training Infrastructure and Supervision
Training infrastructure enables efficient, memory‑aware agent rollouts via process supervision and on‑demand sandboxing.
Agent rollouts must keep intermediate files, tools, and partial results available, yet keeping every sandbox resident would exhaust GPU memory.
Instead of waiting for a final reward, the model receives token‑level teacher scores while the trajectory is still unfolding, letting it correct behavior early.
Token 2 KL: $D_{KL}$([0.7,0.3]‖[0.8,0.2]) ≈ 0.02.
Token 3 KL: $D_{KL}$([0.5,0.5]‖[0.4,0.6]) ≈ 0.02.
Sum of KLs = 0.04; N_$\tau$ = 2 (tokens 2 & 3).
LOPD = (1/2) × 0.04 = 0.02.
Process supervision yields a small scalar loss (0.02) that can be back‑propagated immediately, unlike waiting for a final reward after the whole trajectory.
When an agent pauses for a model response, the sandbox can be swapped out of GPU memory and later resumed, so the host can reuse compute for other agents while preserving the agent’s state.
At start, both agents load the 2 GB base image into GPU memory (total 4 GB).
Agent A creates a 200 MB file; its workspace grows to 2.2 GB.
Agent A pauses; its 2.2 GB workspace is offloaded to host RAM, freeing GPU memory.
Agent B loads its own 200 MB workspace (now only 2 GB base + 0.2 GB = 2.2 GB on GPU).
When Agent A’s model response arrives, its workspace is restored (GPU memory usage returns to 4.2 GB total).
Offloading lets multiple agents coexist on a single GPU by only keeping active workspaces resident, dramatically reducing peak memory usage.
Is pVisor just a checkpoint‑restore system?
No — checkpointing saves a static snapshot of the entire process. pVisor preserves the full sandbox semantics (file system, network policies, and incremental tool state) and can resume exactly where it left off, not merely reload a frozen image.
Benchmark Performance
We report benchmark performance of Sage‑A1.5 across search, engineering, scientific, and general tasks.
Science‑enhanced Teacher boosts FS‑R score from $2.5$ to $70.0$, a +$67.5$‑point gain.
Table 2 shows the teacher achieving $70.0$ versus $2.5$ for the Qwen3.5‑35B‑A3B baseline.
**Figure 1.** Benchmark performance of Sage-A1.5.
**Figure 7.** Agentic Orchestration in a 50-channel research atlas. **Left:** the 13-turn main-agent trajectory, with badges marking delegation and batch sizes. **Upper right:** parallel subagents investigate 50 channels in six successive batches, after which one further subagent examines cross-channel relationships. **Lower right:** the StarPlus subagent tests the delegated Sony attribution against evidence and corrects it to Disney Star / JioStar; the main agent uses this correction in its subsequent relationship assignment and final atlas. Task execution time measures the end-to-end elapsed duration; total research time sums the execution durations of all subagents.
Scientific Discovery Case Studies
Open scientific discovery showcases Sage‑A1.5’s long‑horizon agentic capabilities across case studies.
MLE Teacher attains a 72.7 % medal rate, 34.8 pp higher than the Qwen3.6‑35B‑A3B base model.
Table 6 shows 72.7 % vs. 37.9 % medal rate.
Open scientific discovery demonstrates Sage‑A1.5’s ability to coordinate interdependent research tasks, verify intermediate results, and produce end‑to‑end reports across diverse domains.
Batch 1 launches subagents 1‑8; each gathers channel identity, ownership, and commercial links.
After batch 1 finishes, the main agent aggregates findings and flags channels sharing partners for follow‑up.
Batch 2 launches subagents 9‑16 to investigate the flagged partners, while the main agent updates the research plan.
By batch 6 all 50 channels are processed; the main agent integrates corrections (e.g., StarPlus operator) into the final report.
This parallel‑batch workflow lets the system explore many hypotheses quickly, then steer later batches based on early discoveries.
**Table 6.** Performance comparison between Qwen3.6-35B-A3B and the MLE teacher on MLE-Bench Lite. Results are reported as mean ± SEM over three evaluations (%).
**Figure 8.** Agentic Verification in a multi-hop BrowseComp task. (a) The task identifies an actor’s first wife through clues about film roles, marriages, and family history. (b) Repeated searches fail to establish a reliable candidate. (c) The model autonomously initiates verification, identifying unsupported assumptions and evidence gaps. (d) It revises its search strategy to verify film credits and marital relationships. Red, amber, and green indicate stalled exploration, self-initiated verification, and revised exploration, respectively.
**Figure 9.** Local deployment of Sage-A1.5. Quantized variants of Sage-A1.5 (MoE with 35B total and 3B active parameters) run on heterogeneous hardware, are served by local runtimes through a local inference API, and carry out multi-turn scientific and engineering tasks with local agent tools. All components stay within the local environment (dashed boundary), enabling a fully on-premise agentic workflow.
**Figure 10.** Illustrative preview of a DeepResearch report generated Sage-A1.5
**Figure 11 |** Long-horizon scientific reasoning and self-correction of Sage-A1.5 on a quantum optics task from CritPt (#19). Through hypothesis formulation, tool-assisted verification, conflict detection, error localization and correction, Sage-A1.5 identifies and fixes an error in its numerical verification code, resolves discrepancies between its analytical derivation and numerical calculations, and independently re-validates the results.
**Figure 12 | Real-world and professional workflows.** Representative artifacts from ten engineering, scientific, planning, data and security workflows. Panels show implementation and simulation results, coverage plans, audit findings, data reconciliation and document processing, with key outcomes highlighted.
**Figure 13.** Computational analyses across three scientific domains. (a) Hydrogen delivery costs across 30 simulated sites under 2025 assumptions. The dashed horizontal line marks the assumed European cost of EUR 5.50/kg. (b) Synthetic waveform differences across spherical harmonic modes (n = 1,500 per mode). Boxes show interquartile ranges, center lines indicate medians, and whiskers span the 5th–95th percentiles. (c) O/OH adsorption scaling across six metal surfaces using approximate reference values and analytical estimates. Lines show linear fits.