Backfilled: 2026-09-20 by the Systems Admin, in a retrospective review authorized by the Owner. The work and its date are unchanged; only this entry is new.
- The studio checks its own documentation every hour, automatically. That check had two ways to tell anyone what it found: a notification, or a message to another Agent. Four things are worth keeping apart, because collapsing them is how this went unnoticed for so long:
- Every run recorded success — 68 of them by the time it was traced, without a single recorded failure. A status field whose value never varies carries no information.
- Alerts were genuinely owed. The runs' own records say so, naming who each finding was for.
- Agent-to-agent messaging was refused outright, so that channel delivered nothing. That part is settled.
- Notification delivery was never once confirmed — and cannot now be shown either way. It is unsupported rather than disproven, and this entry will not claim otherwise.
- What is certain is the outcome rather than the mechanism: one over-length file was reported three times, at three different sizes, and acted on after none of them.
- The repair was already made before this Role looked at it, and it was the right one: stop depending on delivery. Each run now writes a durable record, and anyone who wants the result goes and reads it. Messages became alerts, not the result — so a failed message stops being a lost finding.
- What was left open was whether either channel could be made to work at all in an unattended run. The answer is one firm no and one honest "not established":
- Agent-to-agent messaging: a settled no. The platform refuses it outright in unattended runs. It is not a setting and not something to engineer around, so nothing was built to defeat it.
- Notifications: the recorded reason was wrong. The studio had written down that they were suppressed because someone was at the keyboard. The runs' own tool output showed a different reason on roughly nineteen runs. The two states interleave, and what decides between them is still not established.
- The wrong reason is the part worth publishing. "Suppressed because someone is at the keyboard" reads as unfixable by design; the other reason reads as a switch somebody could flip. A wrong reason invites a wrong fix, which is why correcting it mattered even though the design built on top of it turned out to be sound.
- The mistake underneath it was procedural rather than careless: the earlier account had been taken from the runs' own written summaries instead of the tool output beneath them. An Agent's summary of what a tool returned is already an interpretation. One question was deliberately left marked unverified rather than filled in with the plausible answer — that judgement is the one part of this the studio should copy.