D0016 — Who watches the workers: the first mate, and what it can actually see

[jwildfire]

You asked whether the workers need a manager. They do — but the eyes and the judgment want to live in different places, and only one of them needs to be a Claude session.

The problem is measured, not anticipated. In the last thirty-six hours: a worker hit a terminal API error and sat dead for twenty-seven minutes until a hand-run health check found it; a watcher ended when its pull requests closed and your changes-requested review sat unseen for six hours; the concierge spent nine of its own turns sweeping worker states instead of answering you; and the scheduled sweep itself failed partway through at 22:43 tonight with nothing alerting.

Measuring every session the workspace ran settles most of the design. The harness's own job records are a genuine pulse — median gap between a worker's actions is twenty-three seconds, and a thirty-minute silence rule would have fired exactly once in thirty-six hours. The shared scratchpad is not: one entry in ten follows a gap of twenty-seven minutes or more. And the same signal means opposite things depending on who is watched — "blocked" is a near-certain death for a background worker (two events, one real incident, zero false alarms) and the resting state of the concierge (forty-seven events, all normal waits for you).

The seven calls, one line each:

• F1 — a fourth standing session, or extend the sweep? Add the role; put the eyes in the five-minute scheduled sweep that already survives everything, and give the first mate a session that wakes on a detection rather than standing watch.
• F2 — the seam. Closeout fires once when a worker finishes ("did this land somewhere you can act on"); the first mate fires while it is still running ("is this still moving"). One shared reader, two triggers, no second audit engine.
• F3 — what it may do. Always record; nudge only a slow worker, never a dead one; replace a confirmed-dead worker under a standing grant, never one of your own sessions; never kill a running worker automatically.
• F4 — three standing sessions? One standing session plus two scheduled programs. A polling supervisor costs roughly $10–50 a day, up to ten times that if its cache lapses on each wake; the scheduled program doing the same watching costs nothing.
• F5 — who watches the watcher. The scheduler, not a peer session. Each observer declares its own staleness rule, something that is not it reads that stamp, and a 07:00 missing-digest check catches the case where both are dead. Nothing wakes you at night in week one.
• F6 — does this delay next week? No. The detection is already one of the four blocking fixes for scheduled sessions; the first mate as a role is a follow-on.
• F7 — compaction. Automatic compaction is already on, and nobody chose it — it is the harness default and nothing overrides it anywhere. Make it an explicit setting in the launchers, write the state file from the hook that already fires at the end of every turn, and add a cheap self-check after compacting, because silent loss is invisible by construction.

Full argument, the measurements behind each claim, and the cost table: https://jwildfire.github.io/obot.roadmap/reports/decisions/2026-08-15-worker-supervision/

Quote an ID when you decide — D0016.1 through D0016.7, or the F-codes above.

Filed alongside: #185 (the supervision work) and #186 (compaction survival). The closeout half of the seam is #184.

---

This comment was drafted by Claude Code using Opus 5 and reviewed by @jwildfire