lbx154/Argus: a reviewed multi-agent runtime that keeps working when you stop

The problem Argus targets: unattended work that nobody has to grade

Most agent frameworks stop when the model turn ends. Someone has to look at the output, decide whether it was any good, and pick the next task. That person is the Driver, and when they sleep, the work stops. Argus is built for the case where the Driver seat is empty for hours at a time.

The README frames this as a Driver-Harness model. A model is an engine that burns compute and emits tokens. A harness couples those tokens to files, shells, compilers and tests. The Driver decides what to do next and whether the last result was worth keeping. Argus claims the Driver seat and splits it across four roles that are explicitly forbidden from doing each other's jobs.

The target user is not someone prototyping a chatbot. It is someone running research or engineering campaigns that span days, where the cost of a human check-in every few hours outweighs the cost of the agent. The README reports 27 campaigns and 1,548 hours, with a human research decision needed roughly once every 310 hours at a 95 to 99 percent duty cycle. Those numbers come from the project's own technical report (arXiv:2608.05144), not from an independent evaluation, and you should treat them as a claim to verify rather than a measured fact.

Manager, Planner, Engineer, Reviewer: what each role owns and cannot touch

The architecture is a chain with a feedback edge: Manager to Planner to Engineer, with Engineer and Reviewer in a loop. Each role has a narrow mandate.

Manager owns stage transitions and where an admitted lesson is kept. It may not perform the work it is admitting. Planner owns the next task and the evidence that task must produce, but may not move the campaign to the next stage. Engineer owns implementation, research, experiments and artifacts, but may not declare its own work complete. Reviewer owns the verdict on correctness, evidence and limitations, and can return blocked, but runs read-only and may not edit anything.

That last constraint is the load-bearing one. Because the worker cannot grade its own work, the grading step is structurally separate rather than a prompt instruction. Credentials, payment, irreversible actions and publication always stop for a human, so the autonomy is bounded by design rather than by configuration.

Improvement happens without retraining. Admitted Skills and source-linked Wiki findings are scoped project, vertical or global depending on how far they were shown to hold. New domains ship as verticals against a core that does not change. Seven are built in and seventeen more live in the separate argus-verticals package.

Installing Argus: Node.js 22.12+, one authenticated Agent CLI, no Docker

The README's Quick Install section is organized by operating system and warns against mixing commands between platforms. Two prerequisites apply everywhere: Node.js 22.12 or newer from nodejs.org, and one authenticated Agent CLI. Docker is not required for a normal installation; the README says it is only an optional prerequisite for the separate Harbor evaluation integration.

The recommended route is to let the code agent you already use install and verify Argus, by copying a prompt from the Agent-assisted section. The manual route is a table of Agent CLI backends with an install command and an authenticate command each. Three of those rows are visible in the README:

npm install -g @github/copilot
copilot login

npm install -g @openai/codex@latest
codex login

npm install -g @anthropic-ai/claude-code

For Claude Code the README says to run claude and then /login. Several other rows are listed by name without their commands in the text I can see: Cursor CLI, OpenCode, Grok Build, Qoder, DeepSeek Harness, and Pi. The Cursor CLI row contains a curl install line that is cut off mid-URL, so do not guess at it; read the current README before running anything.

The Python side is packaged as argus on PyPI metadata terms, requires Python 3.11 or newer, and declares dependencies including fastapi, uvicorn, websockets, mcp, pydantic-settings, jsonschema, pypdf, portalocker and rich. The seventeen community verticals are deliberately not dependencies: the pyproject comments say the framework must run without them, and they install separately from the Argus-AiTeam/argus-verticals repository. There is also an argus_doctor.py at the top level, which is the obvious first thing to run after installation if you want a health check before starting a campaign. The README does not document what argus_doctor.py checks.

Where Argus breaks down: channels, truncation and the missing rollback story

The most important warning in the README is not about the agent at all. It is about which repository you installed from. microsoft/ArgusAgent is described as the official source repository; lbx154/Argus is the development preview, and changes reach the official repository through synchronization. The README states plainly that installing source from main is not the same as installing a published Desktop release.

That means a bug report against a source install and a bug report against a packaged Windows release may not describe the same code. The release list shows v0.1.7 labeled Windows, v0.1.6 and v0.1.5 without platform labels, while pyproject.toml declares version 0.1.7. The README header still advertises v0.1.6. If you are chasing a defect, establish which channel produced the binary before you spend time on it.

The second limitation is documentation coverage. The Quick Install table is truncated in the available text, so several backends are named without install commands. There is no documented rollback procedure, no documented downgrade path between releases, and no stated compatibility guarantee between a source checkout and a packaged desktop build. The README also does not document what the Doctor script verifies.

Third, the autonomy numbers are self-reported from a technical report. A 310-hour mean interval between human decisions is a strong claim; nothing in the repository readme describes an independent replication. If your work involves irreversible actions, the README's own boundary (credentials, payment, publication stop for a human) tells you where the system expects a human to remain.

Argus compared with a plain coding agent CLI

The honest alternative is the thing Argus sits on top of: a single coding agent CLI such as Claude Code, Codex CLI or Copilot CLI, driven by you in a loop. You install one npm package, authenticate once, and work interactively. There is no Manager, no Planner, no separate Reviewer, and no campaign state to reason about.

The difference in approach is where the judgement lives. In a plain CLI, you are the Reviewer and the Planner: you read the diff, decide whether it is correct, and type the next instruction. Argus moves those two functions into separate roles with explicit prohibitions, so the Engineer's output is graded by something that cannot edit it and cannot be the same actor. The trade is setup complexity and a new failure surface: you now have a runtime with its own state, its own verticals and its own release channels, and you have to trust the role separation to actually hold.

A second alternative is a general workflow orchestrator that chains model calls with your own review step. That gives you full control over the graph but leaves the Driver seat with you, which is exactly the problem Argus is trying to remove. If your campaigns are short enough that you check in every hour anyway, the orchestrator is simpler and you lose nothing.

Licence, maintenance and what an upgrade actually costs

Argus is MIT licensed, per both the repository metadata and the license field in pyproject.toml, which declares MIT as a text license. MIT is permissive: you can use, modify and redistribute it, including commercially, provided the copyright notice and permission notice are preserved. That is a description of the licence text, not legal advice, and if you are embedding Argus in a product you should have counsel read the LICENSE file rather than this paragraph.

The maintenance signal is recent. The last push to lbx154/Argus was on 2026-09-17, and the repository is not archived. Three releases landed in the week before that: v0.1.7 on 2026-09-14, v0.1.6 on 2026-09-11 and v0.1.5 on 2026-09-10. A release cadence that tight during a 0.1.x series means the surface is still moving, and the README's own note about separate source and desktop channels tells you what that movement costs you.

The upgrade cost is mostly in the verticals. Because the community verticals are deliberately excluded from the core dependencies and register through the argus.verticals entry-point group, a core upgrade and a vertical upgrade are separate operations. The pyproject comments note that the pre-rename argus_skill.verticals group is still read for one release, which means there is a deprecation window you should not sit on. Pin your core version, pin argus-verticals separately, and check the entry-point group name after any core bump.

Editorial conclusion

Adopt Argus if you already run an authenticated agent CLI and want long-horizon work that survives a night's sleep; the role split between Engineer and read-only Reviewer is the reason it can run unattended. Do not adopt it if you need a stable, documented install path today: the README states that source on main and packaged Desktop releases are separate channels, and the Quick Install section is truncated mid-table. Before committing, verify three things in your own checkout: which Agent CLI you will authenticate, whether argus-verticals is needed for your domain, and which repository (microsoft/ArgusAgent or lbx154/Argus) you are actually installing from.

Frequently asked questions

Official sources

1. Issues
2. lbx154/Argus on GitHub
3. License: MIT
4. README
5. Releases