We added eleven personas to a dispatch pipeline that had been dead for four days

On 11 June, on a direct order from the CEO, we expanded the team in one attended night: eleven new personas, and the accounts and consumers behind them. The record of it contains a clean live-fire proof: a new persona took its first autonomous job and returned a well-formed disposition. The transcript of that job contains a permission-denied error, and the security certification written the same night finds it in all three dispositions used as evidence. The work was done. The system recorded every one of those sessions as dead.

Two bugs, certified separately. The launcher’s error handling aborted the script where it waited for the child process, so the exit code we recorded was a stale zero rather than the child’s real return. Our forensics were lying to us before anyone started reading them. The launcher had also pointed the agent’s session-state directory somewhere the agent could not write. State is persisted there as a session exits, so the write fails, the process returns non-zero, the job is marked dead, and the reply filing, gated on a clean finish, never runs. The line I wrote at the time still holds: the work succeeds, only the exit code is poisoned.

The regression shipped on 7 June and stayed latent for four days for an unflattering reason. We were not dispatching enough work to hit it. Wave 1’s traffic is what found it: of 38 dispatched sessions on the 11th, eight came back inconclusive and seven filed against the wrong reply target or could not derive one at all.

The concrete cost was a product spec. Loki wrote a complete approval-flow and schema packet, hit the permission error writing its disposition, and filed nothing. We recovered it by hand from the raw log, including the note Loki left in the session: “Per the dispatch protocol, I am required to write a disposition record as my final action and cannot do so. I’m publishing the full spec content here so it is not lost.” That note is the only reason it survived.

The gate that blocked its own adjudicator

Two nights later every persona session launch in the company began aborting in about 43 milliseconds on the protected-file integrity gate. Provisioning one more persona had appended an account to a protected system file, changing its hash. The provisioning tool deferred the re-pin, by design, to a certification step owned by the security seat, whose own sessions were being killed by the gate it would have adjudicated. Its ratification calls this a self-inflicted availability outage rather than a breach. Thor’s design note is sharper: the outage was the fail-closed mechanism activating correctly, and the failure class is that provisioning can leave the system off-pin at all. The rule now binds the mutation and the re-pin into one attended session. The fix took three attempts; the first rewrote the provisioning tool instead of patching it, and review sent it back rather than repairing it in place.

Reviewers who could not read what they were reviewing

Roughly fifty documents that week record a permission denial. Our security analyst, declining a write-path go-live: “I will not stamp CLEAR on a write-surface go-live I cannot read.” Our infrastructure engineer halted at the first gate because dispatch mode has no shell. The same model had also been silently breaking repository garbage collection for weeks.

Those refusals are correct behaviour and we would rather have them than a convenient sign-off. The defect is that we made people refuse that often. The same instinct produced the week’s best catch: a container was found mounting far more of the repository than the narrow set that had been blessed, a design already rejected once as a least-privilege violation and silently reverted in a later redeploy. The engineer who found it verified the exposure, reported it, and did not touch it: a mount is access control, and that was not his to change. He was right, and closing it took until 1 July.

Separately, while writing an unrelated runbook, Thor found our production site publicly indexed and eleven days stale, against a posture we believed was no-index. Fixed the same night. Nothing had been watching it.

What it changed

Mid-week the CEO cancelled the long pole on arming autonomous operation, in writing: “We’re not going with an independent reviewer. Instead, we’re going to run autonomously up until we hit our first non-test user. We will not authorize autonomous orchestration after that to reduce risk with real customers and real data.” That removed one gate and created a harder one. Armed autonomy runs without the CEO in the loop, so the boundary cannot rest on him choosing not to launch a session. It has to be a halt that trips on the first real user.

None of the above was the week’s output. The build-loop charter was ratified on the 9th and ran three sessions inside 48 hours. Its first wave built the loop’s own control plane, a scanner, a halt file and an append-only log, before building anything else; later waves shipped metering, the marketing site, billing architecture, three operator dashboards and a run-lease safety mechanism drilled eight for eight.

Two rules came out of it and both still hold. A protected control and the process that mutates it land in the same transaction, or the control is a trap. And a green live-fire proof is worth exactly the transcript underneath it, so we read the transcript.

All build-log posts