Running many projects without losing track means knowing which one is waiting on you.

A coding session that has stopped to ask a question prints the question once and then goes quiet. From outside, that silence looks the same as a session that has hit an error, and a session that is still running is hard to tell apart from one that finished and went idle. OCTYN runs around eighteen of these sessions at once across twenty one codebases, as recorded on its work page on 14 September 2026, and finding the quiet one meant checking every window.

The work inside any single session is rarely what goes wrong. What goes wrong is duller than that. A session asks something, nobody sees it, and the cost turns up as an hour of nothing happening somewhere nobody was looking. There is no crash to point at.

The same thing happens in any business with more in flight than fits in one head. Say you have twelve client projects open, a made up number you can swap for your own. One is waiting on a quote you said you would check. Another has a draft sitting in your inbox that the client cannot see until you approve it, and each of them needs about five minutes of you. Projects that are moving tend to make noise, through messages and questions and new files. A project waiting on you has nothing new to say, so it says nothing.

What a waiting project looks like from outside

The trouble with stopped work is that it does not look stopped. On a board, the card still says in progress, as it has since somebody first dragged it across. In the inbox, the thread is still there, a little further down each hour. The coding sessions are no better: the terminal shows whatever it printed last, which might be a question or might be a long build with a minute left to run.

The cockpit write up is blunt about why this is hard to automate. A session does not publish its state anywhere. It has to be worked out from what the session prints, and the category that matters to a person, whether it is waiting for them, is not one the process reports.

Naming what each one is waiting for

Cockpit is the screen OCTYN is building over its own sessions, still a prototype and used while it is being built. The part that took the thinking was the naming. A waiting session is tagged with what it is waiting for, and there are two tags. Asked means the session wants an answer. Review means it has finished something and wants a person to look at it. An error counts as a separate thing again and takes the focus slot on the right of the screen.

Those two tags ask for different kinds of attention. An asked session needs a decision, often a small one, and it will sit exactly where it is until it gets one. A review session has already done its part, and the useful move is to read what it did before starting anything that depends on it. Lumping them together as needing attention puts a one line answer in the same pile as a long change to read, and the quick answers end up waiting behind the slow reading.

At the bottom of the screen, the whole fleet comes down to three counts. Only one of them is urgent: how many sessions need a person. The rest of the screen is there to get you from that number to the right session quickly.

For a firm running client work, the same split is worth making by hand. The quote you said you would check is asked. The draft waiting for your approval is review. Writing the tag next to each stalled item takes less time than reading this paragraph, and it turns a vague feeling of being behind into a count.

Looking back, the case study's own advice is to write down what each state means before drawing the screen. The tags were arrived at by drawing it twice.

The number nobody has recorded yet

Cockpit cannot yet tell you how long a session waits. No timing instrumentation is built into the prototype, so there is no figure for the gap between a session asking and a person answering. That gap is the number the system exists to shrink, and the first item on the case study's list of things to do differently is recording it from the first commit. Until then, the claim that sessions sit idle unnoticed rests on the experience of the person using it, which is honest and also unmeasured.

A wrong status does more harm than a missing one. A session shown as running when it has really stopped and asked a question gets believed, and a monitor that answers wrongly is worse to trust than having no monitor. Working out state from output is a guess, and there is no confidence signal on that guess in the prototype yet. The person whose sessions it watches maintains it, so drift shows up within a day, as a session marked busy that turns out to have been waiting since the morning.

Any tracker a founder keeps has the same weakness. A board whose status column says in progress for something actually stuck on a question to you will be trusted right up until the client asks where it is.

Picking a stopped project back up

Seeing which project is waiting is half of it. The other half starts when you open that project and have to remember where it was. Brain, the planning system OCTYN runs its portfolio on, exists for that half, and the write up on Brain has the detail. The workspace it covers was audited on 24 July 2026 at more than twenty repositories and roughly 34,853 files, and every morning the context of each project has to be rebuilt: the state it was in, and the reason for a decision that now looks strange.

Two habits from that system carry over to a business that has nothing to do with code. Each project keeps a progress log, and the log gets written because the next session needs it, so nobody has to be reminded. Brain is also forbidden from mixing two projects into one answer. The failure that case study worries about most is a blended reply, two projects merged into one confident answer, and it is the same mistake a person makes walking out of one client meeting and straight into another. Other posts on where a founder's hours go sit under founder operations.

The work in each project moves at the speed it always did. What should change is how long a stopped one sits before anyone sees it, and until the prototype records waiting time, OCTYN cannot tell you by how much.