The Superintendent

You say what you want in a sentence. The Superintendent turns that into a plan: an initiative, the tickets under it, and a proposed owner for each one. You read the plan and either accept it or change it. Only then does anything execute.

That order is the product. An agent that starts working from an instruction is a fast way to produce work nobody asked for; a supervisor that produces a plan first makes the expensive part — the doing — something you have already agreed to.

What it is allowed to decide

The Superintendent proposes. It decomposes an intent into tasks, sizes them, and suggests which seat should hold each one. It does not set the goals, and it does not decide that a plan is worth executing.

Its output is a plan on the record rather than a message in a conversation, which means the plan can be read later by someone who was not there, and the difference between what was proposed and what actually happened is a diff rather than a memory.

Where you meet it

• In the terminal, as a command that decomposes an intent into an initiative.
• On the desktop, as a panel that stays with you while you look at the board, so directing work does not mean leaving the view of the work.

Both go through the same runtime and write to the same record. There is no second orchestrator behind the desktop; the board is a view and the panel is a caller.

Two roles that run underneath

The Steward watches the health of a Works — whether workers are alive, whether a run has stalled, whether something needs recovering. It is the operations role, and it exists so that a stuck agent is a condition the system notices rather than one you discover an hour later.

Custodians do background maintenance: the tidying, checking and housekeeping that keeps a long-running Works from silting up. They are the least visible part of hm and the reason the visible parts stay predictable.

Neither of them decides what work is worth doing. That question belongs to exactly one role, and it is not an agent.