Argus: A General-Purpose Agentic Runtime for Long-Horizon Reasoning

Verification-Guided Persistence, Pivoting, and Runtime Self-Evolution

Section Summary: Argus is an agentic runtime system designed for long-horizon tasks, where specialized roles such as Manager, Planner, Engineer, and Reviewer work together over durable project state. It maintains a stable record of user intent while allowing evidence-based adjustments to objectives, constraints, and methods, but only after verification by the appropriate roles and task-specific checks, preventing unchecked changes or repeated failures. The system improves through accumulated runtime experience rather than altering its underlying model, leading to measurable gains in efficiency and success across diverse technical benchmarks while preserving detailed records of both successful and rejected paths.

Boxiu Li$^{1,2,,\S}$, Zimo Wen$^{2,,\S}$, Yijia Fan$^{1,*,\S}$, Junxiang Lei$^{3,\ddagger}$, Sufeng Guo$^{4,\ddagger}$, Jiaao Wu$^{5,\ddagger}$, Ruize Tang$^{1,\ddagger}$, Mukai Li$^{6}$, Yifei Shen$^{1}$, Xiaoyu Chen$^{2}$, Wanbo Zhang$^{3}$, Runjing Gu$^{2}$, Yifei Gao$^{2}$, Yuheng Wu$^{2}$, Xuyao Huang$^{2}$, Zelong Zhao$^{7}$, Jiachen Zhang$^{7}$, Shibo Hu$^{8}$, Hangxi Guo$^{9}$, Yilin Chen$^{10}$, Yuzhe Zhang$^{2}$, Fan Yang$^{1}$, Chuan Wen$^{2}$, Xian Zhang$^{1,\dagger}$, Xuanhe Zhou$^{2}$, Zhijie Deng$^{2,\dagger}$
$^{1}$ Microsoft $^{2}$ Shanghai Jiao Tong University $^{3}$ Fudan University $^{4}$ Nanjing University $^{5}$ Tsinghua University $^{6}$ The University of Hong Kong $^{7}$ Independent Researcher $^{8}$ Peking University $^{9}$ The Chinese University of Hong Kong, Shenzhen $^{10}$ Donghua University

$^{*}$ Co-first Authors
$^{\ddagger}$ Co-contributors
$^{\S}$ Co-project Leaders
$^{\dagger}$ Corresponding Authors: [email protected], [email protected]

Abstract

Long-horizon reasoning is not a race to push farther along a fixed route. A capable runtime must persist while evidence supports the current approach, but pivot when measurements expose a failed route, hidden constraint, or misspecified objective. Unrestricted pivoting is indistinguishable from rationalized failure, so each material change must be evidence-backed, role-gated, and recorded. We present Argus, a persistent, self-evolving agentic runtime in which Manager, Planner, Engineer, and Reviewer execute bounded missions over durable project state. Its working contract separates stable user intent from the operational objective, constraints, and verification criteria that evidence may refine. Verification-gated admission makes such refinement cumulative rather than ad hoc: candidate memories, skills, procedures, verifiers, routing decisions, and rejected routes become reusable only after role-owned review and, where available, task-native verifier evidence. The model weights remain fixed, so self-evolution occurs in the persistent runtime state and control policy. Mission execution is autonomous between explicit operator-owned escalation points.

In benchmark runs with autonomous mission execution, the same harness remains effective across seven GPT-5.5 benchmark arenas. It reaches approximately 78% on SWE-Bench Pro versus 59% for Direct Copilot, while using 1.41× the aggregate Tokens. After verification-gated runtime self-evolution, mature SWE-Bench Waves use 21% fewer solve input Tokens and 15% less active workflow time per task than startup Waves. This observational trajectory is not monotone; it also records 34 verifier recoveries and 22 strict review-loop rescues. Across the broader suite, Argus reaches 76.8% on AARRI-Bench research tasks and a 28.0 gap on mathematical data synthesis, alongside competitive GPU-kernel and language-model-training results. Its artifacts extend beyond benchmark endpoints: an optimized RWKV6 kernel was merged into the upstream Flash Linear Attention repository. A multi-day mathematical campaign retains one falsified route and six proof-backed frontier updates; six paper pipelines with autonomous mission execution span 254 missions and 16 Stage rollbacks before reaching submission completion. Two verticals close against external checkers the runtime does not own: an inference accelerator certified for its demonstrated scope, and a materials campaign in which the admitted method is simpler than the published one it replaces. These results show a general, self-evolving harness that can revise, recover, and accumulate verified approaches without forcing every long-horizon trajectory into a success claim. The retained trajectories also form structured data for future supervised and reinforcement learning.

Executive Summary: Argus is a runtime system designed to let AI agents handle long, open-ended research and engineering tasks that may require changing direction as evidence arrives. Current agent systems typically fix an objective in advance and optimize execution toward it. This approach breaks down on real problems because the original goal is often underspecified, unreachable, or simply wrong once work begins. Without a safe way to revise the operational objective, agents either fail silently or produce rationalized but useless results. The document therefore asks whether a single runtime can keep user intent stable while allowing evidence-backed changes to the working plan, record those changes, and improve its own behavior over repeated missions without retraining the underlying model.

The authors built and tested Argus to answer that question. The system divides authority among four roles—Manager, Planner, Engineer, and Reviewer—that operate over a durable project state rather than a single long transcript. Missions are bounded and explicitly completed or blocked. Candidate updates to memory, skills, verifiers, or routing rules enter persistent state only after role-owned review and, where available, task-native evidence. Model weights stay fixed; evolution occurs only in the recorded state and control policy. The evaluation combined seven benchmark suites, a 731-task longitudinal run on SWE-Bench Pro, one detailed mathematical campaign, six complete paper-production projects, a certified chip design, and a materials-generation study.

Across these arenas Argus reached roughly 78 percent accuracy on SWE-Bench Pro compared with 59 percent for a direct baseline, using 1.41 times the tokens. Mature waves of the same run used 21 percent fewer solve tokens and 15 percent less active time per task than the startup waves. Independent review was invoked on 466 of 731 tasks and produced 34 verifier recoveries plus 22 strict review-loop rescues; another 35 tasks were correctly declared blocked rather than completed. The system also posted 76.8 percent on AARRI-Bench research tasks, delivered competitive GPU-kernel and training results, and generated an RWKV6 kernel that was merged into an external repository. All six paper pipelines reached submission, the mathematical campaign retained one falsified route and six proof-backed advances, and two external-checker verticals (a certified inference accelerator and a simplified materials method) closed without the runtime owning the final validator.

These outcomes matter because they show that verification-gated pivoting and fixed-model self-evolution can be made practical at scale. The runtime improves efficiency as shared state accumulates, refuses unsupported completion, and produces artifacts that survive external review. At the same time, the retained trajectories supply structured data that could later be used for supervised or reinforcement learning of long-horizon behavior.

The most immediate next steps are matched frozen-state replay experiments to isolate the contribution of accumulated memory and skills, prospective user studies with real researchers to measure clarification quality and time saved, and extension of the same harness to additional model families and external verifiers. The authors also recommend using the collected trajectories to train stronger internal planning and verification policies.

The main limitations are that the longitudinal efficiency gains are observational rather than causal, public prospective studies of user-guided pivots are absent, and several vertical results are scoped to demonstrated evidence rather than full production certification. Within those bounds the benchmark numbers and recovery statistics are reported with concrete counts and consistent measurement rules.

1. Introduction

Section Summary: The introduction explains that long-horizon work such as research or complex software projects rarely follows a fixed plan, because new evidence often requires revising the immediate goal while keeping the original user intent intact. Existing AI agents avoid this issue by locking the objective in place, but that approach leads to declining performance as tasks lengthen and hidden problems surface. Argus instead treats objective updates as legitimate when they are supported by recorded evidence, performed by distinct roles, and stored in durable project state so that changes remain distinguishable from simple failure or drift.

Long-horizon research is not a race to execute a fixed plan for more steps. In practice, standing intent can remain stable while the operational objective, constraints, and verification criteria become more precise. A mathematical campaign rarely terminates in the theorem it set out to prove: intermediate bounds, counterexamples, and reformulations are the normal output, and they carry real value. A software request is often underspecified until a candidate implementation exposes what was missing. In system verification, the specification and the implementation may both be wrong, and deciding which one to change is itself part of the work. In each case, progress may require revising the operational objective, not only the plan, without silently abandoning the intent that motivated the campaign.

Permitting that revision is difficult because it is externally indistinguishable from failure. A system that abandons its stated target may have discovered that the target was misspecified, or it may have failed and then rationalized. Nothing in the final artifact separates the two. A runtime that allows objective revision without resolving this ambiguity invites goal drift: the objective degrades toward whatever the executor happens to be able to finish. The standard response is to remove the choice, fixing the objective and optimizing execution toward it.

Prior work follows that response. ReAct, SWE-agent, and OpenHands established practical interfaces between models and external environments ([1, 2, 3]). The AI Scientist, CycleResearcher, AutoSci, FARS, and Arbor extend this interaction into iterative research programs covering planning, experiments, review, memory, and scientific communication ([4, 5, 6, 7, 8]). These systems differ in how they search, remember, and review, but they share the assumption that the objective is given. Their reported progress makes the remaining problem visible: agent success declines as software-task horizons grow ([9]), and the horizons that matter most are those over which the objective is least likely to survive unchanged.

We take the opposite position: pivoting should be permitted and made safe by verification. An admissible pivot is supported by evidence that the previous route or objective was unreachable or misspecified, admitted through an explicit role boundary, and recorded so that later missions inherit both the change and its justification. Verification is therefore not a quality filter applied after execution. It is the mechanism that makes pivoting distinguishable from drift.

Three properties must hold before any such certification is possible, and each fails in long-running agents. Continuity fails when a growing transcript is compacted or dropped, so the evidence that motivated a revision no longer exists when the revision is proposed. Acceptance fails when the component that performs the work also declares it complete, so a revision is certified by the party with the strongest incentive to accept it. Experience fails when only the final artifact survives, so refuted routes cannot later be cited as evidence that an objective is unreachable. Hierarchical and workflow-oriented memory systems address parts of this problem ([10, 11, 12]). A larger context window extends session continuity; certifying a change of objective additionally requires explicit state, ownership, and update rules.

We present Argus (Autonomous Research Generation and Understanding System), a general-purpose agentic runtime for long-horizon reasoning. Its central abstraction is a sequence of bounded missions executed against a durable project state. Four model-driven roles divide authority: a Manager anchors the objective and campaign state, a Planner selects the next units of work, an Engineer implements and evaluates them, and a Reviewer inspects artifacts and run outputs before issuing the completion verdict when independent review is required or requested. Allowed low-risk tasks may instead use recorded Engineer self-review. These roles operate across three planes—control, execution, and records—so that scheduling, work, and record keeping remain separable even though they participate in one continuous loop.

At the report level, we summarize the evolving working contract as $K_t=(\iota, o_t, c_t, v_t)$. Here $\iota$ is the standing user intent that the campaign must preserve; $o_t$ is the current operational objective; $c_t$ is the set of known constraints; and $v_t$ specifies the verification criteria at mission $t$. We use $X_t$ for user-visible clarifications, priorities, and unresolved questions. This notation separates an evidence-backed refinement of the operational contract from a silent change of intent. Section 3 formalizes how evidence, recorded verdicts, and the required user or Manager authority admit a material update.

Deployment provides qualitative motivation for this design. Expert users of Argus report that a substantial part of its practical value lies in where it stops: the system declines to continue on an underspecified objective, and that refusal surfaces constraints the user had not stated. Related internal system-verification cases involve real researchers and project-specific details that cannot be disclosed in this report; we therefore record the observed use as qualitative motivation rather than a public prospective user-study result. After initial assignment, the current runtime can execute ordinary rounds unattended and pause explicitly for operator-owned decisions; the public traces do not provide a measured zero-touch rate.

A pivot should not reset the campaign. The runtime self-evolves the approach between the standing intent and the current operational contract: admitted Stages retain attempted routes, measurements, verdicts, accepted and rejected results, reusable skills, verifiers, and routing decisions. Candidate updates enter persistent state only after the authorized role checks the relevant artifacts and task-native evidence; the gate may include an official verifier, independent Reviewer, or explicitly allowed Engineer self-review according to task policy. Model parameters remain fixed, but later missions therefore begin from a changed search policy rather than merely a longer transcript. We call this mechanism verification-gated fixed-model runtime self-evolution. Section 6 reports its longitudinal evidence as observational rather than a controlled learning ablation.

We sharpen this design language into a process-to-capability theory. The final artifact is a projection of a richer typed trajectory; reviewed compression retains the parts needed for later decisions; and an accepted update counts as compounding only when it reduces future task risk or resource cost. This separates three claims that are often conflated: more process information is available, a review gate improves admission quality, and retained state actually helps later work.

Overall, the evaluation asks whether one self-evolving runtime can combine broad task capability, verified accumulation across missions, and sustained research delivery. The evidence is organized in three parts. First, seven benchmark arenas cover software repair, GPU kernels, language-model training, training speed, research-assistant tasks, and mathematical data synthesis. Beyond SWE-Bench Pro, the suite includes 76.8% on AARRI-Bench and a 28.0 mathematical-data gap, both above their reported references; a de-duplicated inventory separately records 41 research artifacts across six programs. Second, the 731-task SWE-Bench Pro trajectory supports longitudinal analyses of Skill/Wiki evolution, verifier recovery, Reviewer intervention, and mature-stage operating cost. Third, vertical evidence tests whether retained state changes later research: one mathematical campaign preserves a falsified route and six proof-backed theorem-frontier updates, while six paper-production campaigns span 254 missions and 16 Stage rollbacks before producing final AAAI- and ACL-formatted manuscripts. Two further verticals carry the same discipline into domains with unforgiving external checkers: a chip certified for its demonstrated scope through mapped synthesis and static timing, and a materials campaign that replaces a published sampling method with a simpler one after removing a confound in the original comparison.

This report makes seven contributions:

C1. We formulate long-horizon research as verified pivoting over a compact report-level contract $K_t=(\iota, o_t, c_t, v_t)$ and explicit user decision state $X_t$, with each variable defined above. The analytical ManagerAdmit operator makes evidence, authority, and provenance requirements explicit without claiming one atomic implementation API.
C2. We present a runtime in which contract refinement is represented through typed, logged, role-owned surfaces rather than one atomic operation or an implicit consequence of replanning. GoalContract revisions, Manager stage transitions, no-go rollbacks, and recorded verdict sources give material changes an author, a precondition, and an audit trail. The same admission discipline gates fixed-model runtime self-evolution: generated memories, skills, verifiers, routing decisions, and rejected routes become reusable only after evidence checks and an authorized commit.
C3. We measure where the runtime spends verification and where it refuses to terminate. Of 731 SWE-Bench Pro tasks, 466 invoke an independent Reviewer and 265 use Engineer self-review. The Reviewer withholds completion on 43 tasks, of which 34 later pass the official verifier and 22 complete the strict review loop; a further 35 tasks are declared blocked rather than reported complete.

A longitudinal view of the same run shows mature Waves using 21% fewer solve input Tokens and 15% less active workflow time per task than startup.

C4. We present a six-project autonomous paper-production case study covering 640 campaign-hours, 254 bounded missions, 576 Engineer rounds, 286 Reviewer revisions, 89 session rolls, and 16 Stage rollbacks, with all six canonical pipelines reaching submission completion. A representative campaign uses seven no-go rollbacks to reframe a failed method search as a 4, 500-row negative-results study, then repairs two late submission defects without resetting the research state.
C5. We reconstruct one mathematical campaign as a role-resolved Agent trace, making the Manager, Planner, Engineer, and Reviewer actions visible across multiple bounded missions, and retaining one falsified route alongside six accepted theorem-frontier updates.
C6. We report a capability floor across seven benchmark arenas in one unified table that preserves each benchmark's backbone, backend, protocol, native metric, and reference, establishing that the verification machinery does not cost end-task performance: on SWE-Bench Pro, Argus reaches approximately 78% accuracy versus 59% for Direct Copilot at 1.41 $\times$ aggregate Tokens.
C7. We report external adoption of an Argus-produced artifact: a TileLang RWKV6 kernel reviewed by an outside maintainer and merged into fla-org:main.

The remainder of the report follows a conventional research-paper organization. Section 2 positions the system against prior agent and autonomous research work. Section 3 formalizes the operating problem; Section 4 presents the runtime; Section 5 and Section 6 describe the evaluation protocol and results; and Section 7–Section 9 discuss interpretation, limitations, and conclusions. The appendix contains detailed experimental tables and notation.

2. Related Work

Section Summary: Recent work has explored autonomous AI systems that handle everything from narrow experiment loops to full research cycles, including idea generation, planning, execution, and review, often using specialized agent roles or multi-agent collaboration. Complementary efforts focus on long-running agents that maintain memory across tasks, learn reusable skills from past actions, and turn detailed execution traces into training data for better reasoning or verification. Evaluation benchmarks have shifted toward measuring complete research workflows rather than isolated tasks, and Argus extends these ideas by emphasizing durable runtime management, explicit review of retained results, and combined benchmarking with ongoing system traces.

2.1 Autonomous Research Systems

Autonomous research systems range from tightly scoped experiment loops to complete research lifecycles. Karpathy's autoresearch repeatedly modifies, trains, and evaluates a model under a fixed compute budget ([13]); AIDE organizes iterative code search for machine-learning improvements ([14]). FunSearch and AlphaEvolve extend evaluator-guided program search to mathematical, algorithmic, and systems problems ([15, 16]). These systems show how a clear objective and an executable evaluator can turn model calls into sustained search.

Full-lifecycle systems add problem selection, planning, experimentation, review, and scientific communication. The AI Scientist introduced an end-to-end research pipeline, while AI Scientist-v2 added agentic tree search and produced a workshop-accepted paper ([4, 17]). Agent Laboratory organizes specialized roles across the research process ([18]), and CycleResearcher closes the loop between automated research and automated review ([5]). More recently, AutoSci proposed a memory-centric system spanning the complete scientific lifecycle, and FARS reported large-scale deployment of fully automated research workflows across 67 fine-grained AI/ML topics ([6, 7]).

A complementary line focuses on scientific ideation and collaboration. ResearchAgent iteratively generates and reviews ideas grounded in the literature ([19]); SciAgents combines knowledge graphs with multi-agent reasoning for materials discovery ([20]); and Co-Scientist uses a multi-agent generate–debate–evolve loop for biomedical hypothesis discovery ([21]). AgentRxiv studies cumulative research through a shared repository of prior work ([22]), while Arbor uses a persistent hypothesis tree and isolated executors to refine long-running research programs ([8]).

Argus belongs to this autonomous-research family but targets the runtime layer beneath any single scientific workflow. It maintains a durable campaign, assigns separate authority to Manager, Planner, Engineer, and Reviewer, and carries accepted results, failed routes, tools, skills, and task definitions across bounded missions. The benchmark suite evaluates software engineering, GPU optimization, model training, research tasks, and data synthesis; a separate mathematical vertical trace examines proof-oriented research depth.

2.2 Long-Horizon Agent Runtimes and Memory

Tool-using agents established the basic interaction loop. Toolformer learns when to invoke external tools ([23]), ReAct interleaves reasoning with environment actions ([1]), and SWE-agent and OpenHands expose repository-scale execution through agent–computer interfaces ([2, 3]). These systems provide the execution substrate for long tasks; autonomous research additionally requires continuity across many sessions, experiments, and changes of direction.

Persistent-memory systems address this continuity from several angles. Generative Agents combine stored observations with reflection and retrieval ([24]); Reflexion retains feedback across attempts ([25]); Voyager accumulates executable skills ([26]); and MemGPT manages multiple memory tiers ([10]). Agent Workflow Memory induces reusable procedures from past trajectories ([11]), while A-MEM organizes memories through agentic linking and retrieval ([12]). Argus combines these ideas with explicit ownership: execution produces candidate updates, review commits the retained form, and the complete event stream remains separate from the bounded working checkpoint.

2.3 Learning from Research Trajectories

Intermediate trajectories are also valuable training material. Process supervision can train stronger mathematical verifiers than outcome-only supervision ([27]). AgentInstruct generates post-training corpora through agentic flows, Agent-FLAN studies data and tuning strategies for agent behavior, and Agent Lightning converts existing agent trajectories into reinforcement-learning transitions ([28, 29, 30]). Test-time-compute studies further show that search and verification should be allocated according to task difficulty rather than by a fixed sampling rule ([31]).

The trajectories retained by Argus connect model outputs to concrete states, tool actions, measurements, artifacts, review decisions, and runtime updates. They therefore serve two purposes: coordinating the next mission online and forming a structured corpus for later supervised, preference-based, or reinforcement learning.

2.4 Evaluation of Research Agents

Software and general-agent benchmarks established repository-level issue repair and multi-environment analytical evaluation as core Agent capabilities ([32, 33, 34]). Research-agent benchmarks increasingly test complete research behavior rather than isolated question answering. MLE-bench packages Kaggle competitions as machine-learning engineering tasks ([35]); RE-Bench compares AI agents with human experts in open-ended research engineering ([36]); AARRI-Bench evaluates granular tasks from the research lifecycle ([37]); and AIRS-Bench targets frontier research-science agents across multiple disciplines ([38]). Together they motivate evaluation in task-native units, with explicit resource accounting and trajectory-level analysis.

This report combines that benchmark view with a continuous system trace. The benchmark suite measures outcomes across seven arenas, while the SWE-Bench Pro and mathematical studies expose runtime evolution, review-driven correction, and cross-mission research progress.

3. Problem Formulation

Section Summary: The section defines dense-intelligence tasks as those needing ongoing invention through search and feedback, many dependent iterations over long periods, and built-in evaluation to confirm real progress rather than mere claims. It models these efforts as persistent campaigns with an objective, starting artifact, and budget, broken into missions that follow a repeating Manager–Planner–Engineer–Reviewer loop across stages that can advance, pause, or roll back while keeping reviewed state intact. Success is measured by an intelligence-density score that tracks how much of the token output actually contributes useful reasoning, effective actions, and valid verification per unit of wall-clock time.

3.1 Dense-Intelligence Tasks

The public Argus formulation defines a dense-intelligence task as one that sustains high-frequency reasoning, tool use, verification, and iteration across a continuous time window until it produces a measurable result ([39]). Three conditions determine whether a task has this shape:

T1. Invention. The answer is not directly retrievable from a manual or database; it must be discovered through search and feedback.
T2. Long horizon. One pass is insufficient. Progress requires many dependent iterations over hours or days.
T3. Verifiability. A task-native evaluator can distinguish genuine improvement from a persuasive but incorrect claim.

The defining loop is therefore proposal $\rightarrow$ execution $\rightarrow$ measurement $\rightarrow$ revised proposal. Performance engineering, security research, scientific search, and quantitative research differ in domain but share this operational structure. The task definition excludes both open-ended ideation without an evaluator and fixed workflows that require time but no new decisions.

We model a campaign by an objective $o$, an initial artifact $y_0$, an evaluation procedure $f$, and a resource budget $B$. The artifact may be code, a model, a dataset, an experimental harness, a proof, or a manuscript. The campaign is divided into bounded missions indexed by $t$, each producing

$ \tau_t=\bigl((s_{t, j}, a_{t, j}, y_{t, j}, e_{t, j}, r_{t, j})\bigr)_{j=1}^{n_t},\tag{1} $

where round $j$ has state $s_{t, j}$, actions $a_{t, j}$, resulting artifact state $y_{t, j}$, observed measurements $e_{t, j}$, and recorded review or admission outcome $r_{t, j}$. A mission must terminate, pause, or transfer control explicitly; continuity belongs to the persistent campaign state rather than an unbounded model session.

Figure 2 contrasts a session-limited trajectory with the persistent runtime model. A session-limited agent eventually spends its budget on reconstruction and repeated work. Argus instead instantiates a recurrent Manager–Planner–Engineer–Reviewer loop inside each campaign Stage. Reviewed state persists below the loop, while Manager-controlled advance, rollback, and rejected branches change the route taken by later missions.

3.2 Role-State and Stage Dynamics

The roles are not four sequential stations that execute once. Within a stage, the campaign repeatedly applies the transition relation

$ M \rightarrow P \rightarrow E \rightleftarrows R \rightarrow M,\tag{2} $

where $M$, $P$, $E$, and $R$ denote Manager, Planner, Engineer, and Reviewer. Reviewer continuation returns work to Engineer; an accepted or blocked verdict returns control to Manager; and a Manager hold or rollback reopens planning. The relation is an explanatory state-machine model of the implemented control flow, not a claim that every transition must invoke a fresh model session.

Let $g_n$ be the current stage after the $n$ th Manager decision. Legal transitions are

$ g_{n+1} \in {g_n, \operatorname{next}(g_n)} \cup \operatorname{prev}(g_n),\tag{3} $

corresponding to hold, advance to the immediate next stage, or rollback to an earlier stage. For the research vertical, the ordered stages are research, plan, benchmark, run, analysis, draft, review, and submission. Stage index and task-native quality need not improve on every cycle: experiments can fail, review can reject a branch, and later measurements can invalidate earlier assumptions. The intended ascent is progress in the accepted frontier over many cycles, not monotonic improvement at each transition.

3.3 Dense-Intelligence Density

The website expresses useful intelligence per unit wall-clock time as

$ \rho_I(T) =\frac{1}{T}\int_0^T \dot{N}_{\mathrm{tok}}(t), \eta_r(t), \eta_a(t), \eta_v(t), dt.\tag{4} $

$\dot{N}_{\mathrm{tok}}(t)$ is the instantaneous rate of token-mediated reasoning and action. The factors $\eta_r(t)$, $\eta_a(t)$, and $\eta_v(t)$ represent the fractions converted into relevant reasoning, effective action, and valid verification. The product is intentionally stricter than token throughput: a run that repeatedly reads the same state, emits activity without changing an artifact, or accepts unchecked claims can consume many tokens while contributing little to $\rho_I$.

Operational efficiency factors.

The three factors describe how work is distributed within an analysis window. For $W$, let $\mathcal{U}_k(W)$ be the attributable units for $k\in{r, a, v}$: observable reasoning segments, executed actions, or verification segments. We define

$ \eta_k(W) =\frac{\sum_{u\in\mathcal{U}k(W)} w(u)q_k(u)} {\sum{u\in\mathcal{U}_k(W)} w(u)}, \qquad 0\leq q_k(u)\leq1,\tag{5} $

where $w(u)$ is the attributable Token count for reasoning and verification, and either one action or its measured cost for action efficiency. The attribution label $q_k(u)$ records conversion into the intended function:

Reasoning efficiency $\eta_r$. A direct unit derives, revises, or rules out a named claim, lemma, blocker, or decision. Repeated context, narrative transitions, and notation-only rewriting are transition cost.
Action efficiency $\eta_a$. A direct action changes an artifact, result set, accepted decision, or explored branch. A falsification action is productive when it certifies a dead branch; retries and interrupted no-op work are tracked separately. State synchronization and packaging form the auxiliary action category.
Verification efficiency $\eta_v$. A direct verification unit compares a named claim with an explicit criterion or artifact, reruns an independent check, identifies a concrete defect, or issues a scoped verdict. Schema repair, reformatting, and checkpoint canonicalization enable review but belong to verification overhead rather than direct checking.

We report a direct-work value and an inclusive value that also counts successful coordination and state maintenance. Equation 4 uses the three factors as a multiplicative bottleneck model. Section 6.5 measures them in the mathematical campaign, and Appendix D gives the full calculation.

3.4 Online Life and Runtime Evolution

The second website object separates model parameters from the operating state around the model:

$ \begin{aligned} H_{t+1} &= U(H_t, \tau_t, E_t, K_{t+1}), \ \theta_{t+1} &= \theta_t. \end{aligned}\tag{6} $

with the public state definition

$ H_t=\left{\text{Memory}, \text{Skills}, \text{Tools}, \text{Verifiers}, \text{Routing}\right}.\tag{7} $

$E_t$ is the subset of results admitted from mission $t$. The equality for $\theta$ is a scope condition: online evolution does not require a gradient update to the underlying model. Section 4 refines $H_t$ into named ownership surfaces, including task/evaluation definitions $Q_t$; subsequent updates treat $Q_t$ as a component of $H_t$. The contract argument records the admitted report-level projection. The update $U$ is partial; many missions change only memory, and some change no reusable component.

3.5 Capability-Set Expansion

Let $C_t$ denote the effective capability set available at time $t$. The website writes verification-gated admission and the desired breadth/depth behavior as

$ \begin{aligned}C_{t+1} &= C_t\cup{c:\operatorname{Verify}(c, E_t)\geq\epsilon}, \W_{t+1} &\geq W_t, & D_{t+1}(d) &\geq D_t(d).\end{aligned}\tag{8} $

where $W_t$ is frontier width across domains and $D_t(d)$ is depth within domain $d$. The inequalities define retention desiderata over validated capability. Skills can become stale, verifiers can be revised, and performance can regress on harder instances. A negative result can still add value by excluding a failed branch even when the effective capability set does not grow.

3.6 Research Value

Dense activity matters only when it produces new, valid, reusable information. The website therefore defines the accumulated research value over horizon $T$ as

$ V_R(T) =\int_0^T \rho_I(t), \Delta I(t), p_{\mathrm{valid}}(t), \eta_{\mathrm{reuse}}(t), dt,\tag{9} $

where $\Delta I(t)$ is information gain, $p_{\mathrm{valid}}(t)$ is the probability that the claimed increment survives review, and $\eta_{\mathrm{reuse}}(t)$ is the fraction that remains useful for later work. Equation 9 separates Token volume from the properties that make a result useful: information gain, validity, and reuse. The experiments measure these components in their native task units.

3.7 The Information Advantage of Process Data

Finally, the public formalization distinguishes the accepted artifact from the trajectory that produced it:

$ D_{\mathrm{process}} ={(s_k, a_k, e_k, r_k, \Delta H_k)}{k=1}^{N} \supsetneq D{\mathrm{final}}={y^\star}.\tag{10} $

The process record contains states, actions, measurements, review feedback, and runtime-state changes, including failed branches omitted from $y^\star$. This additional information can reduce repeated search, guide later analysis, and provide grounded material for later skill construction or evaluation. Argus retains typed, privacy-preserving observations and verdicts rather than private chain-of-thought transcripts.

The set inclusion in Equation 10 can be strengthened into a decision-theoretic statement. Let $P$ denote a typed process record and let $Y=g(P)$ be its final-artifact projection. For a downstream task $q$ with target $Z_q$, loss $\ell_q$, and decision policy $\pi$, define the minimum achievable risk

$ \mathcal{R}q(X) =\inf{\pi}\mathbb{E}!\left[\ell_q!\left(\pi(X), Z_q\right)\right].\tag{11} $


If $Y=g(P)$, then $\mathcal{R}_q(P)\leq\mathcal{R}_q(Y)$ for every downstream
decision problem $q$. The inequality is strict for some $q$ whenever two process
records can yield the same final artifact while implying different optimal next
actions. The proof is immediate: every policy using $Y$ can be reproduced from
$P$ by first applying $g$, while the reverse simulation need not exist. This is the
Blackwell-information ordering specialized to a research trajectory
 ([40]).

Dominance is informational, not computational. A raw trajectory can be too large, stale, or contradictory to use efficiently. For a context budget $b$, the relevant object is therefore a typed compression $\psi(P)$ that trades downstream risk against retrieval and validation cost:

$ \psi_b^\star =\arg\min_{\psi:, \operatorname{size}(\psi(P))\leq b} \mathbb{E}_{q\sim\mathcal{D}} \left[\mathcal{R}q(\psi(P))+\lambda_c C{\mathrm{read}}(\psi(P))\right].\tag{12} $

Equation 12 explains why an append-only event tape and a bounded reviewed checkpoint serve different purposes. The tape preserves the more informative experiment; the checkpoint approximates a decision-useful compression under a finite context budget. Failed branches belong in the compression when they change the next optimal action, not merely because they occurred.

3.8 Reusable State and Compounding Intelligence

Process data compounds only when an admitted state update improves later work. Let $H_t\oplus\Delta H_t$ denote the state after accepting mission $t$, and let $q_{t+1:t+L}$ be the next $L$ tasks. We define the discounted reuse value

$ G_L(\Delta H_t) =\sum_{j=1}^{L}\gamma^{j-1} \left[\mathcal{R}{q{t+j}}(H_t) -\mathcal{R}{q{t+j}}(H_t\oplus\Delta H_t) \right].\tag{13} $

$G_L>0$ means that the accepted memory, skill, verifier, routing rule, or certified dead branch reduces future loss under a prespecified task distribution. $G_L<0$ captures negative transfer. This definition turns "compounding intelligence" from monotone rhetoric into a counterfactual claim: reuse must outperform a frozen state on matched future tasks. Workflow-memory experiments show that induced reusable routines can improve success and reduce steps ([11]). Section 7 connects this quantity to the current Argus traces.

The website's density and research-value equations can then be joined into a protocol-specific verified reusable yield:

$ \mathcal{Y}{\mathrm{PRI}}(W) =\frac{ \sum{t\in W}p_{\mathrm{valid}, t} \left[\Delta I_t+\lambda_g G_L(\Delta H_t)\right] }{ \sum_{t\in W}N_{\mathrm{tok}, t} }.\tag{14} $

$\Delta I_t$ is immediate task-native information gain, such as a score improvement, theorem strengthening, or certified branch elimination; $p_{\mathrm{valid}, t}$ is estimated by an external evaluator or a calibrated review procedure; and $G_L$ measures future reuse. $\lambda_g$ converts immediate and future value into one protocol-specific unit. Equation 14 connects immediate research output to future reuse. The current substitutions are reported in Appendix D.

3.9 Review as Selective Error Correction

Let $C$ denote whether a proposed state increment is correct, $A$ whether the Reviewer accepts it, $p=\Pr(C=1)$ the proposal base rate, $\alpha=\Pr(A=1\mid C=1)$ Reviewer sensitivity, and $\beta=\Pr(A=1\mid C=0)$ false-acceptance rate. Bayes' rule gives

$ \Pr(C=1\mid A=1) =\frac{\alpha p}{\alpha p+\beta(1-p)}.\tag{15} $

If $\alpha>\beta$, accepted state is more precise than the proposal stream; review acts as a selective error-correction channel. Its operating point balances accepted precision, recall, and Token cost. Section 6 reports the observed repair and recovery rates.

3.10 Role-Resolved Vertical Traces

Endpoint metrics do not show how an Agent system actually conducts research. We therefore project each mission trajectory in Equation 1 onto the four role-owned actions

$ \phi(\tau_t)=\left(m_t, p_t, x_t, r_t, \Delta H_t\right),\tag{16} $

where $m_t$ is the Manager's objective or stage decision, $p_t$ is the Planner's bounded task and dependency decision, $x_t$ is the Engineer's artifact-producing execution, $r_t$ is the structured completion decision together with its source, and $\Delta H_t$ is the durable state update exposed to later missions. The decomposition makes two authority constraints explicit: only the Manager changes campaign stage, while mission completion records either an allowed Engineer self-review or a required/requested independent Reviewer verdict. Vertical policy and stage-closing tasks prevent Engineer self-certification where independent review is mandatory; the Planner may propose future work but cannot certify the mission.

A vertical trace is useful when these tuples remain linked across many missions. It shows whether the objective survived failures, whether the Planner consumed previously accepted state, whether the Engineer changed real artifacts, whether the Reviewer rejected or redirected incomplete work, and which decisions became inputs to the next mission. This explanatory model organizes the Agent workflow; Section 6.5 applies it to one mathematical campaign.

4. Argus Runtime

Section Summary: Argus is a runtime system that organizes AI-driven research into long-running campaigns divided into short, bounded missions, each handled by distinct roles for planning, execution, review, and oversight. It separates concerns across a control plane for scheduling, an execution plane for actual work with tools, and a record plane for immutable logging, while using a shared checkpoint file to maintain state across sessions and enable clean restarts. Completion decisions are made explicit, allowing an engineer to self-review only low-risk tasks while requiring independent review for others, with all steps captured in structured traces for traceability and recovery.

4.1 System Overview

Argus is a general-purpose agentic runtime built around four model-driven roles and three system planes. The control plane anchors the campaign and schedules work; the execution plane performs one bounded mission against real tools and artifacts; and the record plane stores what happened without deciding whether the work is scientifically complete. The distinction is operational: control owns scheduling, execution owns work and mission review, and the record plane owns the immutable record but no completion decision.

The four roles divide research authority as summarized in Table 1. The Manager spans the campaign rather than one execution round. The Planner authors future work and the Engineer performs it. Mission-level completion has an explicit source: allowed low-risk bounded work may use Engineer self-review, while vertical policy, stage-closing tasks, or the Engineer's own request require an independent Reviewer. The interfaces are structured objects rather than untyped prose, which makes ownership and recovery behavior explicit.

::: {caption="Table 1: Role separation in Argus. The Engineer executes and may self-review allowed low-risk bounded work; mandatory or requested independent review belongs to the Reviewer."}

:::

**Input:** standing intent $\iota$, contract $K_t$, user state $X_t$, runtime state $H_t$, backlog $B$, budget $b$
$c \leftarrow \operatorname{ManagerCommit}(\iota, K_t)$; persist campaign identity
**while** $b$ remains and $c$ is not complete **do**
  $q \leftarrow \operatorname{Planner}(B, H_t, c, K_t)$; claim one bounded task
  $\Gamma_t \leftarrow [\,]$; initialize round-level operational records
  **repeat**
    $(y, e, d) \leftarrow \operatorname{Engineer}(q, H_t)$
    **if** $d=\texttt{\small skip}$ and $\operatorname{SelfReviewAllowed}(q)$
      $r \leftarrow \operatorname{EngineerSelfReview}(q, y, e)$
    **else** $r \leftarrow \operatorname{Reviewer}(q, y, e)$
    append $(q, y, e, r, r.\texttt{\small source})$ to $\Gamma_t$
    **if** $r=\texttt{\small continue}$ **then** $q \leftarrow r.\texttt{\small next\_action}$
  **until** $r\in\{\texttt{\small done}, \texttt{\small blocked}, \texttt{\small paused}\}$
  $\tau_t \leftarrow \operatorname{TraceProjection}(\Gamma_t)$
  $(e_t, r_t) \leftarrow \operatorname{AdmissionEvidence}(\tau_t)$
  $E_t \leftarrow \operatorname{AdmitResult}(\tau_t)$
  $(X_{t+1}, K_{t+1}) \leftarrow (X_t, K_t)$
  **if** evidence proposes material refinement $K'_t$ **then**
    obtain required user authority $u_t$
    $(X_{t+1}, K_{t+1}) \leftarrow \operatorname{ManagerAdmit}(X_t, K_t, K'_t, e_t, r_t, u_t)$
  $H_{t+1} \leftarrow U(H_t, \tau_t, E_t, K_{t+1})$; persist outcome, trace, and state
  $t \leftarrow t+1$; refill $B$ when required
**end while**

**Output:** accepted artifacts, inspectable trajectory, admitted contract, and updated runtime state

Here ManagerAdmit is the analytical projection defined in Section 3: it summarizes coordinated updates across persisted contract revisions, operator questions, replanning, Manager transitions, and provenance. It is analytical projection shorthand, not one atomic production application programming interface (API). If the evidence does not justify a material refinement, both the standing contract and user-decision state carry forward unchanged.

4.2 Bounded Missions over Durable State

The long-lived object in Argus is the campaign, not a provider transcript. A campaign has a persisted identity and objective; its work is divided into missions that have explicit outcomes. The scheduler assigns one mission at a time, records its result, and advances only at a clean mission boundary. Mission assignment is transactional, preventing duplicate work under concurrency, and resumed execution is tied to the persistent campaign identity.

Engineer and Reviewer calls use fresh provider sessions for each round. Cross-session continuity comes from an ordinary shared CHECKPOINT.md containing durable state, evidence references, open questions, and the next step. This follows the broader move from monolithic context toward managed memory tiers and reusable workflows ([10, 11, 12]). The Engineer updates the checkpoint after execution. When independent review is invoked, the Reviewer reads and corrects the same file and is its final editor for that round; on an accepted self-review path, the Engineer's version remains the handoff. The full history remains in artifacts and the event record.

This design makes restart and upgrade behavior part of the method. A running process hands off only at a mission boundary, and the replacement resumes from the same persistent campaign identity. After an interruption, replay or reassignment begins from committed campaign state rather than reconstructing the task from a model transcript.

4.3 Review and Completion

All role invocations pass through a common instrumentation layer that records usage and associates each call with the mission trace. The Engineer and Reviewer share the same artifact state, allowing review of the actual outputs and execution record rather than only the Engineer's summary. A typed, append-only trace is the canonical timeline; user interfaces are projections over that record.

The source of a mission completion verdict is explicit. When self-review is enabled and no vertical or task policy requires independence, an Engineer may select review=skip; its prompt restricts that choice to low-risk bounded work with a passing verifier. The runtime accepts the explicit agent judgment without adding a second heuristic or validator and records review_source=engineer_self_review. Otherwise a fresh Reviewer returns the structured verdict, and stage-closing or vertical-required review cannot be waived. Completion never comes from filenames, Token volume, or prose keywords. The corresponding artifacts and execution records remain inspectable, while credential redaction and result provenance preserve the selected verdict source.

4.4 Verification-Gated Fixed-Model Runtime Self-Evolution Equation 6 separates the model from the state around it.

Table 2 identifies how each component can change and who owns the committed update. The ownership model is intentionally not uniform. Memory and skills use a work-versus-certification split: the Engineer or Scientist produces a candidate, and the Reviewer commits the retained form. Tools and procedures are system-configured. Stage checklists are Planner-owned, with Reviewer feedback rather than a second commit gate. Routing policy is Manager-committed, while task definitions are Planner-authored and scheduler-committed.

We use verification-guided for the overall control policy that decides whether to persist, stop, or pivot, and verification-gated for the narrower admission condition on reusable updates. We use runtime self-evolution in a deliberately narrow, fixed-model sense. The underlying model parameters remain unchanged; what evolves is the persistent state that later missions retrieve or obey. Verification-gated is the umbrella term used in this report: a generated candidate is not reusable merely because a role produced it. Admission requires the task-native evidence that exists for that surface and a commit by its authorized owner. Depending on policy and risk, this can combine an official executable verifier with independent Reviewer judgment, permitted Engineer self-review, or a Manager, Planner, Scheduler, or system-configuration commit. It does not mean that every low-risk update requires an independent Reviewer. We use Reviewer-gated only for the independent-Reviewer path and external grader only for a task-native evaluator outside the role loop.

A complete update cycle has four parts: (1) an execution trajectory produces a candidate memory, skill, procedure, verification rule, routing decision, or task definition; (2) the responsible role checks the candidate against artifacts and task-native evidence; (3) the authorized owner commits, revises, or rejects the update; and (4) a later mission retrieves the retained state as part of its starting context or execution policy. Activity that does not survive this commit-and-reuse path is not counted as self-evolution.

::: {caption="Table 2: Attributable ownership of fixed-model runtime evolution. A mission usually updates only a subset of these components."}

:::

Two knowledge surfaces carry reusable experience. Versioned skills store procedures that can be matched to later tasks. A project knowledge base stores source-linked records and synthesized pages derived from reviewed outcomes. Neither surface is treated as automatically correct: entries can be revised, archived, or retired when later results contradict them.

This mechanism can improve a later mission without changing the model itself. A verified retained failure can prevent a repeated dead end; an admitted procedure can shorten environment inspection; a verifier can reject a previously accepted shortcut; and a routing update can assign independent review to a higher-risk task. The mechanism does not imply monotonic improvement. Some missions commit no reusable state, retained state can become stale, and a harder task distribution can increase cost even after useful state has accumulated.

4.5 Reliability and Resource Governance

Long-running systems fail through operational drift even when individual model calls are strong. Argus therefore combines round-level progress classification with mission-boundary replanning. Work that repeatedly produces no decision or artifact change is stopped or reformulated, while long-running external jobs are tracked separately from model reasoning. These mechanisms bound execution; scientific correctness remains with the task evaluator and the explicitly selected Engineer-self-review or independent-Reviewer judgment path.

Resource accounting is centralized at model-call and external-job boundaries. Budgets are checked before work begins and reconciled after completion, preventing individual roles from expanding their own allocation. Concrete scheduling, sandboxing, and deployment mechanisms are implementation choices rather than part of the scientific claim.

5. Empirical Methodology

Section Summary: The section describes how Argus is tested across seven diverse benchmarks that measure performance in software repair, GPU optimization, model training, and related tasks, each using its own native metrics rather than a combined score. It outlines four research questions focused on overall results, whether the system becomes more efficient over time with fixed underlying models as it accumulates knowledge, how often an independent reviewer is needed and how often it rescues failed solutions, and what mechanisms drive any observed gains. The methodology details the use of SWE-Bench Pro for in-depth runtime and reviewer analyses, along with trace protocols and mappings from theory to specific measurements.

We evaluate Argus across seven benchmark arenas spanning software repair, GPU-kernel optimization, language-model training, training-speed optimization, research-assistant tasks, and data synthesis. Each benchmark is reported in its native unit. SWE-Bench Pro is one benchmark in this suite; its sequential task log also enables deeper analyses of runtime evolution and Reviewer intervention.

5.1 Research Questions

RQ1: Benchmark performance.

What task-native outcomes does Argus achieve across the seven benchmark arenas, and how do they compare with the reference reported for each arena?

RQ2: Fixed-model runtime self-evolution.

Within the SWE-Bench Pro run, how does solve-time resource demand change as reviewed Skill, Wiki, verification, and routing state accumulates while the underlying model parameters remain fixed?

RQ3: Reviewer routing and recovery.

Within the same SWE-Bench Pro run, how often is an independent Reviewer invoked, and how many initially rejected solutions are recovered after Reviewer feedback?

RQ4: Process-to-capability mechanisms.

How do the retained traces quantify process-data advantage, verification-gated correction, Token conversion, and cross-task reuse?

5.2 Benchmark Suite

SWE-Bench Pro evaluates repository-level software-engineering tasks with executable acceptance tests ([41]). The remaining arenas evaluate B200 kernel optimization, nanochat training on B200 and H100, the nanoGPT speedrun, AARRI-Bench, and Math-Reasoning Data Synthesis from the Arbor suite ([42, 43, 13, 44, 37, 8]). Because rank, bits per byte, elapsed time, solve rate, and pass-gap are incompatible metrics, we do not average them into one score.

::: {caption="Table 3: Definitions of the seven benchmark arenas. B200 and H100 nanochat runs are kept separate because hardware changes the optimization problem."}

:::

The six non-SWE arenas use GPT-5.5 through Codex. The SWE-Bench Pro evaluation uses GPT-5.5/xhigh through Copilot for both Direct Copilot and Argus. The full 731-task comparison reports approximate accuracy and the aggregate Token ratio

$ R_{\mathrm{tok}} = \frac{N_{\mathrm{Argus}}^{\mathrm{total}}} {N_{\mathrm{Copilot}}^{\mathrm{total}}} \approx 1.41.\tag{17} $

Raw Copilot Token totals and per-Wave resource traces were not retained; therefore the longitudinal analysis is Argus-only.

5.3 SWE-Bench Pro Runtime Self-Evolution Analysis

For a completed Argus Wave $w$ with task set $\mathcal{T}_w$, we measure

$ \begin{aligned} \bar{I}_w^{\mathrm{solve}} &= \frac{1}{|\mathcal{T}w|} \sum{i\in\mathcal{T}_w} I_i^{\mathrm{solve}}, \quad\text{(a)}\ \bar{T}_w^{\mathrm{agent}} &= \frac{1}{|\mathcal{T}w|} \sum{i\in\mathcal{T}_w} T_i^{\mathrm{agent}}. \quad\text{(b)} \end{aligned}\tag{18} $

$I_i^{\mathrm{solve}}$ contains all model calls in the accepted task trajectory, including routing, Skill adaptation, execution, and any independent review. $T_i^{\mathrm{agent}}$ measures active workflow time. Orchestration wait, environment preparation, external verification, infrastructure recovery, and post-task knowledge maintenance are excluded.

Completed Waves are summarized by task-weighted windows: W1–6 (startup), W7–12 (early reuse), W13–18 (composition shift), W19–22 (mature operation), and W23–24 (late difficult tasks). Two incomplete Waves are omitted from the grouped means. The primary comparison is startup versus mature operation; composition and difficulty variation remain visible.

The unit of analysis is the observed sequential window, not a matched task pair. The startup window begins with less project-specific state, whereas later windows can retrieve reviewed repository knowledge, reusable procedures, prior failure records, verification guidance, and updated routing decisions. Lower Token or time demand in a later window is therefore consistent with runtime self-evolution when the retained state removes repeated inspection or failed work. It is not, by itself, a causal estimate of the value of that state. Task identity, repository mix, execution latency, and difficulty also change across Waves, and no matched frozen-state replay is available.

5.4 SWE-Bench Pro Reviewer Analysis

A task is Reviewer-invoked when its final trajectory contains an independent Reviewer model call; otherwise it follows Engineer self-review. A Reviewer verdict of continue is a revision request. We report both subsequent official verifier success and the stricter case in which a later Reviewer verdict is done. The latter is called a strict Reviewer rescue.

Reviewer routing is adaptive rather than randomized. The analysis reports routing, revision, and recovery behavior over the observed task sequence.

The 41-artifact research portfolio is reported separately as a measure of research program breadth.

5.5 Representative Vertical-Trace Protocol

To complement endpoint and software-trajectory measurements, we report one Erdős–Gyárfás mathematical campaign as a representative vertical trace. The trace is role-led rather than theorem-led: it records what the Manager, Planner, Engineer, and Reviewer did during recovery, problem selection, route testing, proof production, revision, acceptance, and state retention. The reported record contains one accepted route falsification and six proof-backed research deltas; detailed mathematical statements remain in the supplementary claim table.

The protocol tracks whether the runtime retains a falsified branch, carries named blockers across missions, and admits later work after artifact-based review. The role trace, claim table, and figure provenance are released with the supplementary materials.

5.6 Theory-to-Measurement Mapping

We map the theory to four reported quantities. Immediate information gain $\Delta I_t$ is represented only in task-native units: benchmark improvement, accepted theorem delta, or certified branch elimination. Review correction is represented by Reviewer continue–revise trajectories and later external-verifier outcomes. Reuse value $G_L$ is approximated observationally by later Token/time demand as Skill and Wiki state accumulates. Token conversion is represented by the role- and mission-level attribution in the mathematical case. Appendix D records the corresponding substitutions in their native units.

6. Results

Section Summary: The results section shows that a single AI-driven runtime achieved competitive performance across seven distinct technical benchmarks, from software engineering to kernel optimization, without being locked to any one model or execution environment. It also earned nine Kaggle medals in an ongoing machine-learning competition track, with several narrow wins verified against official leaderboards, and demonstrated an upstream code contribution that was merged into an external open-source project. Analysis of the largest benchmark further highlights how the system routes harder tasks to independent review, sometimes requests revisions, and can explicitly decline to claim success on unsolvable problems rather than forcing an answer.

6.1 Capability Floor Across Seven Arenas

Table 4 is the primary empirical summary and reports all seven benchmarks in one comparison; Table 3 defines the task and metric for each row.

::: {caption="Table 4: Results across seven benchmark arenas. Values remain in task-native units and are not cross-normalized. Backbone denotes the model driving the research agent; Backend denotes the execution surface."}

:::

The runtime is not bound to one backbone or one execution surface. A separate SWE-Bench Pro run replaces GPT-5.5 on Copilot with GLM-5.2 at a 200K-token context window, driven through Claude Code, and is currently at 70.94% accuracy. That run is still in progress and has no matched Direct baseline on this backend, so we do not enter it in Table 4 or in any longitudinal analysis; we note it because the runtime carried the same contract, routing, and Reviewer policy onto a different model and a different agent surface without re-instrumentation.

As a small upstream-adoption example, an Argus-optimized TileLang RWKV6 kernel was reviewed by a Moonshot AI-affiliated FLA collaborator and merged into fla-org:main (pull request (PR) #1045; commit c70f11c); Appendix E records the technical details.

An eighth arena is in progress and is reported here as a partial result. The MLE-Bench Lite campaign runs the official MLE-Bench Low split ([35]) under a reviewer-approved medal gate: a competition counts as complete only when an independently reviewed submission earns a Kaggle medal, so the reported outcomes are medals rather than raw leaderboard positions. Table 5 lists the competitions closed to date: nine medals, evenly split into three gold, three silver, and three bronze. The gate is narrow rather than nominal. On denoising-dirty-documents the campaign settled 0.00009 RMSE short of the silver band, and on jigsaw-toxic-comment-classification-challenge it cleared the bronze threshold by 0.00018 AUC; both outcomes were awarded by the external grader against the official Kaggle leaderboard, not by internal review. Two further competitions were graded without reaching a medal: dog-breed-identification finished above the median after twelve submissions, and new-york-city-taxi-fare-prediction remained below it after four. The transparent-conductor result is also a verification-gated route change: the external grader rejected the initial approach at 0.208 RMSLE, the campaign replaced it with a public-state-of-the-art method, and the grader then certified the replacement inside the medal band at 0.06402 against a 0.06582 bronze threshold. The remaining competitions continue to run; we exclude this arena from Table 4 and will report the full split on completion.

::: {caption="Table 5: MLE-Bench Lite competitions closed with a medal by Argus so far. Arrows give the direction of improvement: area under the ROC curve (AUC) is maximized, while log loss (LogLoss), root mean squared error (RMSE), and column-wise root mean squared logarithmic error (RMSLE) are minimized. Each score is the Reviewer-approved submission that the external MLE-Bench grader scored, and each medal is the grader's award against that competition's official Kaggle leaderboard. Seven of the nine rows are reconciled against the 2026-07-29 reviewer-approved campaign snapshot, which records 40 graded submissions across nine competitions. The campaign is still running, so this table reports the competitions closed to date rather than a final standing."}

:::

The table shows one runtime reaching competitive outcomes across heterogeneous tasks. The remainder of this section analyzes the SWE-Bench Pro row because it provides a long sequential trajectory and Reviewer decisions.

6.2 Knowing When to Stop: Verification Routing and Non-Termination

Objective revision is admissible only if the runtime can withhold completion. This subsection measures where independent verification is spent and where the runtime declines to declare a task finished.

Of 731 tasks, 466 (63.7%) invoke an independent Reviewer, while 265 (36.3%) use Engineer self-review. The Reviewer requests another implementation round on 43 tasks. After revision, 34 pass the official verifier and 22 complete the strict continue $\rightarrow$ revision $\rightarrow$ done loop. A further 35 tasks receive a blocked verdict, recording that the runtime cannot complete them rather than emitting an unsupported completion. Refusing to stop early and refusing to claim success are two expressions of the same gate.

Reviewer-routed tasks consume 2.75 $\times$ as many solve input tokens and 1.80 $\times$ as much active time as self-reviewed tasks on average, indicating that the routing policy selects a harder workload. The recovery funnel is therefore more interpretable than a raw group-accuracy comparison.

Figure 3 separates the routing population from the revision-recovery path. The accepted and revise branches partition outcomes after Reviewer invocation together with 35 blocked cases; verifier pass and strict rescue are nested recovery milestones among the 43 revision-requested tasks.

$**Figure 3:** Adaptive Reviewer routing and revision recovery. Panel (a) shows that 466 of 731 tasks invoke an independent Reviewer, while 265 use Engineer self-review; routed tasks consume 2.75 $\times$ the solve input Tokens and 1.80 $\times$ the active time on average. Panel (b) follows the routed workload: 388 tasks are accepted on first review, 43 receive a revision request, 34 of those later pass the official verifier, and 22 complete the strict review-loop rescue. Routing is task-dependent; a randomized-routing run would additionally isolate the causal effect.$

6.3 Cost of the Mechanism as State Accumulates

Figure 4 shows the Argus-only longitudinal trajectory. Here, self-evolution refers to changes in persistent runtime state, not to online training of the underlying model. Across Waves, accepted trajectories can update repository knowledge, reusable Skills, verification guidance, task definitions, and routing policy. These objects alter what later missions retrieve, which checks they run, and where they spend independent review.

Mature operation W19–22 uses 21% fewer solve input Tokens and 15% less active workflow time per task than startup W1–6. This pattern is consistent with accumulated state reducing repeated inspection, rediscovery, or failed execution. The lowest-Token window, W13–18, reaches a 50% reduction from startup but requires more active time, showing that Token efficiency and execution latency do not move together. The final difficult-task window rebounds in both metrics.

The trajectories show a lower-cost mature operating window together with visible task-composition and late-wave difficulty effects. The rebound in W23–24 prevents the startup-to-mature comparison from being read as monotonic improvement. Because the task sequence is not replayed against a frozen runtime state, the evidence characterizes system-state accumulation over this sequence; attributing the reduction to an individual memory or Skill update calls for a matched frozen-state replay.

6.4 Measured Process Quantities

The process theory is instantiated from two complementary traces. In the mathematical campaign, direct reasoning, verification, and action each account for approximately 56% of their respective attributed units. In SWE-Bench Pro, Reviewer revision requests lead to 79.1% official-verifier recovery and 51.2% strict review-loop rescue, while the mature window uses 21% fewer solve input Tokens and 15% less active time than startup. Appendix D gives the complete substitutions for the density, reuse, yield, and compression quantities.

The public research inventory additionally contains 41 de-duplicated artifacts across six programs, illustrating the range of research programs executed by the same runtime.

6.5 Objective Revision in a Mathematical Campaign

Figure 5 follows the retained mathematical claim frontier inside one real campaign. The case begins with an open-ended research objective. The Manager preserves that goal through budget and process failures; the Planner turns the current reviewed state into bounded work; the Engineer retrieves sources, runs tools, and writes research artifacts; and the Reviewer decides whether the work is accepted, revised, or blocked before it can enter durable state.

The trace makes the work allocation concrete. The Manager recovers the campaign and owns stage transitions. The Planner first selects a cheap falsification test, then proposes changing the success contract from "collect observations" to "produce a proof"; the Manager admits that refinement, and later requires new missions to advance the retained result rather than restart from an easier fact. The Engineer performs the domain work—source retrieval, executable checks, proof writing, and result packaging. The Reviewer rejects an overstated route, requests the missing checks, and certifies the bounded theorem recorded by the artifacts.

In the reported trace, the campaign retains one falsified route and six proof-backed deltas, including one stricter bound and two bridge results. Accepted work changes the next Planner input, rejected work remains available as a dead branch, and open blockers become explicit future tasks. The trace therefore captures a continuous research path rather than a sequence of isolated answers.

6.6 Efficiency Attribution in the Mathematical Case

We apply Equation 5 to the theorem-production window covering Rounds 12–17. The analysis contains 18 bounded missions: six changed the theorem frontier, four directly checked or re-certified mathematical results, seven consolidated review state and documentation, and one overlap-analysis mission was interrupted without an admitted result. Table 6 uses mission purpose as a coarse attribution rule for process allocation.

::: {caption="Table 6: Efficiency attribution for the representative mathematical case. Auxiliary work includes result packaging, checkpoint updates, and documentation consolidation."}

:::

The normalized interpretation is concrete. Of every 100 Engineer reasoning-output Tokens, approximately 56 occurred in frontier-changing proof missions, 39 in verification or state-maintenance work, and 5 in the interrupted branch. Of every 100 Reviewer reasoning-output Tokens, approximately 55 directly checked a proof package, 35 maintained formal review state, and 10 were spent in the interrupted analysis. The strict action score is $10/18=55.6%$; if the seven successful auxiliary missions are also credited, the inclusive score is $17/18=94.4%$. Cost weighting makes the interruption more visible: the strict and inclusive action scores become 56.1% and 89.7%, respectively.

The trace also clarifies what the numerator should reward. The early witness check that killed a proposed reduction counts as an efficient action because it pruned a false route before a long proof attempt. In Round 15, selecting one internal triple, deriving the degree bounds, and closing the counting inequality are direct reasoning; rewriting the result into the structured claim record is auxiliary work. Reviewer inspection of those steps is direct verification, whereas updating the working checkpoint is coordination overhead. This separation prevents activity volume from being mistaken for research progress while preserving necessary coordination as a visible cost.

6.7 Objective Revision at Campaign Scale

The benchmark suite evaluates task endpoints, while the mathematical trace follows one research objective in depth. A complementary question is whether the same runtime can carry multiple research programs through the complete paper-production lifecycle. We therefore reconstruct six projects spanning evaluation reliability, vision–language matching, test-time adaptation, GUI agents, multimodal hallucination, and model quantization. The initial objectives and compute environments were provided externally; the retained Argus records identify the Manager, Planner, Engineer, and Reviewer as the actors responsible for Stage transitions, experiments, manuscript construction, review, and submission checks.

Figure 6 summarizes the portfolio. All 6 of 6 canonical pipelines reach the final submission Stage. In aggregate, they span 640 campaign-hours, 254 bounded missions, 576 Engineer rounds, 286 Reviewer revision verdicts, 89 session rolls, and 16 Manager rollbacks. Campaign-hours are summed across projects and are not calendar time because several projects overlap.

The trajectories are inconsistent with a one-pass account of autonomous paper writing. Each manuscript states a scoped research question and a task-native outcome rather than merely presenting a generated document. The portfolio includes uncertainty-aware leaderboard reporting, a failed compositional gate, an over-restrictive adaptation controller, a narrow GUI reliability gain, a failure-mode audit of multimodal wrappers, and a negative result for static quantization proxies. Several projects therefore become diagnostic or negative results after their original positive hypothesis fails. Verification-gated state makes that scientific pivot explicit instead of silently replacing the failed branch.

Figure 7 resolves the multimodal-hallucination campaign in greater detail. During a dense 12-hour search window, seven rollback decisions reject baseline coverage or proposed mechanisms that are unreproduced, base-identical, or missing their preregistered signal. Planner then proposes changing the claim from a positive mitigation method to a diagnostic negative-results audit, and Manager admission makes the refinement authoritative. Engineer completes a five-method by three-benchmark matrix with 4, 500 official-scored rows; Reviewer binds the resulting no-op and degradation claims to those outputs. Two later submission checks return the project to benchmark to repair scorer provenance and GPU telemetry before the final 10-page AAAI-formatted package completes the pipeline.

The process layer is similarly nontrivial. Even the shortest case requires 28 Engineer rounds, 19 Reviewer revisions, and 13 session rolls over 20.8 hours. The two AAAI-formatted cases finish as 10-page anonymous submissions, while the four ACL-formatted cases contain 10–13 pages. Across all six projects, the retained academic, layout, and infrastructure histories contain 436 automated review snapshots. These are process records rather than external assessments of paper quality.

The case study also exposes a consistency failure. The compositional-matching pipeline reaches a complete submission Stage and produces its final PDF, while the last stored assurance object remains BLOCKED on a Manager-stage authority check. This discrepancy does not change the paper artifact, but it shows that derived certification state can lag the canonical pipeline state. Public release automation should reconcile those two views before presenting assurance as a final verdict.

6.8 A Chip the Runtime Designed: ACE-2

The campaigns above produce software, proofs, and manuscripts. ACE-2 asks whether the same runtime holds when the artifact is hardware, where an unverified claim survives exactly as long as it takes someone to run the tool that contradicts it. Argus specified ACE-2, wrote its RTL, built its verification environment, and drove it through mapped synthesis and static timing without a human author of record for any of those artifacts. The result is an inference accelerator that executes Qwen2.5-0.5B end to end in W4A8, certified against a fixed scope.

Functional closure.

The accepted design runs the full 24-layer Qwen2.5-0.5B W4A8 command integration. Layer 0 matches the reference on all 18 ordered operators exactly, and the two-token runtime completes 13,914/13,914 commands over 1,240,410,384 simulator cycles with generated token identifiers $[0, 0]$ and no first failure recorded. The runtime package, command log, and progress journal are each bound by content hash, so the functional claim resolves to specific bytes rather than to a summary.

Physical closure.

Canonical SKY130 HD mapped synthesis and OpenSTA at TT 25 textdegree C / 1.80 V report 62,283 cells and 0.614 mm$^2$ of non-SRAM area against an operator-set cap of 2.0 mm$^2$, with $+0.6966$ ns detailed setup slack, 0.00 ns worst negative slack, 0.00 ns total negative slack, and a 10.000 ns clock period. Both operator-owned targets—the area cap and the 100 MHz floor—pass without relaxation, and the passing packet is the sole exactly-once canonical run rather than the best of several attempts.

What the gate produced.

The certification is dated 2026-08-04 and was issued by a Reviewer that did not perform the work, bound to one RTL tree hash. Each accepted RTL repair carries its own reviewer binding together with the originating and resulting tree hashes, so the certified design is reachable from the audit trail rather than asserted alongside it. The more informative artifact, for the argument of this report, is what the certificate refuses to say. It enumerates its own exclusions: no routed timing, no power signoff, no DRC/LVS, no GDS or tapeout, no silicon validation, no generation beyond two tokens, no external deployment interfaces, and no FPGA prototype. That list was produced by the same gate that admitted the positive claims. An unbounded runtime would have reported a chip; this one reported a chip and the exact perimeter of the evidence supporting it.

ACE-2 therefore extends the pattern of Section 6.5 and Section 6.7 into a domain with an unusually unforgiving verifier. The functional and physical claims are narrow by construction, and the scope conditions are part of the output rather than a caveat added afterward.

6.9 Simplifying a Published Method: Materials Generation

The verticals above are evaluated by a proof checker, a venue format, and a synthesis toolchain. This one is evaluated by an external chemistry validator that the runtime does not own, against two published models it did not write. The campaign targets metal–organic framework (MOF) generation, and its outcome is the sharpest instance in this report of the pattern Section 4 describes: the admitted result is simpler than the method it replaces, and it was admitted only after a confound in the original comparison was removed.

Adding a control the base model lacked.

MOFFlow-2 generates building-block sequences with an autoregressive language model and then places them by flow matching. Its published conditioning accepts a single continuous property and cannot address chemical identity. Argus added metal element, node nuclearity, and ligand family as three discrete condition tokens read through cross-attention, each with its own ANY token and independent condition dropout, so one model serves unconditional, partial, and joint requests. Continuing to train the full decoder raised validation loss, so the language model was frozen and only the condition encoder and six cross-attention modules were updated: 12.69M trainable parameters of 75.8M, or 16.7%. Over 3,300 balanced condition requests weighted toward rare chemistry, adherence reaches 92.5% on metal (17.4% under a permuted-condition control), 100.0% on nuclearity (24.3%), and 74.5% on ligand family (39.0%). The effect concentrates in the tail the corpus under-represents: nickel rises from a 2.1% corpus base rate to 83.7%, trinuclear nodes from 3.9% to 100.0%, and pyrazolate ligands from 2.0% to 46.0%. Unconditional structure-level validity also improves, from 30.61% for the local MOFFlow-2 reproduction to 37.12%. The control is not free: at guidance $w{=}2$ structural validity falls to 17.18%, and the campaign records that trade-off rather than reporting only the adherence numbers.

Replacing the score, then questioning the method.

A failure census over 19,483 paired structures found that the published steering potential penalizes atom overlap, while the dominant failures of the all-atom model are the opposite: under-coordination, fragments, and floating components. Argus built a scoring function aligned to the external MOFChecker criteria instead, with radii derived from covalent and van der Waals tables rather than tuned by hand. Against the external validator it separates passing from failing structures at AUC 0.833, versus 0.594 for the overlap-only potential.

That gain then exposed a measurement problem. Enabling the published Feynman–Kac steering also switches the integrator from ODE to SDE, so the reported improvement mixes two changes. Separating them attributes $+1.92$ points to the integrator alone, which does not reach significance ($p{=}0.238$), and $+9.00$ points to the score inside a fixed SDE ($p{=}2.0\times10^{-9}$). With that confound removed, the runtime tested whether the particle interaction was doing any work at all, by holding model, integrator, score, forward-pass budget, and the same 989 crystals fixed and simply generating $K$ independent trajectories and keeping the best-scoring final structure.

::: {caption="Table 7: External MOFChecker pass rate on 989 paired crystals at matched forward-pass budget, model, integrator, and score. Single-sample SDE decoding passes 43.38%. Independent generation followed by best-of- K selection beats the published Feynman–Kac steering at every budget; the K=8 difference survives a paired test (p=0.0486). Best-of-4 at 53.39% already exceeds Feynman–Kac at K=8 while spending half the compute."}

:::

Table 7 reports the result. The mechanism is visible in the particle statistics: at $\lambda{=}2$ the median effective sample size is approximately one, and 72.1% of crystals collapse to a single particle after resampling, after which the remaining SDE noise does not restore diversity. The published method pays for $K$ forward passes and then discards most of the exploration it bought. Keeping the trajectories independent costs nothing extra and retains it.

Where the campaign stops.

This is a research candidate, not a state-of-the-art claim, and the runtime records why. The 989-crystal subset is the same data on which the score was designed, so the numbers above are not an independent holdout. The full 19,483-structure leaderboard has not been run. The matched-compute MOFFlow-2 comparison was interrupted by a parameter error that enumerated all 19,792 test structures instead of the intended 1,500, and its export is incomplete. Conditional sequence generation and best-of- $K$ structure prediction have not been joined into one end-to-end system. No relaxation, machine-learned interatomic potential, or DFT check has been run, so every number here is scored by the same validator the selection optimizes against, which is exactly the failure mode Section 8 names for verifier-shaped objectives. The campaign therefore holds at a candidate version rather than declaring a release, and the outstanding items are enumerated rather than deferred silently.

What this vertical contributes to the argument of the report is not the pass rate. It is that a runtime given a published method, a fixed compute budget, and an external validator arrived at a smaller method than the one it started from, and that the step which made this admissible was removing a confound rather than adding a component.

7. Analysis and Discussion

Section Summary: The analysis shows that Argus achieves notably higher accuracy on software and research benchmarks than simpler systems, though it spends more computation on planning and review, with efficiency improving as shared experience accumulates over repeated tasks. The reviewer component functions mainly as an adaptive error-correction step that salvages many failing attempts, while the overall system supports full research cycles that involve repeated revisions, rollbacks, and verification rather than simple one-shot generation. A persistent record of verified results and failed paths enables the runtime to evolve its own procedures and reuse prior knowledge without altering the underlying model, and the same traces can later supply training data for improved agents.

7.1 System-Level Performance

The seven-benchmark suite shows one runtime operating across software repair, GPU-kernel optimization, model training, research tasks, and data synthesis; a separate mathematical vertical trace examines proof-oriented research depth. On SWE-Bench Pro, Argus reaches approximately 78% accuracy compared with 59% for Direct Copilot at 1.41 $\times$ aggregate Tokens. The comparison pairs additional computation for planning, execution, and review with a 19-point accuracy difference.

The longitudinal run shows how this cost changes with accumulated state. Mature W19–22 uses 21% fewer solve input Tokens and 15% less active time per task than startup W1–6. The curve remains non-monotone: W13–18 combines low Token use with longer execution, while W23–24 contains a late concentration of difficult tasks. The operating profile changes over time as shared state expands, while task-dependent variation remains visible.

7.2 Reviewer as Selective Error Correction

The Reviewer requests revision on 43 SWE-Bench Pro tasks. After another Engineer round, 34 pass the official verifier and 22 complete the stricter continue $\rightarrow$ revision $\rightarrow$ done loop. These trajectories show the Reviewer functioning as an error-correction stage rather than a terminal commentary layer.

Reviewer routing is adaptive: Reviewer-routed tasks use more Tokens and active time than self-reviewed tasks. The observed routing concentrates independent review on the more resource-intensive part of the workload.

7.3 Autonomous Research Production

The six-paper case study extends the endpoint results into a complete research lifecycle. All six canonical pipelines reach submission completion across six domains and two venue formats, but none follows a one-pass path. Reviewer revision verdicts, Stage rollbacks, and session rolls are common rather than exceptional. The final manuscripts therefore demonstrate persistence across research framing, experimentation, writing, review, and packaging—not merely the ability to emit paper-like prose.

The multimodal-hallucination trace illustrates the control mechanism. Reviewer gates reject seven weak method routes before they are scaled into an unsupported positive claim; Planner proposes reframing the accumulated failures as a diagnostic study; Engineer then completes the 15-cell canonical matrix; and Manager accepts two late rollbacks when submission checks expose scorer-provenance and telemetry defects. The recorded sequence is consistent with role separation redirecting the scientific trajectory: failure is retained as information, while only reviewed state controls the next Stage.

The case also separates artifact completion from process certification. Five final assurance snapshots pass; the compositional-matching project retains a stale blocked assurance snapshot after its canonical pipeline and final PDF complete. This is a useful systems distinction: derived quality metadata must be reconciled with the authoritative Stage state before it can serve as a public certificate.

7.4 Persistent State and Verification-Gated Runtime Self-Evolution

The long-lived object in Argus is the campaign state rather than a provider transcript. Accepted results, failed routes, tools, skills, and current blockers remain available after session and process restarts. Equation 10 formalizes the information advantage of this record, while Equation 12 explains why the runtime keeps both a complete event history and a bounded working checkpoint.

This mechanism gives concrete meaning to verification-gated fixed-model runtime self-evolution. The base model remains unchanged, but an admitted mission can change the starting point, available procedures, verification obligations, or routing policy of later work. The admission gate binds each candidate to artifacts, task-native evidence, and an authorized commit; independent Reviewer judgment is one gate path rather than a requirement for every low-risk update. Rejected branches also participate when they are retained as verified exclusions: later missions can avoid repeating the branch and cite its failed evidence when proposing a pivot. Evolution therefore occurs in the runtime's admitted state and control policy, not in model weights or an unconstrained summary of prior conversation.

The two longitudinal views expose complementary parts of this claim. The SWE-Bench Pro trajectory measures how solve Tokens and active time vary as shared state accumulates, while the mathematical campaign shows direct semantic reuse: later missions consume earlier definitions, bounds, rejected routes, and bridge lemmas. Neither trace isolates a single update mechanism. A matched experiment that replays the same tasks with frozen versus accumulated runtime state would be required to attribute a causal gain to memory, Skills, verification, or routing separately.

7.5 From Runtime Learning to Model Training

The same trajectories can be transformed into supervised examples, preference pairs, and reinforcement-learning transitions. AgentInstruct, Agent-FLAN, and Agent Lightning provide complementary mechanisms for this conversion ([28, 29, 30]). Argus contributes a structured source stream linking objectives, tool actions, measurements, revisions, and retained-state updates. A future training stage can use this stream to internalize recurring planning and verification patterns while the runtime continues to provide long-horizon coordination.

7.6 Vertical Research in Mathematics

The Erdős–Gyárfás campaign exposes the four-role organization at research depth. The Manager preserves the objective and stage, the Planner converts the current frontier into bounded theorem tasks, the Engineer produces proofs and computational checks, and the Reviewer controls admission into durable state.

The campaign retains one falsified route and six accepted theorem-frontier updates. Later missions improve a bound and close two graph-realizability gaps by starting from the reviewed ledger rather than restarting from the original conjecture. This is the same runtime mechanism seen in software repair, applied to a domain where progress is expressed through definitions, lemmas, counterexamples, and proofs.

7.7 Verticals Whose Verifier the Runtime Does Not Own

The chip and materials campaigns (Section 6.8 and Section 6.9) sharpen the same argument under a stricter condition: in both, the deciding evaluator is external. A static-timing engine and an independent chemistry validator will contradict an unsupported claim the moment they are run, so the gate cannot be satisfied by narrative.

Their outcomes are informative in opposite directions, and both are consistent with the position of Section 3. ACE-2 closes a scope and then publishes the perimeter of that scope as part of the result, so the exclusions are an output of the gate rather than a caveat appended to it. The materials campaign instead reverses a design assumption: after separating an integrator change from a scoring change, the runtime found that the published particle-interaction step was discarding the exploration it paid for, and that keeping $K$ trajectories independent scored higher at matched compute. The admitted method is therefore smaller than the one it replaced. Neither outcome required a new component, and neither was reported as a state-of-the-art claim, because in one case the evidence stops at mapped synthesis and in the other it stops at the same validator the selection optimizes against.

7.8 Connecting Theory and Results

Table 8 connects the process-to-capability model to the measurements reported in Section 6 and Section 6.5.

::: {caption="Table 8: Connection between the process-to-capability theory and measured system behavior. Detailed substitutions appear in Appendix D."}

:::

8. Limitations and Future Work

Section Summary: The section highlights several important limits in the current work. Many claims rest on internal observations or single-environment case studies rather than publicly documented, forward-looking experiments with outside collaborators, so questions remain about how well the system helps researchers spot problems in real time or across varied tasks. Refinement steps and verification checks can still accept flawed goals or incorrect tests, and the reported experiments do not yet isolate the effects of persistent memory, reviewer routing, or model differences, leaving open how far the approach generalizes to new models, domains, or full chip-fabrication flows. Future studies are proposed to test these gaps through controlled trials, randomized orders, and broader validation.

User-guided pivots are not publicly evaluated prospectively.

Internal system-verification use has produced concrete cases in which stopping or surfacing a contradiction helped real researchers refine the operational task. Those cases contain project-specific research details and user interactions that cannot be disclosed here. They motivate the mechanism but do not constitute a public prospective study of clarification quality, researcher calibration, or time to identify the binding constraint. A publishable evaluation requires consented, prospectively designed collaboration studies with disclosure-safe tasks.

Contract refinement can still fail.

Evidence and explicit authority reduce goal drift but do not eliminate it. A Manager or operator can approve a poorly framed tradeoff, a recorded standing intent can omit a tacit requirement, and the report-level $K_t/X_t$ projection is distributed across several runtime surfaces rather than one atomic transaction. Future work should test adversarial refinements, invariant-preservation checks, disagreement handling, and rollback of harmful contract changes.

Verification is only as sound as its evidence boundary.

An executable test, formal checker, benchmark, or model Reviewer can encode the wrong property. The runtime can record and revise a verifier, but that does not make the verifier correct. Controlled studies should separately seed implementation bugs, specification bugs, and mismatches between them, then measure whether the runtime localizes the faulty side rather than merely satisfying the current check.

Attribution and task sequence.

The SWE-Bench Pro experiment compares the complete Argus runtime with Direct Copilot. Reviewer routing is adaptive, the 22 completed Waves (24 Wave IDs with two incomplete Waves excluded) follow one task order, and per-Wave Direct-Copilot Token/time records are unavailable. The current results therefore characterize whole-system behavior over this sequence. Matched frozen-state runs, randomized task orders, and randomized review routing will separate the contributions of persistent state, role separation, and review. The startup-to-mature comparison is observational rather than a causal learning ablation.

Generality across models, domains, and evaluators.

The seven benchmark arenas use different metrics, hardware, and execution protocols, while the mathematical analysis follows one vertical campaign. Results are interpreted in their native units rather than combined into a universal score. The in-progress GLM-5.2 run on Claude Code is the first evidence that the runtime transfers across both backbone and execution surface, but it is incomplete and has no matched Direct baseline, so it bounds nothing yet. Repeated campaigns, additional backbones, and external domain review will measure how the runtime transfers across task families and research standards.

ACE-2 is certified for a demonstrated scope, not for silicon.

The chip result establishes functional closure of a 24-layer, two-token Qwen2.5-0.5B W4A8 integration and canonical mapped SKY130 synthesis with static timing. It is not routed timing, power signoff, DRC/LVS, GDS or tapeout, silicon validation, generation beyond two tokens, or an FPGA prototype, and the certificate records those exclusions itself. Whether the same runtime reaches signoff-quality physical design or fabricated silicon is untested.

Metric calibration and model transfer.

The efficiency analysis labels whole role calls by mission purpose; finer segment labels would sharpen the reasoning, action, and verification factors. Reviewer sensitivity and false-acceptance rate require randomized routing with an external verifier, and the counterfactual reuse value $G_L$ requires paired future tasks with and without a state update. The runtime-to-model path is currently a training direction: held-out trajectory splits and scaffold-removal studies will measure how much of the long-horizon control loop can be internalized by the model.

Scope of the paper-production case study.

The six paper projects come from one shared research environment, campaign-hours overlap in calendar time, stored review snapshots are model-generated, and runtime logging evolved across projects. Within that scope, the case study establishes end-to-end lifecycle behavior and recovery under review across six domains and two venue formats, not paper acceptance, scientific novelty, or superiority to human research teams. It also does not establish a measured zero-touch rate. Recorded costs in the public data exclude utility calls without a priced event.

9. Conclusion

Section Summary: Argus is a durable runtime system designed for extended research efforts, allowing it to maintain progress across many steps and restarts while switching approaches when evidence shows a path is failing. It relies on persistent records, separated roles for oversight, and strict verification before accepting changes, all without modifying the core AI models themselves. The system has delivered strong results on demanding benchmarks and real projects like paper writing, while generating detailed records that could help train future AI tools.

Argus is a persistent, pivot-capable runtime for long-horizon research. Its premise is that success does not come from rushing in one direction for as long as possible: the runtime should persist while evidence supports the current route and pivot when verification exposes a failed approach, hidden constraint, or misspecified objective. Persistent campaign state, four-role authority separation, and verification-gated updates carry verified progress across model calls, tool runs, revisions, and restarts. Across seven benchmark arenas, the runtime reaches strong task-native results; on SWE-Bench Pro it attains approximately 78% accuracy versus 59% for Direct Copilot at 1.41 $\times$ aggregate Tokens. Mature operation uses 21% fewer solve input Tokens and 15% less active time than startup, while Reviewer intervention produces 34 verifier recoveries and 22 strict review-loop rescues.

The self-evolution claim is deliberately fixed-model and verification-gated. Candidate memories, skills, procedures, verifiers, routing decisions, and rejected routes alter future work only after evidence checks and an authorized commit; model parameters do not change. Thus a failed branch can become reusable progress without allowing an unverified narrative to rewrite the campaign.

The report-level $K_t/X_t$ model and ManagerAdmit operator make the evidence-and-authority requirements for contract refinement explicit; they summarize distributed runtime surfaces rather than one atomic API. The process-to-capability theory explains how this runtime converts Token activity into retained research progress. Typed trajectories contain more decision-relevant information than final artifacts alone, review separates proposal from admission, and reuse changes the starting point of future missions. The mathematical campaign makes this mechanism visible through one rejected route and six accepted theorem-frontier updates produced by the Manager, Planner, Engineer, and Reviewer.

The six-paper production case provides a second vertical view. Across 640 aggregate campaign-hours, Argus repeatedly survives review rejection, Stage rollback, and session replacement while producing two AAAI- and four ACL-formatted manuscripts. In the representative campaign, seven rejected method routes become a 4, 500-row negative-results study, and two late submission rollbacks repair the evidence package without resetting the paper. This illustrates how the runtime can connect hypothesis revision, experiment execution, and sustained scientific communication, while the stale assurance snapshot in one project identifies a concrete synchronization failure for future work.

These trajectories also define a natural interface to model training. Supervised, preference-based, and reinforcement-learning methods can use the accumulated objectives, actions, measurements, revisions, and state transitions to internalize parts of the long-horizon research loop.

Appendix

Section Summary: The appendix supplies extensive supporting tables and data that expand on the main report’s findings, covering task performance statistics across multiple analysis windows, reviewer routing and recovery outcomes, and detailed role handoffs during a research campaign. It also includes an excerpt from a sample mathematical proof, complete underlying calculations for process metrics, and an account of an optimized software kernel that was reviewed and merged into an external open-source library. The section closes with a notation reference and notes on released supplementary files such as traces and editable sources.

A. Detailed SWE-Bench Pro Results

The main text reports the startup-to-mature comparison. Table 9 shows every analysis window, including the composition shift and late difficult-task period.

::: {caption="Table 9: Task-weighted Argus window statistics. Token index normalizes W1–6 to 100."}

:::

::: {caption="Table 10: All completed Argus Wave summaries used in the longitudinal analysis. Two incomplete Waves are omitted from grouped means."}

:::

B. Reviewer Intervention Details

Table 11 separates routing decisions from recovery outcomes. The first two rows give the routing split; rows three through five partition the 466 independent-Reviewer outcomes; the final two rows measure recovery after a revision request.

::: {caption="Table 11: Reviewer routing and recovery. Strict rescue requires an independent Reviewer continue followed by a later Reviewer done."}

:::

C. Representative Vertical Trace Details

Table 12 expands the role handoffs summarized in Figure 5. The table deliberately foregrounds Agent authority and durable outputs rather than the mathematical statements.

::: {caption="Table 12: Role-resolved phases in the reported Erdős–Gyárfás campaign. The table follows how each role changes the shared research state."}

:::

The supplementary trace bundle contains the role/claim table, calculation map, editable figure source, and provenance. The source campaign retains the complete artifacts and event history.


For fixed roots $x, y$, let $\mathcal{P}_4(x, y)$ be the length- $4$ paths from
$x$ to $y$, and let $\mathcal{F}$ be their internal three-vertex sets. In a
graph with no $C_8$, any two members of $\mathcal{F}$ intersect: two paths with
disjoint internal vertices would join to form an $8$-cycle. A separate
no- $C_4$ case analysis shows that any fixed pair of internal vertices occurs in
at most three path sets.

Assume that the path family has no common internal blocker. Choose
$E=\{a, b, c\}\in\mathcal{F}$. For each $t\in E$, some member $F_t$ omits $t$.

Every set containing $t$ must meet the three vertices of $F_t$; the pair-occurrence
bound therefore gives $d(t)\leq 9$. Hence

$
d(a)+d(b)+d(c)\leq 27.
$

Every member of $\mathcal{F}$ meets $E$, while $E$ itself contributes three
incidences rather than one, so

$

|\mathcal{F}|+2\leq d(a)+d(b)+d(c)\leq 27.
$

Thus $|\mathcal{P}_4(x, y)|=|\mathcal{F}|\leq25$: the paths share a common
internal blocker or there are at most $25$ of them. This excerpt illustrates the
kind of proof artifact produced and reviewed by the workflow; the complete case
analysis and computational checks remain in the source bundle.

D. Process-Theory Calculations

Table 13 records the complete substitutions behind the process quantities summarized in the main text. The mathematical window contains 332, 274 reasoning-output Tokens over 9, 620.5 active seconds. The strict and inclusive density values use the two attribution policies defined in Equation 5. The process-compression row is a separate campaign snapshot.

::: {caption="Table 13: Detailed calculation of the process-theory quantities. Values retain their task-specific units; the main text reports the corresponding system-level patterns."}

:::

E. Upstream Kernel Adoption

The kernel-optimization work produced an externally reviewed upstream contribution to Flash Linear Attention. In FLA PR #1045, Argus implemented and optimized an opt-in TileLang RWKV6 dense-bf16, D=64 forward-intra kernel. The submitted H100 evidence reports a forward latency reduction from 0.199 ms to 0.168 ms (1.18 $\times$) and a forward-plus-backward reduction from 0.900 ms to 0.747 ms (1.21 $\times$), with 13 correctness-gate passes and 14 repository tests.

An FLA collaborator affiliated with Moonshot AI reviewed the generated CUDA, identified a long-sequence numerical-stability issue, and requested block-local exponent centering. After Argus applied the fix and reran the verification suite, the contribution was merged into fla-org:main on July 20, 2026 as commit c70f11c. This is evidence of human-reviewed upstream adoption, not external scientific validation of the broader runtime.

F. Notation

::: {caption="Table 14: Notation used in the report."}

:::

Machine-readable aggregates and editable figure sources are released with the report. They are kept outside the narrative so that implementation metadata does not obscure the scientific results.

References

Section Summary: This section compiles a list of recent academic papers and preprints, mostly from arXiv, that explore AI systems capable of reasoning, using tools, and automating tasks in software development and scientific research. The references cover foundational work on language model agents alongside newer projects aimed at full research cycles, code generation, and collaborative discovery. They span publications from 2023 through 2026 and include both theoretical advances and deployed systems.

[1] Yao, Shunyu and others (2023). ReAct: Synergizing Reasoning and Acting in Language Models. arXiv preprint arXiv:2210.03629. https://arxiv.org/abs/2210.03629. arXiv:2210.03629.

[2] Yang, John and others (2024). SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. arXiv preprint arXiv:2405.15793. https://arxiv.org/abs/2405.15793. arXiv:2405.15793.

[3] Wang et al. (2024). OpenHands: An Open Platform for AI Software Developers as Generalist Agents. arXiv preprint arXiv:2407.16741. https://arxiv.org/abs/2407.16741. arXiv:2407.16741.

[4] Lu, Chris and others (2024). The AI Scientist: Towards Fully Automated Open-Ended Scientific Discovery. arXiv preprint arXiv:2408.06292. https://arxiv.org/abs/2408.06292. arXiv:2408.06292.

[5] Weng et al. (2025). CycleResearcher: Improving Automated Research via Automated Review. In International Conference on Learning Representations. https://openreview.net/forum?id=bjcsVLoHYs.

[6] Qian et al. (2026). AutoSci: A Memory-Centric Agentic System for the Full Scientific Research Lifecycle. arXiv preprint arXiv:2605.31468. https://arxiv.org/abs/2605.31468. arXiv:2605.31468.

[7] Tang et al. (2026). FARS: A Fully Automated Research System Deployed at Scale. arXiv preprint arXiv:2606.31651. https://arxiv.org/abs/2606.31651. arXiv:2606.31651.

[8] Jin et al. (2026). Toward Generalist Autonomous Research via Hypothesis-Tree Refinement. arXiv preprint arXiv:2606.11926. https://arxiv.org/abs/2606.11926. arXiv:2606.11926.

[9] Kwa et al. (2025). Measuring AI Ability to Complete Long Software Tasks. arXiv preprint arXiv:2503.14499. https://arxiv.org/abs/2503.14499. arXiv:2503.14499.

[10] Packer et al. (2023). MemGPT: Towards LLMs as Operating Systems. arXiv preprint arXiv:2310.08560. https://arxiv.org/abs/2310.08560. arXiv:2310.08560.

[11] Wang et al. (2024). Agent Workflow Memory. arXiv preprint arXiv:2409.07429. https://arxiv.org/abs/2409.07429. arXiv:2409.07429.

[12] Xu et al. (2025). A-MEM: Agentic Memory for LLM Agents. arXiv preprint arXiv:2502.12110. https://arxiv.org/abs/2502.12110. arXiv:2502.12110.

[13] Karpathy, Andrej (2026). autoresearch: AI Agents Running Research on Single-GPU nanochat Training Automatically. GitHub repository. https://github.com/karpathy/autoresearch.

[14] Jiang et al. (2025). AIDE: AI-Driven Exploration in the Space of Code. arXiv preprint arXiv:2502.13138. https://arxiv.org/abs/2502.13138. arXiv:2502.13138.

[15] Romera-Paredes et al. (2024). Mathematical Discoveries from Program Search with Large Language Models. Nature. 625. pp. 468–475. doi:10.1038/s41586-023-06924-6. https://doi.org/10.1038/s41586-023-06924-6.

[16] Novikov et al. (2025). AlphaEvolve: A Coding Agent for Scientific and Algorithmic Discovery. arXiv preprint arXiv:2506.13131. https://arxiv.org/abs/2506.13131. arXiv:2506.13131.

[17] Yamada et al. (2025). The AI Scientist-v2: Workshop-Level Automated Scientific Discovery via Agentic Tree Search. arXiv preprint arXiv:2504.08066. https://arxiv.org/abs/2504.08066. arXiv:2504.08066.

[18] Schmidgall et al. (2025). Agent Laboratory: Using LLM Agents as Research Assistants. arXiv preprint arXiv:2501.04227. https://arxiv.org/abs/2501.04227. arXiv:2501.04227.

[19] Baek et al. (2024). ResearchAgent: Iterative Research Idea Generation over Scientific Literature with Large Language Models. arXiv preprint arXiv:2404.07738. https://arxiv.org/abs/2404.07738. arXiv:2404.07738.

[20] Ghafarollahi, Alireza and Buehler, Markus J. (2024). SciAgents: Automating Scientific Discovery through Multi-Agent Intelligent Graph Reasoning. arXiv preprint arXiv:2409.05556. https://arxiv.org/abs/2409.05556. arXiv:2409.05556.

[21] Gottweis et al. (2025). Accelerating Scientific Discovery with Co-Scientist. arXiv preprint arXiv:2502.18864. https://arxiv.org/abs/2502.18864. arXiv:2502.18864.

[22] Schmidgall, Samuel and Moor, Michael (2025). AgentRxiv: Towards Collaborative Autonomous Research. arXiv preprint arXiv:2503.18102. https://arxiv.org/abs/2503.18102. arXiv:2503.18102.

[23] Schick et al. (2023). Toolformer: Language Models Can Teach Themselves to Use Tools. arXiv preprint arXiv:2302.04761. https://arxiv.org/abs/2302.04761. arXiv:2302.04761.

[24] Park et al. (2023). Generative Agents: Interactive Simulacra of Human Behavior. arXiv preprint arXiv:2304.03442. https://arxiv.org/abs/2304.03442. arXiv:2304.03442.

[25] Shinn, Noah and others (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv preprint arXiv:2303.11366. https://arxiv.org/abs/2303.11366. arXiv:2303.11366.

[26] Wang, Guanzhi and others (2023). Voyager: An Open-Ended Embodied Agent with Large Language Models. arXiv preprint arXiv:2305.16291. https://arxiv.org/abs/2305.16291. arXiv:2305.16291.

[27] Lightman et al. (2023). Let's Verify Step by Step. arXiv preprint arXiv:2305.20050. https://arxiv.org/abs/2305.20050. arXiv:2305.20050.

[28] Mitra et al. (2024). AgentInstruct: Toward Generative Teaching with Agentic Flows. arXiv preprint arXiv:2407.03502. https://arxiv.org/abs/2407.03502. arXiv:2407.03502.

[29] Chen et al. (2024). Agent-FLAN: Designing Data and Methods of Effective Agent Tuning for Large Language Models. In Findings of the Association for Computational Linguistics: ACL 2024. pp. 9354–9366. doi:10.18653/v1/2024.findings-acl.557. https://aclanthology.org/2024.findings-acl.557/.

[30] Luo et al. (2025). Agent Lightning: Train Any AI Agents with Reinforcement Learning. arXiv preprint arXiv:2508.03680. https://arxiv.org/abs/2508.03680. arXiv:2508.03680.

[31] Snell et al. (2024). Scaling LLM Test-Time Compute Optimally Can Be More Effective than Scaling Model Parameters. arXiv preprint arXiv:2408.03314. https://arxiv.org/abs/2408.03314. arXiv:2408.03314.

[32] Jimenez et al. (2024). SWE-bench: Can Language Models Resolve Real-World GitHub Issues?. arXiv preprint arXiv:2310.06770. https://arxiv.org/abs/2310.06770. arXiv:2310.06770.

[33] Liu et al. (2023). AgentBench: Evaluating LLMs as Agents. arXiv preprint arXiv:2308.03688. https://arxiv.org/abs/2308.03688. arXiv:2308.03688.

[34] Ma et al. (2024). AgentBoard: An Analytical Evaluation Board of Multi-turn LLM Agents. arXiv preprint arXiv:2401.13178. https://arxiv.org/abs/2401.13178. arXiv:2401.13178.

[35] Chan et al. (2024). MLE-bench: Evaluating Machine Learning Agents on Machine Learning Engineering. arXiv preprint arXiv:2410.07095. https://arxiv.org/abs/2410.07095. arXiv:2410.07095.

[36] Wijk et al. (2024). RE-Bench: Evaluating Frontier AI R&D Capabilities of Language Model Agents against Human Experts. arXiv preprint arXiv:2411.15114. https://arxiv.org/abs/2411.15114. arXiv:2411.15114.

[37] Wang et al. (2026). Act As a Real Researcher: A Suite of Benchmarks Evaluating Frontier LLMs and Agentic Harnesses in Research Lifecycle. arXiv preprint arXiv:2606.07462. https://arxiv.org/abs/2606.07462. arXiv:2606.07462.

[38] Lupidi et al. (2026). AIRS-Bench: A Suite of Tasks for Frontier AI Research Science Agents. arXiv preprint arXiv:2602.06855. https://arxiv.org/abs/2602.06855. arXiv:2602.06855.

[39] Argus Team (2026). Argus: A Self-Evolving Research Agent. Project website. https://argusbot.cn/.

[40] Blackwell, David (1953). Equivalent Comparisons of Experiments. The Annals of Mathematical Statistics. 24(2). pp. 265–272. doi:10.1214/aoms/1177729032. https://doi.org/10.1214/aoms/1177729032.

[41] Xiang Deng et al. (2025). SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?. arXiv preprint arXiv:2509.16941. https://arxiv.org/abs/2509.16941. arXiv:2509.16941.

[42] Lin et al. (2026). SOL-ExecBench: Speed-of-Light Benchmarking for Real-World GPU Kernels Against Hardware Limits. arXiv preprint arXiv:2603.19173. https://arxiv.org/abs/2603.19173. arXiv:2603.19173.

[43] Karpathy, Andrej (2025). nanochat: The best ChatGPT that $100 can buy. GitHub repository. https://github.com/karpathy/nanochat.

[44] Jordan, Keller and contributors (2024). Modded-NanoGPT: The NanoGPT Speedrun. GitHub repository. https://github.com/KellerJordan/modded-nanogpt.