Decision artifactD00162026-08-15Session framework — supervision

Who watches the workers

You proposed a fourth role: a first mate who keeps an eye on the worker agents so they do not get lost or stall, because that job is currently landing on the concierge session and fighting its one goal of answering you fast. You are right about the problem — it has already failed three times in thirty-six hours, and it costs the concierge a measurable share of its turns. This page measures what a watcher can actually see, what the same job costs as a script versus as a standing session, and what it should be allowed to do without asking you.

Verdict add the role — but not as a fourth standing session Cost gap roughly $10–50 a day polling vs. about zero today Decide F1–F7 below

DECIDED — CLOSED 2026-08-16

@jwildfire · 2026-08-16 · in chat

“D14/15/16 all seem like a mess to me. Close them all. Do a single assessment of readiness to move to a schedule and let me know when it’s ready.”

Closed, and its central question already has his answer. This page asked whether the fleet needs a fourth standing role to watch the workers; the consolidated Navigator design put the same question to him as one of its eight, and he adopted the recommendation that the separate supervisor folds into the Navigator rather than being built beside it. The requirement that had been filed for a standalone supervisor closes into the Navigator’s. So the seven questions here are settled by that, not abandoned.

The findings this page measured are not retired with it. The gap distribution across thirty-eight background workers, the one death that survived only in the event timeline while the job record read healthy, and the finding that a watcher living inside a session is not a watcher — all of it is evidence the readiness assessment rests on. It carries forward to Scheduled sessions: what is ready and what is not (D0019), which is the one page that now answers the question these three were circling.

Everything below is the page as it stood when it was folded, on 2026-08-16. It was folded into the consolidated Navigator design because @jwildfire asked for "a consolidated design/decision doc explaining how the navigator/coo agent is going to work" rather than several pages each answering part of it; the questions were carried forward there and answered there. Nothing here is withdrawn — the measurements and the argument stand, and the consolidated page cites them. The answers are on The Navigator (D0017).

WHAT IS BEING DECIDED

"I wonder if we need some kind 'manager' agent to keep an eye on all of the workers and make sure they don't get lost/stalled etc. obot-prime is doing this now, but I feel like it's counter to its primary goal (low latency). So 3 key orchestration roles: I'm ceo, obot-prime is the captain, this new agent is first mate, then we've got the navigator and the crew (worker agents). I kind of think prime, first-mate and navigator all get long-running claude sessions…" — @jwildfire, tonight

Three separable calls are hiding inside that. Whether the job exists — something must notice a worker that dies or wedges, and today nothing does unless a human asks. Who does the job — a Claude session that reasons about what it sees, or a scheduled script that reports and lets a session judge. What the job is allowed to do — watch and report, or reach in and replace a worker on its own. The first is settled by evidence below. The second and third are your calls, and they are where the cost and the risk live.

Recommendation

Add the role. Do not add a fourth standing session to carry it. Put the eyes in the scheduled sweep that already runs every five minutes and already survives everything — that work is already scoped and already blocking next week's scheduled runs. Give the first mate a waking session instead of a standing one: it sleeps for free, the sweep summons it when something actually looks wrong, and it brings judgment to the handful of cases a script cannot decide. Roughly one incident per day earns a few cents of thinking; a standing session that polls all night earns the same answer and a monthly bill.

THE PROBLEM IS REAL, AND IT IS MEASURABLE

Four things happened in the last thirty-six hours, each verified against the machine's own records rather than recalled.

Failure 1 — a worker died and nobody noticed

The audit worker hit a terminal API error — "the response stopped arriving" — and went to a blocked state at 06:12:24. Twenty-six minutes later the concierge sent it a message; the message was recorded against the job, the job stayed blocked, and eighty minutes of complete silence followed. That is the whole lesson in one incident: a dead worker cannot be revived by talking to it, only replaced. The only reason the gap was twenty-seven minutes rather than the whole night is that the concierge happened to run a health check by hand.

Failure 2 — a watcher ended and nobody re-armed it

You left a changes-requested review on the chart-library release candidate at 4:29 in the morning. It was first seen at 10:41 — six hours and twelve minutes later — and only because the scheduled sweep had by then been built. The watcher that should have caught it had ended when the pull requests it was watching closed, and re-arming it was a step someone had to remember.

Failure 3 — supervision is eating the concierge's turns

The concierge's own activity record shows nine turns spent on fleet supervision in thirty-six hours — sweeping worker states, collecting close-outs, diagnosing the dead worker, spawning its replacement. Each of those is a turn it was not answering you, and each of them was reactive: it looked because it thought to look, not because anything told it to.

Failure 4 — happening right now, as this page is written

The scheduled sweep's 22:43 run failed partway through: three of seven repositories would not list. It degraded exactly as designed — kept the last good queue, stamped the file "treat as stale", wrote the reason to its log. And nothing alerted. That is not an argument against the script; it is the argument for the layer above it, and it is the same shape as the demo study's scheduled pipeline that has now been red for twelve days with no subscriber.

Worth saying plainly: this program has reached this conclusion before. A deep dive in June, in the previous era of the tooling, found the identical root cause — "treating returned agent ids as reliable active work without durable liveness evidence" — and concluded that agents were not safe to rely on until liveness became observable. The answer both times was records, not another agent: a run ledger with heartbeats, deadlines, and a recovery path. That history is the strongest single argument for where the eyes belong.

WHAT A WATCHER CAN ACTUALLY SEE

You asked what "lost or stalled" means mechanically. There are four candidate signals, and measuring them across every session the workspace ran in the last thirty-six hours settles most of the design without anyone having to guess.

Signal	What it is	What the last 36 hours show	Verdict
State of the job	Every agent session writes a live record: a state, a one-line description of what it is doing right now, a token count, a timestamp	Across 38 background worker sessions, the blocked state appeared twice — both belonging to the single worker that died. Across the concierge and your own interactive sessions, it appeared 47 times, every one of them a normal wait for you.	Use it — but role-aware
Silence	Time since the worker last did anything the machine recorded	Median gap between actions: 23 seconds. Nineteen gaps in twenty exceed nothing worth noticing; ninety-nine in a hundred are under seven minutes. Gaps beyond fifteen minutes: eight, out of nearly two thousand. Beyond thirty minutes: exactly one — and that worker was legitimately working.	Use it, at 30+ minutes
The shared notebook	The running log every agent is asked to write as it goes	Median gap between entries: 5 minutes. One entry in ten follows a gap of 27 minutes or more. The longest gap from a healthy worker was eight and a half hours.	Do not use it for liveness
Looping	The same activity description repeating, or the same file edited over and over	Not yet measured. The activity line is a plain sentence the model writes, so repetition is suggestive but not proof — a worker legitimately grinding through forty similar files looks identical from outside.	Later, if it earns its place

The three findings that matter

The same signal means opposite things depending on who is being watched. For a background worker, "blocked" is a high-precision death signal — two events in thirty-six hours, one real incident, zero false alarms. For the concierge, "blocked" is its resting state: it is what waiting for you looks like. A watcher that does not know which kind of session it is looking at would have raised forty-seven false alarms in a day and a half.
The notebook is a story, not a pulse. Agents write to it when they remember; the machine's own record updates when they act. A thirty-minute silence rule on the notebook would fire constantly. The same rule on the machine's record would have fired once in thirty-six hours — and the real death would have been caught in under five minutes by the state signal, not by silence at all.
Replacing a dead worker is already mechanical. Each job record carries the exact command that launched it and the full original instructions. Nothing has to be reconstructed or guessed to stand up a replacement — which is why the recommendation below can treat replacement as a safe, auditable action rather than a delicate one.

One honest limit, because it shapes what the watcher must be. The job record settles: the worker that died at 06:12 now reads as cleanly done, with a normal-looking completion note. Only its append-only event log still contains the death. A watcher reading job states after the fact cannot tell a clean finish from a corpse — it has to be watching while it happens. That is exactly what a scheduled sweep is for and exactly what a session that might be asleep, restarted, or compacted is not.

THE SEAM — TWO OBSERVERS, ONE SUBSTRATE

The main design risk you named is that the two watchers merge, or that we quietly grow a second audit engine beside the one the roadmap already has. The seam is clean if it is stated as a trigger rather than a topic:

The closeout check fires once, at the moment a worker goes terminal, and asks: did this finish into something you can act on, and is the roadmap right? That is the requirement filed alongside this one tonight — it is not this page's scope, and this page does not re-decide it.
The first mate fires while a worker is still running, and asks: is this still moving, and if not, what do we do about it before morning?

They read the same source — the harness's own job records — and they must share one reader rather than growing two pollers with two opinions about what a session is. The closeout check watches for the moment a job first goes terminal; the first mate watches everything that has not. Between them there is no gap and no overlap, and neither of them evaluates the quality of anyone's work, which is the existing audit's job and stays there.

WHAT IT MAY DO ABOUT IT

Detection without a permitted action is theatre, and the most consequential actions are the ones you would not want happening at 3am without your standing say-so. Recommended ladder, most conservative first:

Action	When	Needs your grant?
Record and surface — write the finding where the morning digest and the dashboard read it	Always, for every detection, including ones it decides not to act on	No — it is only writing to its own state file
Nudge by message	Only a worker that is slow, never one that is dead	No — but note it is nearly useless: the one time it was tried on a dead worker the text landed in the record and changed nothing
Replace — start a fresh worker from the dead one's own recorded instructions, and post a note saying so	Only for a confirmed-dead worker, only one the fleet itself started, never one of yours and never the concierge	Yes — this is the one real grant being asked for
Kill a running worker	Recommended: never automatically	Not requested. A worker that looks stalled from outside may be thinking, and this is the one action that destroys work
Wake you	Only through the morning digest for week one	No — see the alerting question below

The asymmetry is deliberate. Replacing a dead worker is cheap and reversible — the worst case is two agents doing the same task, which shows up immediately and costs tokens, not correctness. Killing a live one is neither. And the detection evidence supports the asymmetry: the death signal had zero false positives in thirty-six hours, while the "looks stalled" signals are exactly the ones that cannot distinguish a wedged worker from a thoughtful one.

WHAT THREE STANDING SESSIONS ACTUALLY COST

You proposed that the concierge, the first mate, and the roadmap verifier all get long-running sessions. Two costs need stating honestly before that becomes the plan.

The durability cost

The roadmap verifier is not a session today. It is a small scheduled program that runs every five minutes, and that is not an accident of implementation — it is the reason it works. Tonight it was the only observer that survived the concierge's context reset. It survives session death, harness kills, and reboots, and it costs nothing when there is nothing to see. Its own approved requirement already writes the ramp rule in advance: start as a scheduled sweep, and graduate to a standing session only if cadence and scope demand one. Nothing measured tonight demands one. Converting it would trade proven durability for judgment it does not currently need.

The money cost

A standing session is not a burst of spend, it is a continuous one, and the shape of the spend is counter-intuitive: almost all of it is re-reading its own context, not thinking. Priced from published rates for the model these sessions run on, and from the token counts the sessions themselves recorded today:

Shape	How often it thinks	Rough daily cost	Note
Scheduled program (today's verifier)	Never — it is not a model	$0	About thirteen GitHub calls per run
Waking session, summoned on a real detection	Roughly once a day, at today's incident rate	Cents	Sleeps for free; pays only when something is wrong
Standing session polling every five minutes, modest context	288 times a day	$10–50	The range is entirely about whether its cached context survives between wakes
Standing session polling every five minutes, large context	288 times a day	$30–300	Worst case is a five-minute poll against a five-minute cache lifetime — it can miss its own cache every single time

That last row is the trap worth naming: a session that wakes on exactly the same interval as its own memory expires can end up paying the full un-discounted rate on every wake, and the difference between best and worst case is roughly tenfold for identical work. A scheduled program has no such cliff. These are order-of-magnitude estimates from list prices, not a bill — but the ordering between the rows is not sensitive to the assumptions, and the ordering is the decision.

The third cost, which is the one that bit us today

Every long-running session needs a story for what happens when it runs out of room to remember. The concierge has one, and exercised it for the first time tonight. The first mate and the verifier would each need their own, or they inherit the exact failure the concierge just spent a day fixing. That is the subject of the next section, and it is a real argument against multiplying standing sessions before the mechanism is proven once.

WHO WATCHES THE WATCHER

If the first mate supervises the crew and the first mate stalls, what notices? Peer-watching is circular and fails in exactly the correlated way you would not want — the same harness problem that kills one session tends to kill the other.

The durable answer is the layer that has actually demonstrated survival: the machine's own scheduler, which is not a Claude session and does not care about context, compaction, or crashes. Recommended heartbeat, in three parts, none of which requires a new component:

Each observer declares its own staleness rule in the file it writes — the verifier already does this, and it is the single best piece of design in the current system: any reader finding a timestamp older than three ticks must treat the observer as dead and say so out loud. A dead watcher cannot masquerade as a quiet one.
Each observer's file is read by something that is not it — the morning digest, the concierge's first read of the day, and the operations dashboard all render the freshness stamp. Your first interaction of the day is therefore a human-touched check of the monitors.
A dead-man check at 07:00: if last night's run did not produce its digest, that is the alarm, even when every failure signal was swallowed. This is already scoped as blocking work for next week's scheduled runs, and it is what turns tonight's silent sweep failure from invisible into a line in your morning message.

One gap to close while we are here: the sweep that failed at 22:43 wrote its failure to a log nobody reads. The same swallow-and-log pattern once hid a broken publisher through an entire session. Failing loudly in the file the digest already reads is a few lines of work and closes the class.

MEMORY THAT SURVIVES COMPACTION

You raised this in the same breath as the roles, and you were right to: a standing session that hits its memory ceiling at 3am with nobody watching simply stops being useful. It has its own requirement filed tonight, but one finding belongs on this page because it changes the three-standing-sessions answer.

Checked, not assumed

Automatic compaction is already switched on — and nobody chose it. It is the harness default, and it is not overridden anywhere: not in your personal settings, not in the workspace settings, not by any environment override, not by the launcher that starts the concierge. So this is not a decision about turning it on. It is a decision about whether a setting that governs every long-running session's memory should be an unexamined default or a recorded, explicit choice in the scripts that launch them.

The good news is real and you called it correctly: the tracking systems are largely in place. Compacting preserves what a full relaunch destroys — armed watchers and the ability to reach live workers by name — and the one time nobody re-armed a watcher after a restart, your review sat unseen for six hours. For an unattended session, automatic compaction is therefore strictly safer than restarting when full. And the antidote to compaction being lossy already exists: a curated file on disk holding what must survive, with a one-command tool that reads it back.

The gaps, named precisely rather than agreed with warmly:

Only the concierge has a state file and a way to read it back. Neither of the proposed new roles does. The answer is almost certainly one shared mechanism rather than three bespoke ones — but it does not exist yet, and building it three times is a reason to add standing sessions slowly.
The write happens when someone remembers. The concierge's file was written deliberately, at the moment of a planned reset. Under autonomy nobody chooses the moment — compaction fires when it fires. The fix is available and cheap: a hook already runs silently at the end of every turn of every agent in this workspace, rate-limited so it cannot become a tax. Refreshing state there makes the file never more than one turn stale, with no discipline required from any agent.
Nothing notices silent loss. If a compaction at 3am drops something load-bearing, today there is no check. A cheap one exists: on the first turn after compacting, read the state file back and compare it against what the summary retained. Worth doing precisely because the failure is invisible by construction.
The state file is capped at roughly four kilobytes, which is right for one bounded read and wrong for an all-night run that accumulates more than that. Nothing currently decides what gets evicted. Simplest answer: the cap holds, eviction is oldest-resolved-first, and anything evicted goes to the session log rather than being deleted.
The cold-start path is designed but still untested — recorded as such in tonight's readiness assessment, and unchanged by anything here.

THE QUESTIONS

Do we add a fourth role — a standing supervisor for the worker agents — or extend the scheduled sweep that already runs?

The job is real and the evidence is not close. The question is where it lives: a new standing session that watches, or the existing five-minute scheduled sweep that already survives everything, with a session summoned only when it finds something.

Recommended: add the role, split the work. Eyes in the scheduled sweep — that work is already scoped and already blocking next week's runs, so it costs nothing extra. Judgment in a first mate that wakes on a detection rather than standing watch. You keep the role in the org chart and on the dashboard; you do not pay for it to stare at a screen all night.

Where is the line between the two observers, so we do not grow a second audit engine?

Two watchers reading the same records will merge unless the seam is written down. Stated as triggers rather than topics, there is no overlap.

Recommended: the closeout check fires once, when a worker finishes — did this land somewhere you can act on, and is the roadmap right? The first mate fires while a worker is still running — is it still moving, and what do we do if not? One shared reader of the job records, two triggers, and neither one judges the quality of anyone's work — that stays with the existing roadmap audit.

What is the supervisor allowed to DO when a worker goes quiet — and what counts as quiet?

What counts as quiet is close to settled by measurement: a worker in the blocked state is near-certainly dead, and thirty-plus minutes of silence is worth one look. The open call is the action ladder, and specifically whether an agent may stand up a replacement worker at 3am without asking you.

Recommended: always record and surface; nudge only a slow worker, never a dead one; replace a confirmed-dead worker under a standing grant, limited to workers the fleet itself started and never to your own sessions or the concierge, with a note posted every time; never kill a running worker automatically. Replacement is safe here because the job record already carries the exact instructions and launch command needed to redo it.

Three standing Claude sessions, or one session and two scheduled scripts?

Standing sessions cost continuously, need a memory-survival story each, and die with their harness. Scheduled programs cost nothing, survive everything, and cannot judge. The measured incident rate is about one a day.

Recommended: one standing session — the concierge — plus two scheduled programs and a waking first mate. Keep the roadmap verifier as a program until its own written ramp condition is actually met. Revisit the moment the first mate is being summoned many times a day, or is being asked a question a script cannot pose.

Who watches the watcher, and should anything wake you at night?

Peer-watching between two sessions is circular and fails together. The scheduler that is not a Claude session is the layer that has actually demonstrated survival.

Recommended: every observer declares its own staleness rule in the file it writes, 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 for week one — every overnight outcome the current fixes leave possible is a safe stop that can wait for morning. One gap to close: tonight's sweep failure was written only to a log nobody reads.

Is the supervisor a prerequisite for turning scheduled sessions on next week, or a follow-on?

You are turning the unattended lane on next week, and tonight's readiness assessment was written under the current two-observer model. This is the practical question of whether that plan now slips.

Recommended: it does not slip. The detection is already a prerequisite — it is one of the four blocking fixes in that assessment, roughly half a day of agent work, unchanged by this page. The first mate as a role is a follow-on: the blocking need overnight is that a failure becomes visible and the run parks safely, not that an agent reasons about it at 3am. Build the detection for next week; add the first mate on top of it once it has a week of real signal to react to.

What forces a standing session to write its memory to disk, now that compaction fires on its own?

Automatic compaction is already on by default and nobody chose it. It fires when it fires, so state cannot be written when someone remembers — it has to be current continuously.

Recommended: refresh the state file from the hook that already runs silently at the end of every turn of every agent here, so it is never more than one turn stale; set the compaction preference explicitly in the launcher scripts so it is a recorded choice rather than a default nobody picked; and add a cheap self-check on the first turn after compacting, since silent loss is invisible by construction. Mechanics and the remaining gaps are in the requirement filed alongside this page.

Where this lands

The supervision work itself — detection rules, the action ladder, the seam — is requirement #185.
Compaction survival for standing sessions — the continuous write, the explicit setting, the silent-loss check — is requirement #186.
The other half of the seam, the closeout check that fires when a worker finishes, is requirement #184, filed the same night.
The detection layer is already blocking work in the scheduled-sessions readiness assessment; the scheduled sweep's own ramp rule lives in requirement #157.

Every number on this page was measured tonight from the machine's own records — job states and event logs across 45 sessions, the scheduled sweep's log, the shared notebook, and the concierge's activity record — not recalled from the day. Cost figures are order-of-magnitude estimates from published list prices applied to those measured token counts; they are not a bill. The one behavior described but not measured is looping detection, and it is marked as such.

This decision artifact was drafted by Claude Code using Opus 5 and reviewed by @jwildfire.