Maestro

The deciding trait is the fresh session. Every task in a queue starts with clean context instead of inheriting the confusion of the four before it, which is the single biggest reason long unattended runs go wrong in every other tool built to this shape.

It is a desktop application and it expects you to have written the checklist properly, which is more preparation than the demo suggests. Pick it if you have several repositories and a habit of writing things down. Pick one agent and watch it if you only have one job today.

The risk is an unaccountable referee. Adding a model to arbitrate between models multiplies the ways a run goes wrong, because a bad decision can now come from the participants or from the thing adjudicating them, and the transcript does not distinguish those two cases.

No protocol, no tie-break rule and no escalation path to a human is described for that conversation. It is also the most expensive component by construction, since it reads everything the others said. What it does right is the batch path, where a checklist is processed one task at a time rather than by committee.

1. This is the correct primitive and it is under-used. Two agents editing one checkout is a race with no referee; two agents in separate worktrees cannot collide, because the isolation is enforced by the version control system rather than by the orchestrator's good intentions.

2. It also makes the result reviewable: each unit of parallel work arrives as a branch, which is the artefact a team already knows how to inspect. 3. No evaluation accompanies the design and none is needed, because the guarantee comes from a tool whose semantics are documented elsewhere.

The structural position is a layer above the money. Every model, every subscription and every agent this drives belongs to somebody else, which makes it a convenience over other people's products and leaves it nothing to charge for that those products could not absorb in a single release.

Moat: the habit, if enough people run their week through it before a vendor ships the same orchestration inside its own client. Likely acquirer is one of those vendors, and the price would be the team. Position: use it, and build no process around it you could not run by hand.

The headless runner is what changes the conversation. A desktop application is a thing sixty engineers each use differently; a binary emitting structured lines on a schedule is a delivery step with a record I can graph. That is the difference between a tool and a control.

Everything else is unresolved. Sixty desktop installs with no central configuration, no identity integration and no audit of which playbook ran against which repository, and the model spend lands on whatever subscriptions people already hold. Approved with conditions: the runner in a pipeline we own, the desktop app on the pilot team only.

Pass-through is the design decision I want more orchestrators to make. It does not reimplement the agent, it drives the one I already set up, which means the configuration I spent an evening on keeps working and there is no second place for my tool definitions to live and drift out of agreement.

The licence is strong copyleft, so a modified version somebody ships comes back to me as source. What I am less excited about is the protocol server, which publishes the product's own documentation rather than exposing the fleet as a tool. It wraps without swallowing, which is rare.