SwarmForge

The trait that decides it is separation. Every role gets its own checkout and its own terminal session, so the agent doing cleanup is not standing in the same directory as the one writing the feature, and the collisions that make multi-agent setups miserable simply do not happen.

What you pay for that is ceremony: a pipeline with six roles is six times the supervision and six times the model spend. Pick it when the process is the point. Pick Vibe Kanban when you want the same parallelism with less structure to maintain.

Durable handoffs make the pipeline restartable and make errors durable too. A role that misunderstands the specification commits that misunderstanding, and every downstream role treats it as the ground truth it was handed. Nothing documented describes rejecting a handoff, rewinding one, or detecting that a stage produced something worse than what it received.

What it does right is the gate. The dashboard holds approval points and answers clarifications, so a human can stop the chain before it compounds rather than after.

1. The structure is coherent: specification, implementation, cleanup, architecture, hardening and quality assurance as distinct roles is a defensible decomposition, and expressing it as separate processes rather than as prompt sections makes the boundaries real. 2. Version control as the interface between stages is an elegant choice, because the handoff format is one every engineer already reads.

2. The comparison that matters is absent. No evaluation contrasts the packs against each other or against a single agent, so the decomposition is asserted rather than demonstrated.

Attention arrived instantly because of who published it, and that is a distribution advantage no startup can buy and no startup can inherit either. There is no company, no commercial tier, and nothing that would fund maintenance once the author's interest moves to the next idea.

Moat: authorship, which does not transfer and cannot be acquired. Likely path: the pattern gets absorbed into orchestration products with budgets while this stays a demonstration of the pattern. Position: study the design, run it if you enjoy it, and do not let a team process depend on a repository with no owner obligation.

The blocker arrives before the budget. Code published without stated terms cannot be adopted by a company, because there is no grant to rely on and no warranty to disclaim, and that alone ends the evaluation regardless of quality.

Behind it the economics are also awkward: six roles means six concurrent sessions against a backend each engineer pays for separately, so my exposure scales with role count and not with headcount. It runs only on two operating systems and nothing executes unattended. Not yet, and not until there is a licence.

The primitives are ones I already use daily, so nothing here is a new abstraction to learn: a checkout per role, a session per role, and the remaining arguments handed to whichever agent command I name. Four backends are supported, so I am not married to a vendor and swapping one is a flag.

The problem is the missing licence file. Public source with no terms means I can read it and cannot safely build on it, and that is the one thing a fork actually needs. Fix that and this scores higher.