Coordinators

A checkout running several agents usually has one you actually talk to. That agent is its coordinator: the default audience for anything to do with that checkout, and the one that keeps the others working.

A coordinator is an ordinary Claude session that can start subagents. It is not app code, and Nightdesk is not driving it — the coordinating is the agent’s own work, done in a session you can open and read like any other. Talking directly to any agent is always possible. The coordinator is a default, not a gate.

Designating one

You ask Concierge. There is no menu item for it and no control on the row: the designation lives on the checkout’s roster, which Concierge writes for you.

After that, the designated agent leads its checkout: selecting the checkout lands on it. If that agent is gone, the designation quietly matches nothing and selection behaves as it did before. A stale designation is never an error and never needs clearing.

No crown, no badge

A coordinator’s row looks exactly like every other row; nothing marks it out. The rail stays a flat list of agents, and ⌘[ and ⌘] step through them one at a time — so a checkout running four agents is four stops on the rail, not one. Being the coordinator changes who you talk to by default; it does not fold the other agents underneath anybody.

What else a checkout’s roster carries

The same roster records which of a checkout’s task sources its Tasks tab shows you — GitHub issues, a to-do file in the repository, or both. Setting it is another thing you ask Concierge for. Leaving it unset hides nothing.

It also decides where a new task is filed. If you have set a checkout to its to-do file, asking for a task there writes it to that file; Nightdesk never files into a backend the tab is currently hiding from you, because a task you cannot see is a task you will not do.

What the Tasks tab lists, and what it tells you when a filter has left it empty, belongs to the Tasks tab rather than to the rail.