Verdent

The deciding trait is the board. Work arrives as cards moving across a kanban view, so at any moment you can see which worker is stuck, which is waiting and which finished, instead of guessing from a scrolling log. For anyone who has run three agents and lost track of two, that view is the feature, not the decoration.

What it costs you is a desktop application and a credit balance to watch. Pick it if you manage parallel work. Pick a terminal harness if you would rather not leave the shell.

The gap between the label and the behaviour is the complaint. A reader comparing options sees a free plan listed beside paid ones and reasonably concludes there is a floor they can stay on, and the documentation then says the allocation runs out and the week ends. Every workflow built during those seven days becomes a purchasing decision made under time pressure.

What it does right is give each workspace its own worktree, branch and staging area, so parallel implementations cannot write over one another and abandoning one is free.

1. Declaring acceptance criteria as part of the plan is the right structural move, because it fixes the definition of done before the work rather than after it, when the answer is easier to rationalise. 2. Verification by a separate agent that observes a running application is a stronger form of evidence than an assertion from the agent that wrote the code.

2. A screenshot is evidence a human still has to read, so what is automated is collection rather than judgement. The distinction matters and is not made in the documentation.

Selling an abstraction rather than a unit is the oldest trick in metered software and it works. A credit has no external referent, so the rate can be adjusted without a price change anyone notices, and a four-step ladder from five dollars to a hundred and seventy-nine tells you the company has found buyers across a very wide range of intensity.

Moat: the manager interface and the habit around it. Likely acquirer: a vendor wanting a multi-agent front end for models it already sells. Position: good product, and read the credit table before you build a team process on it.

The seat rate is affordable and the platform list is the blocker. A desktop application for two operating systems means a portion of my engineering organisation cannot install it at all, and a tool that some of the team uses and some cannot is a fairness argument I will be having in a retrospective.

Nothing here runs unattended, so it improves individual throughput and produces no pipeline measurement, and no directory integration or audit export is documented. Approved with conditions: the mobile and backend groups only, with a credit cap set at the organisation level.

Handing worker tasks to a tool already installed on my box is the concession I did not expect from a closed product. It means the manager is orchestration and the actual work runs under credentials and binaries I control, which turns a subscription into a coordination layer rather than a dependency. Servers configure from a JSON file under my home directory.

What I still cannot do is read the manager, fork it, or point it at weights on my own hardware. The doors are open; the building is not mine.