A session that stops should tell you why it stopped

There are two kinds of stopped agent and they need opposite responses from you.

One has finished, or has a question, and is waiting - the work is fine and thirty seconds of your attention releases it. The other has fallen over: the connection dropped, the tool exited, something upstream refused. That one is not waiting for you. It is dead, and every minute you leave it is a minute lost.

On the screen, for a long time, those two looked identical. A quiet row.

Quiet is the expensive state

This is the specific way a fleet of agents wastes your day, and it scales exactly the wrong way. With one agent you notice within a minute, because you are watching it. With eight, the one that died at 10:40 is indistinguishable from the three that are thinking hard, and you find it at four in the afternoon when you go looking for its output.

The cost is not the failure. Things fail. The cost is the six hours between the failure and you learning about it, and that gap is a product defect, not bad luck.

The row says the reason

So a session that stops now says why on its own row, rather than going quiet and leaving you to work it out. Waiting on you looks like waiting on you. A session that ended because the agent exited says that. A session that lost its connection says that, and says it where you are already looking, which is the session list rather than a log file.

This sounds small written down. In use it changes the shape of supervision: you stop periodically auditing every session to check it is alive, because the ones that are not alive are announcing it.

The other half is the thing you do next

A reason is only worth showing if it points at an action. The three that cover most of it:

• Waiting on you - answer it, from the Director or your phone. Nothing is broken.
• The agent exited - read the last turns and decide whether to resume the conversation or start clean. Resuming keeps the context; starting clean is usually right when the agent had wandered.
• The connection went - the work is usually intact. Sessions are built to survive a wobbly link rather than to be recreated after one.

What a supervisor is owed

The general principle underneath this: an orchestrator that hides a failure is worse than no orchestrator, because it converts a visible problem into an invisible one and charges you for the privilege. If something cannot be determined, the right answer on the screen is that it could not be determined - not a blank, and not a zero, both of which read as "fine".

We hold the same line in the parts you cannot see. A status we failed to read is reported as a failed read, never quietly rendered as nothing happening.

The session list and what each state means: sessions in the Director. Naming, resuming and closing: session lifecycle.