A director can do load-bearing work through harness subagents that Runtime never records

[drewstone]

The worked example, happening live

capability-per-parameter-cpp-glm-20260915c, a director at 9h18m on runtime 0.226.0. Its headline result — a pre-registered stake refuted with a paired cluster bootstrap — needed an independent check, so at 06:50:18Z the director spawned an opencode Task subagent on the same host to re-score the arms from raw generations.

That checker has since reproduced three of four arms exactly (12B n=1350 acc=0.4222, base 0.1593, multi exact) and found, diagnosed and explained the fourth as a staleness artifact (g4 fresh 0.2970 n=1350 against the claimed 0.2978 n=1340, ten late-arriving rows). It is the verification the result stands on.

Runtime has no idea it exists.

where	what it shows
spawn-journal.jsonl	spawned count unchanged at 69. No entry.
root-stream.jsonl	last event 06:50:18Z. Silent for the checker's entire life.
result.json / blobs	nothing; the checker has no outRef, no trace, no spend record
opencode's own opencode.db	152 parts and counting — the complete transcript, in harness scratch

An operator reading Runtime's records sees a root that went quiet for half an hour. What actually happened is the most important half-hour of the run.

Why this is not the same as #1244

#1244 is a Runtime child whose transcript dies at teardown — Runtime knows the child existed and loses its contents. This is different and worse: Runtime never learns the work happened at all. There is no id to attach a receipt to, no spend to meter, and no settle to hang a reason on. The recursion the supervisor believes it is observing (69 children, 33 settled) is not the recursion that ran.

It also silently breaks two properties the stack advertises:

• Replay. Rehydrating this run reconstructs a tree in which the result's verification never occurred.
• Budget conservation. The checker's tokens were spent through the director's own harness session, so they land in the root's own-inference total rather than as a child's reservation. The pool is not wrong, but "what did this run spend on verification" is unanswerable.

Why a director does it anyway

It is the cheapest correct move available. A Runtime child runs in a sandbox and could not see pursuits/…-glm-20260915b/workspace, where the generations being re-scored live; a same-host harness subagent can. The director reasoned exactly this, in its own words: "The checker must see the glm-b workspace paths — a fresh Task subagent on this host (independent context, did not produce the result) fits the contract."

So this is not misbehaviour to prompt away. The placement the director needed — an independent worker with access to the root's local filesystem — is one Runtime does not offer, so it stepped outside the substrate to get it.

Ask, in preference order

1. A same-host worker placement. If Runtime could place a child on the root's own host with the root's workspace visible, this work would be a normal child with a journal entry, a blob and a spend record, and no one would need to leave the substrate.
2. Failing that, record the departure. A harness that spawns its own subagents should surface them as at least a journal note with a count and a token total, so the record says "work happened here that I did not supervise" instead of showing silence.
3. At minimum, document that spawned counts Runtime children only, and that a root's own-inference spend may include an unbounded amount of unsupervised subagent work.

Related: #1244 (dropped child transcripts), #1247 (reconciliation never recovers; fleet yield), #1245 (a sandbox-placed root cannot use its coordination tools).

🤖 Generated with Claude Code

[drewstone]

Correction to my own report, and it changes the ask. I wrote "Runtime has no idea it exists." That is wrong, and the run proved it minutes later. The record is layered, and only the third layer is actually missing.

Layer 1 — the fact of the subagent already crosses. root-stream.jsonl seq 405 at 07:39:05Z:

{"kind":"tool_call","toolName":"task","toolCallId":"prt_0a8fb051c0010iSn8ezIUBUEOj",
 "args":{"description":"Verify E1 specialization result","prompt":"You are an independent checker …"}}

Runtime has the call and the entire brief the director wrote for it. My "silence for half an hour" reading was an artifact of checking before the task tool completed — opencode emits a tool part only once its state is completed or error, so a long subagent produces one event at the end rather than nothing at all.

Layer 2 — the subagent's result and its session id are fixed, unreleased to this run. The completed tool part carries:

<task id="ses_f5704fabdffeX7gBMGSh0z7Ja0" state="completed">
<task_result># Checker Report — specialization suite …

That is the subagent's whole report and an addressable handle to its transcript. cli-bridge forwarded no tool results before drewstone/cli-bridge#228 (merged tonight) and agent-runtime#1241 (0.228.0), so this run lost it. A bridge restarted on the new code would carry both. Nothing further needed here.

Layer 3 — the subagent's own turns are dropped by one line in opencode, and it looks like an oversight. packages/opencode/src/cli/cmd/run.ts v1.18.30 deliberately tracks child sessions:

const sessions = new Set([sessionID])                                    // :699
if (event.type === "session.created" && event.properties.info.parentID) {
  if (sessions.has(event.properties.info.parentID)) sessions.add(event.properties.info.id)   // :704
}

It then honours that set for permissions:

if (!sessions.has(permission.sessionID)) continue                        // :803

and ignores it for parts:

if (part.sessionID !== sessionID) continue                               // :722

So every subagent reasoning step, tool call and tool result is discarded from run --format json by a filter that compares against the root session instead of the set the same loop maintains. Changing :722 to sessions.has(part.sessionID) and stamping the emitting session id on the event is the whole fix at that layer.

Revised ask. Layers 1 and 2 are done or in hand, so drop the "record the departure" fallback. What remains:

1. Upstream run.ts:722 to use the sessions set, with the session id stamped on emitted parts. Then cli-bridge can attribute them and Runtime can journal a subagent's turns under the calling tool.
2. The same-host worker placement from the original report still stands as the better long-run answer, because it makes this a supervised child with a reservation and a settle instead of a tool call to reconstruct.
3. Withdrawn: the claim that replay reconstructs a run whose result was never checked. Replay reconstructs a run whose check is a task tool call with the full brief and, post-0.228.0, the full report. That is thinner than a child record, not absent.

🤖 Generated with Claude Code