One Status Light, Several Agents

Three lenses sit on the matte-black Status Light, with red above amber and green. That is enough to summarize several coding agents only when a strict aggregation rule and a separate detail view explain what the single colour means.

Why does one light need an aggregation rule?

Agents finish, wait for permission, run tools and fail independently. If the newest event simply sets the light, one routine completion can turn it green while another session is still broken. The display needs a deterministic calculation over current session records, not a race between notifier processes.

Give every agent a stable identifier, task name, state, update time and terminal target. Store those records centrally and let one aggregator own the output.

How does worst-state-wins work in practice?

Define a short priority order. A verified failure can map to red, a confirmed request for human input to amber and an ordinary finished or working state to green according to the team's policy. Unknown and stale states should never be quietly treated as healthy.

Recompute the aggregate whenever a record changes or expires. Make the calculation independent of event arrival order, and require each notifier to update only its own session record.

How do you find which agent tripped the light?

Keep detail in a tmux status script, local dashboard or text command that lists task, state and age. The physical signal should prompt a glance at that source, not replace it. Include a direct terminal target so attention can move to the right window without cycling blindly.

Acknowledge or clear a state only after opening that session. Do not make touching the light approve a tool request or dismiss an error in the agent itself.

When do you actually need more than one light?

Add another signal when two groups have different owners, urgency or physical locations. Separate production deployment state from exploratory agents if combining them would make red too frequent or green misleading. More lamps do not repair undefined policies.

The Status Light gives the needed three-lens form, but its automation interface remains unconfirmed by the current facts. Build and test the aggregator with a software display first, including simultaneous failures, stale records and notifier restarts. Limit the set to sessions one person can genuinely supervise. Remove records when tasks close, and give every state a maximum age. Run table-driven tests for every combination in the priority policy so a later refactor cannot make success hide a failure. A manual mute may silence output, but it should not erase the underlying agent records.