ROOK

An AI coding session can keep going for a long time, then stop at one choice only you should make. ROOK separates those two situations. Coding work stays in a work loop; a genuine fork returns to you through a decision loop.

Imagine a task-tracker app with two open threads. One adds a keyboard shortcut for search and can continue on its own. The other adds “archive completed projects” and reaches a product choice: should archive be reversible, or should it permanently delete data? ROOK can keep the first thread moving while it carries the second thread's decision to you.

The map has one author of work: the coding agent, meaning the coding agent that reads the project and authors changes and decisions. A mechanical driver starts fresh sessions and follows their recorded instructions. It does not choose the next task, interpret a report or make the archive decision.

What changes from an ordinary terminal workflow

Without ROOK, you can run the two tasks in separate terminal sessions, keep notes and return when a prompt needs you. That is often enough for a small or closely watched project. The friction appears when several sessions finish at different times: you must remember which prompt belongs to which thread, which work is safe to resume and what evidence survived the closed terminal.

ROOK makes those handoffs durable. A thread is one path of work. The queue is the set of work paths still able to run. A real fork becomes a bounded card; your answer stays attached to that card; and later work advances from recorded events rather than from a terminal process merely exiting successfully.

That difference is useful when independent work and durable decisions recur. It does not make the choice for you, guarantee another thread is runnable or guarantee a good implementation after you answer.

Read the six sections

01The two loopsWhat may continue, and what must return to me?02Decision cardsWhat makes the archive choice answerable away from the terminal?03The recordWhere do the task, card, answer and result remain authoritative?04AutonomyHow can one thread park while another proceeds without giving the driver judgment?05DevicesWhich machine owns the work, and what does the phone actually do?06Status and limitsWhat exists now, and what should you not infer from it?

The section landings show the whole idea. Their child pages enlarge one part without changing the actors or the example.

The boundary in one minute

• The coding agent is the only component that reasons about the project.
• The driver starts sessions and follows recorded instructions; it does not author or rank work.
• A decision card carries one fork with options, consequences and a recommendation.
• The authoritative record stays on the machine doing the work. Desktop and phone apps are surfaces onto it, not competing copies.
• ROOK is designed around proof-of-record: state advances after the record captures the event, not merely because a command returned success.
• ROOK is in active development and is not ready for production credentials or team use.

The first question is where ordinary coding work ends and operator judgment begins.

Next

Start with the two loops.