Contrabass

The deciding trait is where the work comes from. It reads your tracker, takes an issue, and gets on with it, which means the queue is the backlog your team already argues about rather than a list you retype into a prompt. That single connection changes the tool from a toy into something that empties a column overnight.

It is wrong for you if you like choosing each task by hand, because then you are fighting the thing it was built to do. Pick it when the backlog is the bottleneck. Pick Agent Deck when judgement is.

The supervision is second-hand. Five different agent runners can be launched, each with its own idea of what working looks like, and the orchestrator detects a stall and recovers an orphan by watching from outside. A runner that is thinking slowly and a runner that has hung present the same way. Recovery then reclaims work that was not actually lost.

What it does right is refuse to guess about dependencies. An issue whose blockers are unresolved is skipped rather than attempted, which is the correct default and one most schedulers get wrong.

1. The phases are separated and named: plan, then execute, then verify, each with its own workers, which means a failure can be attributed to a stage instead of to the run. 2. Branch advance verification is the detail worth noting, because it checks that work produced movement rather than trusting that a process exited cleanly.

2. Retry backoff is described as deterministic, which makes a failing run reproducible, and reproducibility is the property that separates an engineered scheduler from a hopeful one. No benchmark is published, and none is needed for a claim of this shape.

220 stars, one maintainer, and a product that is openly a reimplementation of a model vendor's own orchestrator. That framing is honest and it is also the risk: the original's owner can ship the idea properly whenever it becomes strategic, and this project's distribution is a fraction of theirs.

Moat: none. Pricing power: none, at a price of zero. Likely path: it stays the version people who dislike the original use, which is a real niche and a small one. Position: use it, and do not build a hiring plan around the workflow it implies.

It runs headless and logs events to stdout, which is the sentence that separates a tool from a demo. That means it can sit in our infrastructure, be scheduled by something we already run, and produce output a log pipeline can read without anyone screen-scraping a terminal.

Against that: it holds tracker credentials, and there is no SSO, no audit log and no retention policy describing what it keeps. Sixty engineers' worth of agent runs against one tracker account is an attribution problem. Approved with conditions: a service account per repository, and logs shipped somewhere we retain.

The file that matters is WORKFLOW.md. YAML front matter plus Liquid rendering means the run definition and the prompts live in my repository, under review, in the diff, rather than inside a settings screen. That is the difference between configuring a tool and programming one.

Apache-2.0 keeps the fork clean, and there is a Nix install for people who take that seriously. It exposes a token-protected endpoint so another agent can drive it, and consumes none itself, which is an unusual direction to point the protocol and a defensible one.