Rove

The deciding trait is that disconnecting does not kill anything. Agent and shell sessions keep running when you close the lid, so the long task you kicked off before lunch is still going when you reconnect, and the sidebar tells you which ones want your attention. That is the difference between parallel work and three terminals you forgot about.

Whether you need it is a real question, and for most people the honest answer is not yet. Pick it if you routinely start work you cannot wait for. Pick one agent if you do not.

Isolation solves the collision and creates the reconciliation. Separate branches mean two agents cannot corrupt each other's work, which is correct, and it also means the moment they succeed you are holding several divergent versions of the same module with no comparison view, no scoring and no documented path to combining them. The files pane shows a diff per worktree, not between them.

What it does right is the isolation itself. A failed attempt costs a directory, and abandoning one leaves the others untouched.

1. Delegating isolation to a mechanism that has been correct for twenty years is the right kind of laziness. The guarantees are already understood, already tested and already familiar to every user, so nothing new has to be trusted. 2. It also fixes the granularity: a task is whatever fits in one branch, which is a constraint the design does not attempt to hide.

2. No verification is described at any level, so a completed attempt is completed by assertion. The architecture is about placement, not correctness.

An orchestration layer above paid agents has the worst economics in the stack: it increases consumption of somebody else's product and captures none of it, which is charming and unfundable. The vendors underneath are all shipping their own parallel execution, and when one of them ships it well this layer is redundant rather than beaten.

Moat: none, and a hundred stars is not a position. Likely path: superseded upstream, or kept alive by the author who needs it. Position: use it, expect to stop, and keep the worktrees where you can find them.

My objection is visibility rather than price. Sixty engineers each running several agent sessions in parallel is a lot of activity happening on laptops, and there is no console, no usage export and no policy I can push, so the honest answer to how much this is being used is that I would not know.

Nothing runs in a pipeline either, so it never becomes a step I can measure or gate. Not yet: before this spreads, I need a way to see it, and a decision about which agent vendors sixty people are allowed to authenticate.

Registering an arbitrary command as an agent is the design decision that makes this mine. It does not care whether the thing it launches is a famous product or a shell script I wrote last night, which means my own tooling gets the same session handling, the same isolation and the same reconnect behaviour as anything commercial.

Permissive licence, a package I can install or a script I can read, and nothing that requires an account. The absence of a protocol client is not a gap here, because the things it drives bring their own connections.