Something has to start the next session after the search-shortcut session ends. In ROOK that something is the driver, and the interesting thing about it is how little it is allowed to understand. It runs the session lifecycle. It does not read the project.
The coding agent remains the only component that thinks. It reasons about the codebase, chooses what is runnable, writes the code and authors decision cards. The driver starts, relays and advances.
What each side owns
| The coding agent | The driver |
|---|---|
| Reads the project and decides what is runnable | Starts a fresh session with the selected work |
| Writes the code and records what it did | Relays the session's output along the loop |
| Authors a decision card when it hits a real fork | Advances only after the result is recorded |
| Judges whether the archive question is answerable | Never reads the card and never answers it |
Two mistakes are worth naming because they are easy to make and both are wrong. The driver does not record the session's result; the session does. The driver also does not check whether a task is runnable, because that judgment needs project context it deliberately does not have.
A fair manual comparison
Plenty of setups solve this by adding a second model: one agent works, another reads its output and decides what happens next. It is an obvious design and it demos well.
The problem is that the second model has almost none of the first one's context. It sees a transcript, not the codebase, and it fills the gap by summarizing. A summary of a decision becomes a new decision, quietly, and the thread drifts away from what the working session actually meant. ROOK treats that as a banned pattern rather than a tuning problem, which is why the comms layer, the on-device server and every screen follow the same rule: they drive, persist, render or converse, and none of them interprets.
Why mechanical parts still need the record
A driver that cannot interpret anything needs an unambiguous signal for when to move. A successful process exit is not it, because a session can exit cleanly having written nothing.
So the signal is the recorded result. The session authors a transition, the record preserves it, and only then does the driver start the next session. This keeps the mechanical component mechanical: it is checking whether an entry exists, not judging whether the work was any good.
Limits
Mechanical is not the same as reliable. Proof-of-record is the design rule for advancing state, not a promise of crash immunity or automatic retry convergence.
Keeping the driver simple also cannot create work that is not there. If the coding agent needs your judgment, the thread parks on a card. If nothing else is runnable, the machine waits. The driver has no way to manufacture a useful next task, and that is the intended behavior rather than a gap.
You now have the two actors. The next page shows the boundary where they meet and the three outcomes allowed there.
Next
See the boundary that controls continuation: the autonomy gate.