Argus: a self-evolving runtime for long tasks

How does Argus keep an agent on track across long tasks?

Argus is a fixed-weight agent runtime that stores verified state and adapts its workflow over long-horizon tasks.

• Research org: Unspecified in arXiv abstract
• Core data: about 78% on SWE-Bench Pro
• Breakthrough: Persistent runtime state with role-owned review and verification-gated self-evolution

Long-horizon agent work is hard because the system has to do more than answer once: it has to persist, notice when it is wrong, and change course without losing the thread. Argus is built around that exact problem. Instead of treating the model weights as something that keeps learning online, it keeps the weights fixed and lets the runtime itself evolve through durable state, control policy, and verified project artifacts.

That distinction matters for engineers. A lot of agent failures are not about raw model capability; they are about coordination, memory, routing, and knowing when to stop following a bad plan. Argus tries to make those pieces explicit. The result is less like a single chatbot loop and more like a managed workflow with checkpoints, reviews, and recoverable state.

What problem Argus is trying to fix

The paper frames long-horizon reasoning as a runtime problem. An agent should persist when evidence supports its current approach, but pivot when measurements show failure, hidden constraints, or a misspecified objective. In practice, that means the system needs to keep working across many steps while also being able to revise plans without throwing away everything it has learned so far.

Argus is meant to handle exactly that. The abstract describes it as a persistent, self-evolving runtime where Manager, Planner, Engineer, and Reviewer roles execute bounded missions over durable project state. It separates stable user intent from operational objectives, constraints, and verification criteria, which is a useful way to think about agent design: the user’s goal stays stable, while the execution plan can change as the system learns more.

For developers, the key idea is that the runtime is not just a wrapper around a model call. It is a control system that can retain memories, skills, procedures, verifiers, routing decisions, and even rejected routes, but only after role-owned review and, when available, task-native verification. That makes the agent less dependent on a single pass/fail answer and more capable of carrying forward structured evidence.

How the method works in plain English

Argus keeps model weights fixed. That is an important design choice because it means the system’s “learning” happens outside the model parameters. The runtime itself evolves through persistent state and control policy, and it can operate autonomously between operator-owned escalation points.

In plain terms, Argus is trying to separate three things that are often tangled together in agent systems: what the user wants, how the system is currently trying to solve it, and what has already been verified. The runtime can store and reuse information only after review, which should reduce the chance that a bad shortcut becomes part of the agent’s future behavior.

The four named roles suggest a workflow with specialization. The Manager coordinates, the Planner decides what to do next, the Engineer carries out the work, and the Reviewer checks it. The abstract does not spell out every internal rule, but it does make clear that review and verification are not optional decorations; they are part of how state becomes durable.

This is also where Argus differs from a simple memory-augmented agent. It is not just keeping notes. It is maintaining a persistent project state that can hold memories, skills, procedures, and routing decisions, while also preserving rejected routes for later analysis. That creates a more structured trail of what happened and why.

What the paper actually shows

The strongest numbers in the abstract come from seven GPT-5.5 benchmark arenas. On SWE-Bench Pro, Argus reaches about 78%, compared with 59% for Direct Copilot, while using 1.41 times the aggregate tokens. The paper also says Argus reaches 76.8% on AARRI-Bench and a 28.0-point gap on mathematical data synthesis.

The abstract does not provide full benchmark tables or every baseline in the raw note, so those details are not available here. What it does provide is enough to see the shape of the claim: Argus is not just chasing higher accuracy, but doing so with a runtime that can recover, revise, and preserve verified work over time.

There is also a before-and-after signal from verification-gated self-evolution. In mature SWE-Bench waves, Argus uses 21% fewer solve-input tokens and 15% less active workflow time per task than startup waves. The same section reports 34 verifier recoveries and 22 strict review-loop rescues, which suggests the system is not only succeeding more often, but also learning how to recover from bad intermediate states.

Beyond benchmark-style evaluation, the paper claims several concrete outcomes: an optimized RWKV6 kernel was merged upstream, a multi-day mathematics campaign retained falsified routes and proof-backed frontier updates, and six paper pipelines completed 254 missions with 16 stage rollbacks. Those examples matter because they show the runtime being used on real multi-step workflows, not just short synthetic tasks.

Why developers should care

If you build agents, the most useful takeaway is that long-horizon reliability may depend less on making the base model smarter and more on making the surrounding runtime stricter. Argus treats verification, routing, and review as first-class system components. That is a practical architecture for teams that need agents to work across many steps without silently drifting.

The paper also hints at a broader training-data angle. The authors say the system produces structured trajectories for future supervised and reinforcement learning. In other words, a runtime like this can do double duty: it can execute tasks now and generate better traces for training later.

There are still limits to keep in mind. The abstract does not give the full experimental setup, and the results are tied to the paper’s chosen benchmark arenas. The runtime also uses more aggregate tokens than Direct Copilot on SWE-Bench Pro, so efficiency is not free. And while the paper argues that fixed weights plus evolving runtime state can improve recovery and accumulation of verified approaches, the abstract alone does not prove how well this generalizes across every domain.

Still, the direction is clear. Argus is a concrete attempt to make agents more like managed systems than single-shot predictors. For teams building coding agents, research assistants, or workflow automators, that is a useful model: keep the base model fixed, make the runtime accountable, and let only verified state survive.

What to watch next

• Whether the role-based runtime pattern holds up outside the paper’s benchmark arenas.
• How much token overhead is acceptable when the system is buying recovery and verification.
• Whether structured trajectories from Argus-style runs improve later supervised or RL training.

For now, Argus is a strong signal that the next step in agent progress may come from runtime design, not just bigger prompts or more model calls.