mngr

The deciding trait is that it tells you which agents are blocked. Running several at once is not hard until you have to work out which of them is waiting on you, and the usual answer is checking each in turn until you find it. Here the state is a column you read.

There is no service to sign up for and no dashboard to keep open, which suits the way most people actually work. Pick it if you have gone past three agents and started losing track. Pick a single terminal session if you have not.

The risk is diffuse ownership of the failure. When an agent will not start, the cause is a key, a checkout, a session or a daemon, and the diagnosis lives in four different logs written by four different programs with no correlation between them. Nothing documented ties them together.

That is the cost of building on a boring stack rather than a service, and it bites when the number of agents is large enough for something to be broken at all times. What it does right is refusing to run a managed service, so there is no fifth failure stacked on top of the four.

1. Start latency is a meaningful property for a tool whose premise is many short-lived agents, so the claim is the right one to make. 2. It is not the right one to publish unmeasured. Started could mean scheduled, running, or ready to work, and those three differ by an order of magnitude.

2. The same applies to shutting down when idle: no idle threshold is stated, so the behaviour can be neither predicted nor budgeted for. Neither figure is dishonest and neither is checkable, which puts both in the large category of claims a reader must take on trust or ignore.

The mirror is the most informative fact on this row. A research lab exporting its internal tooling is not running an open-source project, it is publishing a byproduct, which is generous and also tells you that maintenance follows an internal need rather than an issue queue.

That is stable while the need exists and it disappears without warning when priorities move. Moat: none, and none intended, since the lab is not selling this. Likely path is continued export, or a quiet stop. Position: use it, pin the version, and treat the roadmap as somebody else's business.

The security surface is more thought through than the category average. Keys are isolated per agent, egress can be restricted by allowlist, and the container is ours to configure, so the controls my team applies to every other workload apply here without inventing anything new.

It also runs unattended, so it becomes a measured step rather than a desktop habit. What it does not have is identity: no directory integration and no audit of who launched what, which at a hundred agents is a gap. Approved with conditions: a named owner for the hosts and an inventory before we pass one team.

Provider agnosticism at the command layer is the part I care about. The agent underneath is an implementation detail I can change on a Tuesday, so switching is a flag rather than a migration, and nothing in my scripts has to know which one is running today.

The licence is permissive, plugins are the documented extension path, and there is no managed service in the middle taking a position on any of it. What is missing is protocol support, so the fleet is not itself a tool that anything else can call.