AgentSys: a plugin marketplace and pipeline runtime for coding agents

The gap AgentSys claims to fill after the model writes the code

The README opens with a blunt framing: models can write code, and that is not the hard part anymore. What it lists as the remaining work is task selection, branch management, code review, artifact cleanup, CI, PR comments and deployment. AgentSys positions itself as the runtime that orchestrates agents across those steps, with structured pipelines, gated phases and state that persists across sessions.

The intended user is someone already running an agent CLI as part of a development workflow, not someone evaluating whether to use one. The supported surfaces are named explicitly: Claude Code, Codex CLI, OpenCode, Cursor and Kiro. If you are not on one of those five, the project has nothing to install into.

The scope is also wider than a single repo. The README states that each plugin lives in its own standalone repository under the agent-sh org, and that agentsys itself is the marketplace and installer that ties them together. That sentence matters more than the headline counts of 24 plugins, 49 agents and 44 skills, because it tells you where the actual maintenance burden sits.

Detection in code, judgement in the model, and what the certainty grades are for

The design principle the README states is "Code does code work. AI does AI work." In practice that means regex, AST analysis and static analysis handle detection, described as fast, deterministic and token-free, while LLM calls are reserved for synthesis, planning and review. The README attributes a 77 percent token reduction for /drift-detect to this split versus multi-agent approaches. That figure comes from the project's own material and I have not reproduced it.

The more concrete mechanism is the certainty grading. Findings are labelled HIGH, MEDIUM or LOW. HIGH means definitely a problem and is described as safe to auto-fix. MEDIUM means probably a problem and needs context. LOW means might be a problem and needs human judgement. The README says this came from testing on 1,000+ repositories.

That three-level scheme is the part worth scrutinising. A grade is only useful if the pipeline acts on it differently, and the README does describe different actions per level. What it does not describe in the supplied material is how a finding is assigned a grade, or what happens when a HIGH finding is wrong. Auto-fixing on a mislabelled HIGH is the failure mode this design invites, and the README does not address it.

Phase gates, single-responsibility agents and state that outlives a session

Each agent is described as having a single responsibility, a specific model assignment, and defined inputs and outputs. Pipelines enforce phase gates so agents cannot skip steps. State persists across sessions so work survives interruptions.

Those three properties are the architecture, and they interact. A phase gate is only meaningful if the pipeline knows which phase it is in after a restart, which is why persistent state is not a separate feature but a precondition for the gates. Model assignment per agent is what makes the benchmark tables in the README coherent: if each agent has a declared model, then swapping the model for a whole pipeline is a configuration change rather than a rewrite.

What the supplied material does not give is the shape of that state, where it is written, or how conflicts are resolved when two sessions touch the same pipeline. The README asserts persistence; it does not document the store. Treat that as an open question to answer from the repository before you depend on it.

Installing: the marketplace path and the --tool flags

There are two install paths named in the material. One is the marketplace, the other is the npm installer. Plugins are fetched automatically from their repos in either case.

The command form that appears in the v6.0.2 release notes is `agentsys install`, which reports failures and exits non-zero when Claude Code rejects a plugin. The same notes state that `agentsys --tool codex` and `agentsys --tool opencode` are the install path for those two CLIs, and that the two adapter `install.sh` scripts were deleted because they deleted a working install and reported success.

That deletion is the most informative line in the release notes. A shell script that removes a working installation and then prints success is worse than no script, and the fix was to remove the path rather than repair it. If you find older instructions referencing an adapter `install.sh` for Codex or OpenCode, they describe behaviour the project has deliberately dropped.

The Windows fixes in the same release are similarly specific. The Claude Code executable is now resolved with `where.exe` instead of assuming `claude.cmd`, and `.cmd` shims are launched through `cmd.exe` at every spawn site. CI was extended to run the suite on Windows as well as Linux. If you are on Windows and pinned below 6.0.2, those spawn-site assumptions are still in your install.

The benchmark tables and what they do not establish

The README includes cost and token tables from a March 2026 benchmark on real tasks, run with `claude -p --output-format json`, using Claude Opus 4 and Claude Sonnet 4 against a repository called glide-mq. In the first table, Opus without agentsys costs $1.10 and produces 2,841 output tokens described as generic recommendations. Opus with agentsys costs $1.95 and produces 5,879 tokens described as specific and project-aware. Sonnet with agentsys costs $0.66 and produces 6,084 tokens, described as comparable to Opus with agentsys.

The second table gives per-plugin savings: /onboard at $1.10 for Opus against $0.30 for Sonnet, and /can-i-help at $1.34 against $0.23.

Two things are worth separating here. The cost and token columns are mechanical measurements. The result-quality column is a judgement, and the material does not describe who made it or against what rubric. The claim that Sonnet plus the pipeline matches Opus plus the pipeline rests on that judgement, so the strongest defensible reading is narrower: structured prompts and enriched context change the output, and the cost difference between model tiers is large enough to matter. Whether quality is equal is not something these tables settle. The benchmark also covers two plugins on one repository, which is a thin base for generalising across 24 plugins.

Where the plugin-per-repo model creates risk

The distribution model is the main structural limitation. AgentSys is the marketplace and installer; the plugins are standalone repos under the agent-sh org. That means the thing you install is not the thing that contains the logic. An install pulls code from repositories that version independently of the installer.

The v6.0.2 notes show what this costs in practice. A release whose headline items are a Windows executable resolution fix, a non-zero exit on rejection, and the deletion of two install scripts is a release about installation plumbing, not about agent behaviour. The project also points at a separate tool, agnix, described as a CLI and LSP linter with 423 rules for catching config errors in Claude Code, Codex, OpenCode, Cursor, Kiro and several other CLIs. The existence of that tool is an admission that misconfiguration is a common enough failure to warrant dedicated validation.

There is also a commercial element in the README: a link to hosted LLM inference under the phrase "Running this agent 24/7?" That is an advertisement, not a dependency, but it tells you the project is maintained by people with a hosted inference product alongside it. Nothing in the supplied material says whether that affects roadmap priorities.

AgentSys against a plain Claude Code setup with subagents

The realistic alternative for most readers is not another orchestration framework but the built-in subagent and slash-command support of whichever CLI they already use. Claude Code supports subagents and custom commands directly, and a team can write a review prompt, a drift check and an onboarding prompt as local files without an installer.

The difference in approach is where the structure lives. With hand-written local commands, the structure is in your repository, under your review, versioned with your code, and broken in ways you can see. With AgentSys, the structure lives in 24 external repositories and arrives through a marketplace listing. You get phase gates, per-agent model assignment and cross-session state without writing them. You give up the ability to read the whole system in one sitting, and you take on the upgrade cadence of every plugin repo independently of the installer version.

That trade is reasonable when the pipeline work is substantial and repeated across projects. It is a poor trade for a single repository where three prompt files would do the same job. The README's own benchmark used two plugins on one repository, which is closer to the second case than the first.

Licence, upgrade cadence and what to check before adopting

AgentSys is MIT-licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That applies to the installer and marketplace repository. The plugins live in separate repositories under the same org, and the supplied material does not state their licences. Check each one you install rather than assuming MIT propagates across the org. This is a description of the licence text, not legal advice.

On upgrade cost, the release history shows three releases between May and August 2026: v6.0.0, v6.0.1 and v6.0.2. The 6.0.2 notes are dominated by install-path corrections, including the removal of the adapter `install.sh` scripts. A major version was followed within three months by two patch releases fixing installation behaviour, which suggests the install surface is still settling. Budget for reading release notes before upgrading rather than pulling automatically.

The concrete checks before adopting: run `agentsys install` and confirm it exits non-zero when a plugin is rejected, since that behaviour is new in 6.0.2. On Windows, confirm your version is at or above 6.0.2 so the `where.exe` resolution and `cmd.exe` shim launching are in place. If you use Codex or OpenCode, use `agentsys --tool codex` or `agentsys --tool opencode` and ignore any older instructions pointing at adapter shell scripts. Then read the licence of each plugin repo you actually install.

Editorial conclusion

Adopt AgentSys if you already drive one of the five supported CLIs and want review, drift detection and onboarding work to run as gated pipelines with state that survives a session boundary. Skip it if you work in a single repository with no CI surface, or if you need an orchestrator that is agnostic about which CLI runs the agents, because the plugins are fetched from separate repos under the agent-sh org and the installer is the only thing tying them together. Verify three things before committing: that `agentsys install` exits non-zero on a rejected plugin in your environment, that `.cmd` shims resolve through `cmd.exe` if you are on Windows, and that the per-plugin repos are the ones you actually want, since the marketplace listing is not the code.

Official sources

1. agent-sh/agentsys on GitHub
2. License: MIT
3. Project website
4. README
5. Releases