GitHubWhat they did
The author builds Opnory, an AI IT service desk, and Alepes, a rules-based cash-flow-to-investment engine, mostly with Hermes. After a single long session started doing all the building and all the checking, they moved to Hermes Kanban swarms. Each project got a base Hermes profile, cloned into four specialists: a builder that owns the code and tests, an architecture or invariants reviewer, a security or adversarial reviewer, and a verifier. The reviewers run in parallel with the builder, the verifier waits for all of them and judges the evidence, and the base profile writes the final report. Each project has its own board, and the author follows the work through the per-task logs instead of one long transcript.
How it went
The verifier turned out to be the most useful part: it now decides whether the evidence supports calling a change finished, not the agent that wrote it. On one Alepes pull request about a live cash event from Plaid, the record shows four problems fixed, including two different inputs that could build the same queue name, and the change still marked as not certified for live use. The author says this does not show which agent found which issue or that a swarm beats a single agent. For small fixes they still use one agent.
Worth knowing
Reviews run in parallel can end up reviewing code the builder has since changed, so tell the verifier to check the final commit. Calling a reviewer read-only in its profile is only an instruction; use file permissions or a container to enforce it. The published swarm examples used a --workers flag the installed CLI did not accept, so check the help output first. Every extra worker costs tokens.