A team points three agents at an aging ERP and lets them run. Each agent works bravely: refactoring screens, patching defects, tightening types. A week later the workspace is a crime scene. The diffs overlap and contradict. The test suite has been red since Tuesday. Two agents fixed the same bug in different files, and a third broke the navigation while improving a dashboard. Nothing has merged, because nothing can be reviewed with a straight face.
The tools were fine. The agents were competent. What the team lacked was a loop: discover, prioritize, implement in isolation, validate, review, repeat. Running more agents does not create continuous improvement. A reliable cycle that finds problems, ranks them, fixes them one at a time, checks the results, and refuses to merge what fails, that is continuous development. Everything else is expensive churn with good intentions.
This piece surveys the seven tools worth evaluating for that job as of October 2026, maps each to the stage of the loop it actually serves, and ends with a setup order and an interactive chooser. The claims are capability-based, drawn from published product documentation, not benchmark results. No tool is credited with writing better code than any other, because that claim cannot be made honestly without running the tools against your repository.
The loop is the product
The six stages deserve precision, because every tool below is strong at one or two of them and irrelevant to the rest.
- Discover. Inspect documented flows, UI, code, logs, tests, and known issues. The audit layer.
- Prioritize. Rank defects and improvements by user impact, severity, and regression risk. Without this stage, agents work in parallel on whatever they noticed first.
- Implement in isolation. One bounded task per agent, in its own workspace, on its own branch. Overlapping mandates are how the crime scene in the opening forms.
- Validate. Tests, type checks, build checks, UI regression checks. Relevant, not exhaustive.
- Review and integrate. Inspect diffs, reject regressions, merge only what passes the required checks.
- Repeat. Record what remains, update the backlog, start the next cycle.
The load-bearing stage is the fifth, and it deserves its own law: a completed run is not a merged change. Scheduled agents will reliably produce changes; that is the easy part and it proves nothing. The quality gate, where diffs face checks and a reviewer before integration, is what separates a continuous improvement system from a machine that confidently rearranges your codebase. This is Confident Wrong Output Marked Done Is the Agentic Failure Mode operating on a schedule, and the trust ladder that makes the gate enforceable rather than decorative is the subject of From Pull Requests to Proof.
Seven tools, one section of the harness each
None of the tools is the loop. Each is a section of the harness that makes one or two stages reliable.
| Tool | Best for | Website |
|---|---|---|
| Solo | Orchestration: lead agent, specialists, shared context, project commands, MCP control | soloterm.com |
| Conductor | Controlled parallel work: per-task workspace, branch, and review path | conductor.build |
| Herdr | Persistent agents: terminals that survive disconnect, agent-state awareness, remote attach | herdr.dev |
| Orca | Multiple coding agents in isolated workspaces, across different agent CLIs | onorca.dev |
| Superset | Structured improvement batches: scheduled automations, isolated workspaces, CLI/MCP/SDK | superset.sh |
| T3 Code | Agent-oriented coding interface; verify orchestration depth before building on it | t3.codes |
| cmux | Terminal-centered workspace for keeping several agent sessions visible | cmux.com |
Read against the loop: Superset and Conductor serve stages three and five, isolated implementation with a review path. Herdr keeps stage four from dying when someone closes a laptop. Solo coordinates across projects and agent types, which matters once more than one loop runs. Orca widens stage three to whichever agent CLI fits the task. cmux is visibility, not delivery. T3 Code is an interface to evaluate, not a foundation to assume.
Superset's documentation carries a caveat worth quoting because it generalizes: a successful automation dispatch means the workspace was created, not that the code changes succeeded. Every tool in this list has a version of that sentence. The dispatch is stage three. The proof lives in stages four and five, and no tool ships those to you.
Which capability picks the tool
For the common case, an existing complex application, ERP-shaped, needing UI refinement, defect fixing, regression testing, and architecture maintenance over months:
| Capability | Strongest candidate | Why |
|---|---|---|
| Scheduled, recurring maintenance | Superset | Recurring agent sessions create reviewable workspaces |
| Multiple independent changes | Superset, Orca, or Conductor | Isolated worktrees reduce conflicts between agents |
| Agent coordination and project services | Solo | Orchestration around agents, commands, and services |
| Long-running interactive sessions | Herdr | Agents persist when clients detach |
| Scriptable development operations | Superset | CLI, MCP, and SDK for programmatic task and workspace management |
| Lightweight multi-terminal visibility | cmux | Sessions visible with less delivery pipeline |
| General coding interface | T3 Code | Evaluate as an interface, not as an autonomous system |
The honest ranking for this goal: evaluate Superset, Solo, and Herdr first. Superset for the recurring loop, Solo if coordination across projects and agent types becomes the bottleneck, Herdr if session persistence is what keeps breaking. Add a tool when a missing capability is identified in practice, not because the install page was persuasive.
Find your setup
The four questions that actually change the recommendation, what the system should improve, where it will run, which agents you want to coordinate, and how autonomous it should be, are now an interactive chooser: Find your continuous development setup. Answer the four questions and it returns a primary tool, the add-ons worth testing, the gate plan for your autonomy choice, and the host warning your machine deserves. It encodes the same capability logic as this piece, nothing more.
The first month, concretely
Four recurring jobs are enough to start, and none of them should merge code in phase one:
- Daily: UI clarity audit. Inspect screens, tables, forms, navigation, and dashboards. Fix only well-defined usability issues. Inventing new flows is not maintenance.
- Daily: defect and regression triage. Review test failures, application errors, and open bug reports. Rank before implementing. Stage two exists so agents do not skip it.
- Weekly: engineering quality review. Duplicated logic, oversized components, type safety, dependencies, fragile integrations. Bounded fixes only.
- Weekly: end-to-end validation. Exercise documented user journeys, check permissions and data integrity, and report failures with reproducible steps.
Run audits automatically, but require approval before any change merges. Once the test suite and deployment safeguards have earned trust over some weeks, widen what the loop may do without asking. That widening is a decision about evidence, and the graduated-trust discipline in From Pull Requests to Proof is how to make it deliberately rather than optimistically.
One host warning belongs in every setup conversation: scheduled runs on a developer's machine depend on the machine being awake. Continuous development on a laptop that sleeps at six is continuous until six. For genuinely unattended cycles, put the loop on an always-on host or CI environment and verify how the tool runs agents there.
What this is not
Not a benchmark. No tool was measured writing better code than another. These are capability mappings from published documentation, current as of October 2026, and they will age; the six-stage loop will not.
Not a claim that the tools are interchangeable with judgment. The gate in stage five is a human decision for as long as the evidence says it should be, and The Review Bottleneck Is the Real Cost Center in AI Teams explains what happens when the loop generates faster than review can honestly consume.
And not an argument for installing all seven. Three overlapping workspaces produce the same conflicts as three overlapping agents. One loop, one tool, proven over a month, then widen.
Take-home
- Adopt the six stages as the team's shared vocabulary before adopting any tool. The tool discussion is unanswerable until stage ownership is explicit.
- Write the law somewhere visible: a completed run is not a merged change. Every automation you configure afterward will be shaped by whether that sentence is respected.
- Start with Superset, add Solo or Herdr only when a specific bottleneck names itself, and take the four setup questions to the chooser instead of debating them from memory.
Related reading:
- From Pull Requests to Proof
- Confident Wrong Output Marked Done Is the Agentic Failure Mode
- The Review Bottleneck Is the Real Cost Center in AI Teams
- Where the Fleet Breaks, and When It Scales
- Build the Snapshot Before the Dashboard
- Never Hand-Maintain What the System Can Derive
If agents are producing changes faster than your team can honestly review them, the missing piece is not another agent. It is the loop and its gate. If you want help designing the cycle before the tools get installed, book a discovery call.
FAQ
What is continuous development with AI agents?
A standing cycle where agents discover problems in an existing system, prioritize them, implement one bounded fix each in isolated workspaces, validate against tests and checks, and submit the results to a review gate before integration. The loop repeats from an updated backlog. More agents running without this cycle is churn, not improvement.
Which tool is best for continuous AI development in 2026?
For scheduled, recurring maintenance of an existing complex application, start with Superset: recurring automations dispatch agents into isolated, reviewable workspaces, with CLI, MCP, and SDK support. Add Solo when multi-project coordination becomes the bottleneck, or Herdr when session persistence is what keeps failing. The ranking is capability-based, not a benchmark.
Should agents merge their own changes?
Not in phase one. A completed run proves the workspace was created, not that the changes are correct, and every tool's documentation carries a version of that caveat. Require approval before merges until the test suite and deployment safeguards have earned trust, then widen autonomy deliberately through graduated trust rather than optimistic configuration.
What are the six stages of the improvement loop?
Discover: inspect flows, code, logs, tests, and known issues. Prioritize: rank by impact, severity, and regression risk. Implement in isolation: one bounded task per agent in its own workspace. Validate: relevant tests, types, builds, and UI regression checks. Review and integrate: inspect diffs and merge only what passes. Repeat: record what remains and start the next cycle.
Can the loop run on a developer's machine?
Partly. Scheduled runs stop when the machine sleeps, so a laptop gives you continuous development only during working hours. For genuinely unattended cycles, run the loop on an always-on host or CI environment and verify how the chosen tool executes agents there before committing to it.