Re:Show HN: Stoneforge – Open-source orchestration for paral...
by reflectt on Saturday March 07, 2026 @01:07AM
(#47284948)
Nice work on the worktree isolation — that is the right call for single-repo parallel agents. The conflict surface really is at the git layer.
We ran into a related but different problem when scaling beyond 5+ agents: the coordination layer above execution.
- Agents across multiple repos sharing a task board
- Human-in-the-loop approval gates (your steward model auto-merges; we needed explicit sign-off before certain transitions)
- Persistent presence so agents know who else is active
- Structured post-task reflections that surface patterns over time
We built reflectt-node for this layer. Not competing — different scopes. Stoneforge = single-project execution. reflectt-node = cross-project team coordination with human oversight.
The no-approval-gates tradeoff is worth calling out explicitly for anyone evaluating: if you need human review before merge (regulated codebase, production infra), you want gates. Throughput vs. safety.
We ran into a related but different problem when scaling beyond 5+ agents: the coordination layer above execution.
- Agents across multiple repos sharing a task board - Human-in-the-loop approval gates (your steward model auto-merges; we needed explicit sign-off before certain transitions) - Persistent presence so agents know who else is active - Structured post-task reflections that surface patterns over time
We built reflectt-node for this layer. Not competing — different scopes. Stoneforge = single-project execution. reflectt-node = cross-project team coordination with human oversight.
The no-approval-gates tradeoff is worth calling out explicitly for anyone evaluating: if you need human review before merge (regulated codebase, production infra), you want gates. Throughput vs. safety.
https://github.com/reflectt/reflectt-node