Magi

The deciding trait is legibility. Instead of one opaque agent producing a result, you watch exploration, architecture, implementation, testing and review happen as separate visible things, which makes it obvious where a run went wrong rather than merely that it did. For anyone who has stared at a wall of output trying to find the turn where it lost the plot, that is real.

The same split is the annoyance, because five voices need more attention than one. Pick it if you like watching. Pick a single agent if you would rather be handed an answer.

The cost model is the failure mode. Splitting a goal across concurrent specialists means the same repository is read several times over, each role fills its own window, and every one of them bills separately. The documentation describes the arrangement and describes no limit on how many tasks the mainline agent may create or how deep the fan-out goes. That bill arrives after the work looked fine.

What it does right is put a permission layer in front of every tool rather than only in front of the shell.

1. Recording verification outcomes in the same trace as the changes that prompted them is the detail that separates an audit log from a transcript: the reader can check whether a claim was tested rather than whether it was asserted. 2. Assigning testing and review to agents that did not perform the implementation preserves the separation that makes any such check meaningful.

2. Nothing quantifies whether the separation catches more defects than a single agent asked to check itself. The design is principled and, as published, undemonstrated.

The distribution decision tells you the stage. Asking users to compile the application themselves is fine for contributors and fatal for adoption, which means the current audience is people who wanted to read the source anyway. Two hundred stars at that friction is a reasonable signal and not a market.

Moat: none identified. Likely path: prebuilt releases appear and adoption is tested properly, or the project stays a well-engineered personal system. Position: interesting to watch, too early to depend on, and no commercial entity to hold to anything.

A governance layer that every developer configures for themselves is a preference, not a policy. Sessions, workspaces, tasks and the knowledge base sit in a per-user directory, so there is no central place to set a rule, no directory login to attach it to, and no record I could produce six months later for anyone who asked.

It does not run unattended, so it never becomes a pipeline step with a measurable outcome, and each machine needs a build toolchain before it starts. Not yet, and the model spend would be unpredictable per head besides.

Putting configuration, sessions, workspaces and the knowledge base in one visible directory is the thing I check first and almost never find. It means I can back it up, diff it, move it to another machine or delete half of it without asking the application's permission, and a Rust daemon with a web front end is two processes I can watch rather than one binary I cannot.

Permissive licence, so the fork is legal. The gap is inference: the provider list is hosted vendors, and nothing documented points a role's model at my own hardware.