While the archive card sat waiting for your answer, the keyboard shortcut for search was still a perfectly ordinary piece of work. Nothing about it needed a product decision. Autonomy in ROOK means that kind of work carries on without you at the terminal, and stops at the kind that does not.

It does not mean removing your judgment from the project. When the coding agent reaches a real fork, it hands that fork back to you as a card and lets that thread wait.

Bounded continuation

Exactly one component is allowed to interpret the project: the coding agent. It reads the code, chooses what to work on next and authors the result. Everything else in ROOK is mechanical by construction.

The part that keeps the loop moving is a driver. It starts a fresh session, carries the output along, waits for the result to be recorded and starts the next one. It does not rank tasks, invent priorities or re-summarize what the session said. When one thread hits a card, that thread parks and the driver can carry on with other runnable work.

A fair manual comparison

The manual version is you, at the desk, running one session and reading its output. That is not a bad way to work. You see problems as they appear, you can redirect mid-flight, and for a single short task it is faster than any coordination layer.

The cost is that your attention becomes the thing the loop runs on. Work stops when you go to lunch, not when it reaches something that needs you, and the question that actually needs judgment often arrives twenty minutes after you stopped watching. ROOK's trade is to let mechanical continuation handle the waiting and reserve your attention for the forks.

What this section covers

Three pages take the boundary from different angles.

  • The non-thinking driver: what the mechanical part is allowed to do, and what stays with the coding agent.
  • The autonomy gate: the three outcomes at the continuation boundary.
  • Park and proceed: what happens to the rest of the queue while one thread waits.

The honest shape of it

Autonomy here is a workflow shape, not a productivity promise. A few things follow from that and are worth saying before the detail pages.

It meansIt does not mean
Runnable work can continue unattendedThat the work will be good
A real fork returns to you instead of guessingThat every fork will be recognized as one
Other threads keep moving while one waitsThat another runnable task always exists
State advances from recorded resultsThat crashes are harmless or retries always converge

When nothing runnable remains — the queue is empty and every thread has parked, finished or blocked — the machine goes idle. That is the honest end state, and ROOK does not manufacture a task to avoid it.

Start with the mechanical half, because most of the boundary is defined by what it refuses to do.

Next

Meet the mechanical part of the loop: the non-thinking driver.