Sortie

The deciding trait is that your ticket queue becomes the input. Work starts because a ticket matched a filter, not because you sat down and started it, which changes the relationship from something you drive to something that runs while you do other things. For a team with a genuinely well-maintained backlog, that is the difference this category promised.

It is also the requirement. Vague tickets produce vague work at scale rather than one bad session. Pick it if your backlog is disciplined. Pick a supervised agent if you groom tickets as you go.

Retry is the expensive word here. A ticket that fails for a reason no model can fix, a malformed description, a missing dependency, a test that was already broken, will be attempted again, and the concurrency limit governs how many run at once rather than how many times each may run. The bill grows in a dimension nobody configured.

What it does right is close the loop with the pipeline. Continuous integration results and review comments both feed back in, so a rejected change is information rather than a dead end.

1. Declaring the state machine rather than encoding it in scheduler behaviour means the lifecycle of a ticket is inspectable before anything runs, and two deployments can be diffed. That is a higher standard of legibility than orchestrators usually reach. 2. Committing that file beside the repository puts the operating policy under the same review as the code it acts on.

2. No evaluation is published, and correctly so: the project states explicitly that it does not affect output quality, so there is nothing about quality to measure.

An incorporated vendor with a domain, documentation and a package tap is behaving like a company, and there is nothing here anybody pays for. That usually means a hosted version is coming or the founders are building an audience before deciding. Either way, the free tool is the top of a funnel whose bottom does not exist yet.

Moat: the scheduling and state layer is unglamorous work that competitors underestimate, which is a real if modest advantage. Likely acquirer: a tracker vendor wanting an execution surface. Position: adopt the tool, watch for the pricing page.

Cost tracking is the feature that gets this a meeting. Spend attributed per run means the model bill stops being one opaque invoice line and becomes something I can allocate to teams and defend against a forecast. Almost nothing in this category offers that, and finance asks for it every quarter.

It runs without a person present and reports into the pipeline we already operate, so it produces measurable throughput. Missing: identity integration, a central audit record, and any supplier obligation. Approved with conditions: one team, our infrastructure, and a monthly reconciliation against the tracked figures.

Agent agnosticism is the thing I actually want from an orchestrator. It schedules whatever binary I point it at rather than being welded to one vendor's tool, so the layer survives me changing my mind about the agent underneath it. Permissive licence, Go source, two packaging routes that both work.

The model layer is out of reach because it is not this program's model layer, which is a fair answer and still means no local endpoint from here. No MCP client either, so my servers reach it only through whatever agent is running.