Comanda

The trait that decides it is that the result is a file. You describe what you want in English once and get a workflow you can commit, review and rerun, which turns a good session into something repeatable rather than something you try to remember how you prompted.

What that costs is spontaneity, because a program is a poor place to change your mind. Pick it when the same task recurs and consistency matters more than flexibility. Pick Forge when every task is different and the conversation is the point.

The premise is enforcement and the artefact doing the enforcing is generated. A model that misunderstands the requirement writes gates that check the wrong thing, and the run then passes confidently, because everything the process was told to verify has been verified. Nothing in the documented flow requires human review before the workflow is committed.

What it does right is failure policy. Retry, abort and skip are explicit per gate, so behaviour on failure is a decision the author makes rather than a default they discover.

1. This is the correct answer to the termination problem that afflicts iterative agent designs. When completion is defined by an external command's exit status, the thing being evaluated does not get a vote, and the criterion is inspectable before the run.

2. Checkpointing means an interrupted loop resumes rather than restarts, so cost does not compound with interruption. 3. No evaluation is published on the generated workflows themselves, which is the component whose quality determines everything downstream.

This is the smallest audience in the batch, and the competitive pressure comes from above rather than sideways: the agents it coordinates are each growing their own plan modes and hooks. A solo project with no revenue cannot outpace that, and there is nothing here that a vendor could not reimplement in a sprint.

Moat: none. Likely path: it remains a personal tool that a handful of people love, or the pattern is absorbed. Position: use it if the workflow file solves a real recurrence for you, and keep the file simple enough to reimplement elsewhere.

Exit codes are what make this interesting to me: a run either passes or it does not, in the vocabulary my pipelines already speak, so this becomes a required check rather than an activity. A configured path allowlist means a loop cannot wander outside the directory it was given, which is the boundary I would otherwise ask for.

The exposure is underneath: it drives coding agents on subscriptions each developer holds, so unattended loops spend money I do not see. Support is one maintainer. Approved with conditions: spend caps upstream, and the path allowlist mandatory.

Mixing model sources inside one workflow is the good idea here: a cheap model on my own machine can handle the boring stage while something expensive handles the hard one, and the routing is a role in the file rather than a code change. Work passes between them through files or standard input, which are formats I already know how to debug.

A single binary and a permissive licence means no dependency management and a legal fork. No protocol client, so my servers stay outside, and that is the one thing I would add.