Archon

The daily trait is the dispatch surface. You leave a comment on an issue and a run starts, which means the work begins where the conversation already happened instead of in a terminal somebody has to remember to open. Once a team gets used to that, the friction of starting a task drops close to zero, and that matters more than raw agent quality.

Pick it when your process is stable enough to write down. Pick Conductor or Claude Squad when it is not, because here the process must exist before the tool is useful.

The risk is calling a worktree a boundary. Several runs execute at once, each in its own checkout, and no container sits between them and the host. A command that touches a shared service, a global package cache or an environment variable reaches every other run and the developer machine underneath. Docker isolation is not part of the design.

Run it on a dedicated box with credentials scoped to what a run may touch. What it does right: bash, tests and git operations execute as deterministic nodes rather than as model output, so the parts a computer does reliably are not delegated to a language model.

This is the design most agent products describe and few encode. Phases are named and ordered, and the implementation phase repeats until the test suite passes, which makes the exit condition mechanical rather than a judgement the model makes about its own output. An approval gate stands between validation and the pull request, so a human decision is a structural element and not a setting.

No benchmark is published, and none is needed to evaluate this. The architecture is legible from the workflow definition itself, which is a stronger form of evidence than a score.

There is no entity here, only a person with a large following and a project people use. That structure has an advantage worth naming: no burn rate means no forced monetisation and no pricing change to survive. It also means the roadmap is one individual's available evenings, and the failure mode is silence rather than a shutdown notice.

Moat: attention, which is real and does not transfer. Likely path: a hosted service if the maintainer wants a company, or a slow handover to contributors if he does not. Position: use it, keep the workflow files portable, own the exit.

Cost at sixty is the model bill and nothing else, which is the best answer procurement gets all quarter. It runs unattended, so we can schedule it on hardware we control and keep the spend visible. Two things block a general rollout: platform support covers macOS and Linux only, and there is no console, therefore no single sign-on and no central audit of who dispatched what.

Onboarding is fast for anyone who already reviews pull requests. Support is a community. Approved with conditions: a shared runner, our own access logging, and a named internal owner.

The configuration is the product and it sits in .archon/workflows as YAML, versioned beside the code it operates on. That means a process change is a pull request with a diff, which is the first time I have seen an agent pipeline reviewed the way everything else is. Swapping the model-driven step between providers is one field.

There is no MCP on either side, which sounds worse than it is: tools reach the pipeline through whichever coding agent the node invokes, so the protocol lives one layer down. I would rather own that indirection than a plugin system. Fork it, edit the YAML, keep it.