diri

The deciding trait is three words on a card: working, needs you, done. Running several agents at once is easy; knowing which one is stuck waiting for an answer is the part that actually costs you, and a status that says so turns a row of terminals into a queue you can work through.

None of that matters if you run one agent and watch it. Pick it when three or four sessions are normal for you and you keep discovering one that stopped an hour ago. Pick a plain terminal when the only session you run is the one in front of you.

The unanswered case is the network. Work can be dispatched to a remote host you already have access to, which is genuinely useful and introduces a failure mode the local design never had. Nothing states whether a dropped connection kills the session, orphans it, or leaves it running unattended on a machine nobody is watching.

The third of those is the expensive one, because an orphaned agent keeps spending. What it does right is worktrees: parallel sessions on separate checkouts means the concurrency problem is handled by version control rather than by hoping two agents avoid each other.

1. Separating the process that holds state from the process that draws it is the correct decomposition. The consequence is testable: a session's lifetime is a property of the daemon, not of a window, so a crash in the interface is a cosmetic event rather than a lost run.

2. Restoring conversations after a daemon restart is the stronger claim, since it requires the transcript to be persisted rather than held in memory, and nothing describes where or in what form. 3. No evaluation accompanies any of this and none is needed: the claim is structural and can be verified by anyone in ten minutes.

The packaging is the only asset, and packaging is not a moat. Everything else here is available in some form from three other single-author projects on this board, which means the differentiator is craft rather than position. Craft attracts users and does not retain them once a funded competitor copies the pleasant parts.

No entity, no revenue, no funding, so the eighteen-month question is entirely about one person's interest. Likely path: it stays lovingly maintained for as long as the author uses it, and stops within a month of the day he does not. Position: adopt it, and keep the underlying CLIs runnable without it.

Distribution is where these tools usually die and this one is alive. A signed and notarised universal build removes the security conversation, and a cask that updates itself removes the version drift I spend most of my time on. That combination is worth more to me than any feature.

The Linux side is a beta with an AppImage and a package, which is fine for volunteers and not for a standard. No single sign-on, no directory sync, no audit export, nothing in a pipeline. Sixty seats cost nothing. Approved with conditions: the Apple side rolled out through the cask, the Linux side left to individuals until it leaves beta.

The licence is right and the posture is right: it brings no model, asks for no key and runs the agents I already authenticated. What it will not do is take my tools. There is no MCP client and no MCP server anywhere in the row, so the extension story ends at whatever the wrapped CLI happens to support.

For an orchestrator that is a defensible omission, since the agents underneath speak the protocol themselves and this only arranges them. It still means the layer I would most like to script is the one with no interface. Grudging respect, filed under useful rather than mine.