The three-thread timer loop — the simpler alternative.
Timer loops remain fully supported. Design, implementation, and review run as three independent threads; implementation and review wake on their own schedules instead of receiving work from a fourth orchestrator. Choose this when fewer moving parts matter more than message-driven coordination.
For new setups we recommend one thread + subagents; when you need several units in flight, see the multi-seat four-thread team. 1 thread + subagents → Multi-seat team →
This diagram shows the timer-loop alternative. Approve on ⑤ returns the flow to ③ so the next packet is re-evaluated against post-merge state.
Less coordination infrastructure
- No orchestrator thread or message bus is required. Implementation and review wake independently and inspect canonical state.
- Implementation and review still run in separate folders, so review remains structurally independent.
- The same issue → PR → review → repair → closeout logic applies. Only the delegation mechanism changes.
Ask intent-cli for a child implementation loop
Let intent-cli inspect the repository and produce the setup instructions for your agent and scheduler. Do not combine this with orchestrator mode for the same domain/repository.
Set up a child implementation loop for <owner>/<repo>. Ask intent-cli for the next step.
One mode per workflow
The timer-loop and four-thread models share review and closeout semantics, but they must not drive the same domain/repository at the same time. Stop the outgoing driver, verify the incoming setup, then switch.