Argus keeps weights fixed, letting long-horizon agents pivot mid-task via verification gating

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

Boxiu Li, Zimo Wen, Yijia Fan, Junxiang Lei, Sufeng Guo, Jiaao Wu, Ruize Tang, Mukai Li, Yifei Shen, Xiaoyu Chen, Wanbo Zhang, Runjing Gu, Yifei Gao, Yuheng Wu, Xuyao Huang, Zelong Zhao, Jiachen Zhang, Shibo Hu, Hangxi Guo, Yilin Chen, Yuzhe Zhang, Fan Yang, Chuan Wen, Xian Zhang, Xuanhe Zhou, Zhijie Deng

cs.AI

2026-08-06

Argus is a fixed-weight agent runtime: four roles run bounded missions over persistent state, and verification gating lets agents pivot mid-task without it reading as giving up. ~78% on SWE-Bench Pro vs 59% for Direct Copilot.

What problem this solves

When an agent runs a long task (fixing a real repository, training a model, working through a set of proofs), the hard part is deciding, partway through, whether to change the objective. The brief you start with is often wrong: a software requirement only becomes clear once an implementation exposes what was missing, a mathematical conjecture rarely survives in its original form, and in system verification the spec and the implementation can both be wrong. A capable runtime has to persist while evidence supports the current route and pivot when the evidence exposes a problem.

The difficulty is that a system which abandons its stated target may have found the target was misspecified, or it may have failed and rationalized. You cannot tell the two apart from the final artifact. Leave pivoting unconstrained and the objective drifts toward whatever the executor can actually complete. Existing frameworks (ReAct, SWE-agent, OpenHands, The AI Scientist, Arbor) assume the objective is fixed and optimize execution against it. Argus is built around making a pivot backed by evidence, gated by a role, and recorded, so it stops looking like giving up.

Method

Argus is four roles over three planes. The Control Plane anchors the campaign and schedules work; the Execution Plane runs bounded missions against real tools; the Record Plane stores immutable event records but never decides completion. The four roles:

The main loop is Manager→Planner→Engineer⇄Reviewer→Manager. The point of splitting the roles is that the component doing the work is not the one declaring it done, which removes self-verification bias.

A working contract Kt = (user intent ι, operational objective ot, constraints ct, verification criteria vt) separates two things: the user intent ι never changes across the campaign, while the operational objective, constraints, and verification criteria can be refined by evidence. Any material refinement goes through a ManagerAdmit operator that requires Manager or operator authority and is logged. This turns "changing the objective" from a vague act into one with evidence, authority, and a record.

"Fixed-weight runtime self-evolution" is the part most likely to be misread. The model parameters θ never change; what evolves is the runtime state Ht = {memory, skills, tools/procedures, verifiers, routing}. A verification gate requires that candidate memories, skills, procedures, verifiers, routing decisions, and even rejected routes become reusable state only after task-native evidence checks and a commit by an authorized role. A branch that failed is therefore not wasted: it persists as a rejected route that later missions can cite. Cross-session continuity rides on a CHECKPOINT.md holding durable state, evidence references, and open questions.

Results

Seven GPT-5.5 benchmark arenas, each in its native unit:

arenaArguscomparison
SWE-Bench Pro78%Direct Copilot 59% (1.41x aggregate tokens)
AARRI-Bench76.8% (63/82)paper best 68.3%
math data synthesis (Arbor)28.0 gapArbor 20.83 / Claude 8.33 / Codex 6.25
nanoGPT speedrun79.77 shuman 80.18 s
nanochat B200 / H1000.9636 / 0.9855 BPBhuman best 0.9646 / 0.9879
SOL-ExecBench (GPU kernel)global #6two firsts, seven top-3

Lower BPB is better and lower time is better, so Argus edges out the human best on both nanochat and nanoGPT. The SWE-Bench Pro longitudinal view best shows the self-evolution claim. Of 731 tasks, 466 (63.7%) invoke an independent Reviewer and 265 use Engineer self-review; the Reviewer asks for another round on 43 tasks, of which 34 pass the official verifier and 22 complete the strict continue-revision-done loop, with another 35 blocked. Mature waves (W19-22) use 21% fewer solve-input tokens and 15% less active time per task than startup (W1-6). The curve is not monotone; the same run records 34 verifier recoveries and 22 strict review-loop rescues.

Why it matters

The real selling point is not any single benchmark score. It is that a fixed-weight harness can accumulate verified approaches and produce artifacts that external checkers confirm. An Argus-optimized TileLang RWKV6 kernel was reviewed by a Moonshot-affiliated FLA (Flash Linear Attention) collaborator and merged upstream into fla-org:main (PR #1045, commit c70f11c). ACE-2 is a chip whose RTL, verification environment, synthesis, and timing were all driven by the runtime with no human author of record: a Qwen2.5-0.5B W4A8 inference accelerator that matches the reference on all 18 operators in Layer 0 and runs 13,914/13,914 two-token commands over 1.24 billion simulator cycles, with 62,283 cells and 0.614 mm2 of non-SRAM area against a 2.0 mm2 cap. Six paper pipelines ran 640 hours, 254 missions, and 16 stage rollbacks, all reaching final submission (two AAAI-format, four ACL-format). A mathematical campaign retained one falsified route and six proof-backed frontier updates.

For practitioners, Argus offers a credible template: you do not have to wait for the model to get smarter. If you separate proposal from acceptance, record rejected routes, and let progress accumulate across sessions, then a long-horizon agent's failures and pivots become reusable assets instead of restarts. The decision-annotated trajectories it produces are also ready training data for future SFT and RL.

Limitations

The authors are unusually explicit about limits. The most important one: the SWE-Bench Pro comparison is a whole-system comparison over a single task order, not a causal ablation. The startup-to-mature 21% token reduction is observational; Reviewer routing is adaptive, the task order is fixed, and per-wave Direct Copilot token and time records are unavailable. The paper does not separate how much the four roles, the persistent state, and the review each contribute.

Another point easy to misread: fixed-weight self-evolution does not mean the model gets smarter. What evolves is runtime state (memory, skills, routing), and that state may not transfer to a different campaign or toolset. Generality is undertested; a GLM-5.2 run on Claude Code is incomplete with no matched baseline. A verifier can itself encode the wrong property, and the runtime can record and revise verifiers but cannot make a wrong verifier correct. ACE-2 is "certified for a demonstrated scope," not silicon; there is no routed timing, power signoff, DRC/LVS, GDS, or tapeout. The six paper pipelines come from one shared research environment, so the case study establishes end-to-end lifecycle and recovery under review, not acceptance, novelty, or superiority to human teams.

Terms

Source

What people are saying

Related papers

All paper explainers