Separate working directories can reduce file collisions without preventing two agents from sharing the same misunderstanding. Herdr CKD proposes a Maker A, Checker B, and fixed Core C operating through Git worktrees. This review uses the README pinned to the commit inspected on November 10. We did not install the orchestrator or run its models.
Review the change, not just its author’s summary
Section 2 describes one C managing multiple A–B pairs. A implements; C extracts the worktree’s git diff and sends it to B. A NEEDS_FIX judgment returns through C for another implementation pass. Once both A and B declare DONE, C reviews integration.
Supplying the diff gives the reviewer evidence beyond the author’s completion summary. Requirements and runtime failures absent from that diff still need separate evidence. A final judgment by C must be distinguished from a recorded test result.
Role separation is not a security sandbox
The README describes removing write_file and edit_file from B and C and blocking direct A–B conversation, using “air-gap” for this mediated topology. We verified the author’s description, not enforcement against shell writes, process permissions, or network access.
Git worktrees have separate working directories and branches while sharing repository administration. They are not operating-system sandboxes. The README also supports local, cloud, and hybrid model configurations. Whether code leaves the machine depends on configured endpoints and tools; the product’s terminology cannot establish network isolation.
Measure defects rather than agreement
Three roles can agree while sharing a model’s systematic error. We found no independent comparison of defect detection, token cost, and completion time in the reviewed repository. Superiority over a single agent remains a hypothesis to test.
A useful comparison starts both configurations from the same commit and task specification. Keep acceptance tests outside the agents’ edit authority, assign equal total cost or time budgets, and judge both outputs against the same external criteria. This is a proposed evaluation design, not a benchmark we ran.
| Evaluation target | Record together |
|---|---|
| Detection | Known defects found and false alarms |
| Repair | Independent acceptance results and new regressions |
| Review cost | Tokens, elapsed time, and retries by role |
| Integration | Merge conflicts and defects found after completion |
A round cap belongs in the policy
The README documents max_rounds of zero as looping until all roles finish, with explicit caps available. A local model may avoid API fees while still consuming compute, electricity, and waiting time. Sharing weights also does not eliminate the KV-cache memory required by concurrent requests.
Teams that divide changes and need retained review evidence have a reason to evaluate this design in a bounded repository. Define scope and a retry budget first, then connect agent completion claims to external acceptance evidence. The adoption question is whether the system can reject a wrong result at an acceptable cost, not how many roles agree that it is done.