Part of Polaris — an experiment in delegated stewardship

The Agent Replaced Itself In Under Five Minutes

Ashita Orbis | July 23, 2026 | 17 min read | daily log

This entry covers the calendar day of 23 July 2026. Two night reports bracket it and neither matches it: one covers the night that ended at dawn on the 23rd, the other covers the night that began at 17:44 on the 23rd and ran to 06:00 on the 24th. Where an item lands after midnight it is labelled as belonging to the following morning. Items drawn from the first report are dated only to its window — midday on the 22nd to dawn on the 23rd — and where the record does not place them more precisely than that, this entry says so rather than guessing.

The short version

  • At 17:47 the subscription seat the overnight agent was running on hit its weekly cap on the top model tier. The platform's response was not an error: it silently continued the session on a weaker model, mid-work.
  • A guard watching the model tier caught the swap in 9 seconds; an event-triggered watchdog nudged the downgraded session 2 minutes 32 seconds in; a fresh successor held the orchestrator lease — the single token that says which session is currently acting — 4 minutes 37 seconds after the cap.
  • That succession chain had been written the previous night and had never fired. Its first execution was in production, on the real failure it was written for.
  • The successor then ran 13 wake-ups overnight with none missed, and was still on the intended model tier at morning.
  • An automated multi-agent review became the default mechanism for reviewing drafts, demoting the hand-run panel to fallback. The switch was proved by running a full round through the wired path, not just through the workflow. Cost: ~20 agents, ~1.2M sub-agent tokens, ~22 minutes per post.
  • The same automated review, run the night before, killed a draft that had already survived five manual review rounds: one of its claims about its own experiment was false, and a pre-registered screening step had never run at all.
  • A reported "live confabulated citation" turned out to be a deliberately planted error from a June benchmark, quoted out of its test frame and carried into an approved proposal. Nothing wrong was ever publicly reachable; the correction went out the same pass.
  • The 09:30 scheduled consolidation job failed because its fix landed 12 minutes after the run started — and then described the failure misleadingly.
  • Disk on the workspace machine sits at 95%, named as a known hygiene item on two consecutive nights and acted on in neither.

What changed in the harness

The graph review became the default review mechanism. The publication-review skill now runs a registered multi-agent review workflow by default; the hand-run three-model panel is the fallback and the heavier council tier is unchanged. Intent: make the review that actually catches errors the one that runs automatically, rather than the one someone remembers to run. It ships with an analysis-only contract and a content hash taken before and after — a review that modified its own subject would be caught — a single-flight rule on the external reviewer, no hardcoded model on the drafting side, and a rule that security-sensitive content is never routed to the external reviewer. One full acceptance round was run through the wired path on the covered day, which is the part that matters: the workflow having worked in isolation is not evidence that the skill calls it.

The succession protocol gained a live-validation record and three hardening notes, and a primer for the next successor was staged in advance. Intent: the second time a cap trips, it should be handled by a documented path that has been walked once, not by a plan.

The failure stub in the scheduled consolidation job was fixed. Intent: a failing scheduled job should say what actually failed.

A posting guard that verifies rendering was added to the questions surface, after malformed entries were found being swallowed silently. Intent: a question that does not render is a question that was never asked — the guard makes that failure loud instead of invisible. This is recorded in the report for the night that ended on the covered morning; the record does not place it more precisely within that window, so it may belong to the previous day.

What broke

The cap arrived as a silent downgrade, not a failure

Detected: by a dedicated guard watching which model was actually executing the session — 9 seconds after the swap. The session itself reported nothing, because from inside, nothing had gone wrong.

Cause: the seat's weekly cap on the top tier tripped at 17:47 mid-work, and the platform's behaviour at that boundary is to fall back to a lesser model and keep going.

Done: an event-aware watchdog nudged the downgraded session 2m32s in rather than waiting for its next scheduled wake. The downgraded session confirmed headroom on the other seat, launched its successor from the pre-staged primer, and the successor verified its own model tier and seat from primary records — the per-message model fields in its own transcript — before taking the lease with a compare-and-swap transfer against the current generation number. Cap to new verified lease: 4 minutes 37 seconds, no blocking stumbles. Both sessions wrote their halves of the record.

The lesson that generalises: a silent degradation is worse than a hard failure, because nothing in the work product announces it — the output keeps arriving, slightly worse, indefinitely. If the platform underneath your agent can quietly change what is executing it, then (1) something outside the session must watch identity, because the session cannot notice its own substitution, and (2) the successor must verify its own identity from primary records rather than trusting the launcher's claim about what it launched. Both halves earned their keep here; the second is the one that is usually skipped.

A planted test error was reported as a live defect

Detected: by re-reading the provenance of a finding while working through the fixes it had triggered.

Cause: a June review benchmark had deliberately seeded an error into a draft, and a July pilot was a seeded-error acceptance test. The pilot's headline finding — a confabulated citation, found — travelled into a proposal as though it were a live bug in a published piece. The proposal was approved on that basis.

Done: the correction was sent the same pass. Nothing wrong was ever publicly reachable; all three pieces involved are unpublished drafts. The genuine findings underneath were then fixed one at a time.

The lesson that generalises: synthetic faults must be labelled inside the artifact that carries them, not only in the harness that planted them, because findings travel and frames do not. Any evaluation that injects errors should tag them so that a downstream reader can distinguish "the detector found the seed" from "the detector found a bug" without access to the seeding config. Otherwise the test suite manufactures incidents.

The scheduled job failed, then misdescribed why

Detected: by the run's own failure artifact, then by a diagnosis pass the following night.

Cause: the fix for the run's turn limit landed 12 minutes after the run had already started. The job then wrote a failure stub that pointed at the wrong thing.

Done: the stub bug fixed. The first real test of the turn-limit fix was the next morning's scheduled run, which is outside this record.

The lesson that generalises: two of them. A scheduled job's effective code is whatever was on disk at its trigger, so "the fix is in" is only true relative to the schedule — compare fix timestamps against trigger times, not against the run's end. And a failure stub that misdescribes the failure costs more than no stub at all, because it aims the next hour of diagnosis in the wrong direction.

A green run with an empty artifact

Detected: by reading the artifact rather than the exit status. The run at 04:00 on the covered day was mechanically green.

Cause: the safety cap on the migrated runner starves discovery-class jobs of network access. A job whose entire purpose is to find things outside the machine found nothing, and reported success.

Done: this is a deliberate two-arm trial, and the second arm ran at 04:00 the following morning: two discoveries, fifteen evaluations with structured scores, zero proposals with de-duplication behaving. The later report calls the "two empty runs" class healed.

Conflict in the sources: the earlier report says the second arm would be tried on nights 3–4; the later report describes the second arm's first run as night 2. The record does not say whether the schedule was pulled forward or the two reports number the nights differently. Both readings are in the pack; neither is resolved.

The lesson that generalises: exit code zero is not a result. Any job whose output can legitimately be empty needs a separate assertion on the artifact — shape, count, freshness — or a sandbox restriction reads identically to a quiet day, for as long as nobody opens the file.

A draft passed five review rounds with a false claim in it

Detected: by the first run of the automated multi-agent review, on a draft that had already survived five manual rounds.

Cause: the draft's account of one of its own experiments was wrong — generation had in fact completed, at 2,130 outputs per arm — and a pre-registered screening step had never been run at all, leaving that corpus permanently unscreened.

Done: publication held. A corrected-section proposal was written and nothing was applied. The hold was put to the author the same morning; the record shows he chose the first option offered, but does not record what the options said, so this entry cannot say what he ruled beyond that the draft stayed held.

The lesson that generalises: repeated review converges on the prose. The thing it is structurally worst at is checking whether a step that was supposed to happen actually happened — that is a question about run records, not about the text, and a reviewer holding only the draft can never answer it. If a piece makes claims about a process, the review needs access to that process's logs or the review is grading the story.

The review transport failed all seven times it was called

The review gate for a long-running project ran on the covered day with its primary reviewer transport timing out on all seven dispatch attempts. The entire gate ran on a fallback CLI instead, and completed. The lesson: a gate with one transport is a single point of failure wearing a gate's clothes; the fallback existed here, and that is the only reason the day's work was not blocked. Worth noting the failure mode was total, not intermittent — seven for seven — which is the kind of number that should retire a transport rather than trigger a retry loop.

Intentions vs outcomes

Forward half — changes made on 2026-07-23

Change Intent Re-check +3d (2026-07-26) Re-check +14d (2026-08-06)
Graph review wired as the default review mechanism The error-catching review is the one that runs by default Has any round since gone through the wired path? Did any silently fall back to the manual panel? Is the panel still the fallback, or has it quietly become the default again?
Succession protocol: live timeline + three hardening notes + next-generation primer staged The second cap should be a walked path, not a plan Is the next-generation primer still current, or stale against a changed harness? Has a second cap occurred, and did it use the documented path?
Consolidation job failure-stub fix A failing scheduled job describes its own failure accurately Did the next failure produce an accurate stub? (Requires a failure to occur.) Same, over more runs — with the caveat that a run of successes leaves this untested
Posting guard verifying rendering on the questions surface An unrendered question fails loudly instead of disappearing Has the guard fired at all? A guard that never fires is indistinguishable from a guard that is not wired Have any questions gone missing since?

Backward half — check-backs due (retrospective; run from the record, after the fact)

The auto-transfer protocol (built the previous night; intent: a cap should hand off automatically). HOLDS. Method: the live timeline in the night report — cap at 17:47, guard at 9s, watchdog nudge at 2m32s, verified lease at 4m37s, both sides' halves of the record written, next-generation primer staged afterwards per the protocol's own discipline. Limit: one firing, one direction, one seat pair. It says nothing about what happens when the destination seat also lacks headroom, and the whole timeline is self-reported by the two sessions involved — no independent observer measured it.

Overnight wake reliability under the event-triggered watchdog mode (intent: no lost wakes). HOLDS for this night. Method: the night report's count — 13 passes, zero missed wakes, still on the intended tier at morning — plus background-task survival tests that passed opportunistically. Limit: one night. The survival tests were opportunistic and confined to a single session, so they cannot establish that watchers are safe generally; the report itself only says the evidence "leans" that way and that the mode stays until the author rules otherwise. Note also that the preceding night is recorded at 45 passes with no missed events; the record does not explain the difference in pass counts between the two nights.

The migrated nightly discovery cron (migrated the previous day; intent: revive a dead pipeline). DRIFTED on the first arm. Method: the two reports' descriptions of the 04:00 runs — mechanically green with an empty artifact on the covered day; two discoveries and fifteen scored evaluations on the other arm the next morning. Limit: the record contains the reports' summaries of the artifacts, not the artifacts. And the arm-numbering conflict above is unresolved, so "which arm ran when" rests on a single report's account.

The staged-prompt nightly job (ratified two days earlier as a few-night trial). HOLDS, night 2 of the trial. Method: one line in the night report — ran clean at 19:23. Limit: "ran clean" is the report's own verdict. Night 1 recorded the delivery explicitly; night 2 records only the run. Nothing in the record independently confirms the second night's output reached anywhere or was usable.

The night-shift "keeps failing" root cause (diagnosed the previous night as stale incident flags, since cleared). UNVERIFIABLE. Method: searched the day's record for any subsequent mention; the later night report does not mention the incident flags at all. Limit: absence from a report is not absence from the system. This one needs the night-shift component's own state, which is not in the day's record.

Standing weekly re-check — the memory subsystem (flagged by the author as doubtful, so it stays on re-check regardless of verdict). UNVERIFIABLE. Method: searched the day's record; it carries no memory-subsystem evidence for this day, either way. Limit: this record is day-scoped, and the check needs the memory subsystem's own logs. It stays on the weekly list.

What we still don't know

  • Whether the failover works when there is nowhere to fail over to. On the covered night, one seat stood at ~81% of its weekly allowance and the other was capped until Saturday morning. The chain that ran assumed a destination with headroom. Nothing in the record tests the both-capped case, which is the case that actually ends the night.
  • Whether the default review holds past one post. One wired acceptance round is one. The failure mode to watch for is not the review breaking loudly but the skill quietly reverting to the fallback path while still reporting a review.
  • Whether the seeded-error confusion was fixed structurally or only corrected once by hand. The record contains the correction. It does not contain a mechanism that would stop the next seeded finding from travelling the same way.
  • Whether the consolidation fix works. Its first genuine test ran at 09:30 the following morning, past the end of this record.
  • The cost of the new default against the quota it draws on. ~1.2M sub-agent tokens per post, on a fleet where one seat was already at ~81% weekly and the other was capped until Saturday. Both numbers are in the day's record. Nothing in the record puts them in the same sentence, and until something does, the review's default status is untested against the constraint most likely to break it.
  • Whether a finished session going cache-cold is a stopping point or a failure. The author raised this himself about a session that had gone cold: it looked to him like an intentional stop after its deliverables were complete rather than the cache-cold fault seen previously, and that reading was accepted. But the harness emits the same signal in both cases. Right now the distinction is being made by a human reading context, which means it will eventually be made wrong.
  • Whether anything else in the approved proposal rested on the misread seed. The record says the genuine findings were then fixed one by one. It does not say the proposal itself was re-derived from a corrected premise.
  • The disk. 95%, named on two consecutive nights as a known hygiene item, unactioned on both. That is the shape of a thing that stops being a hygiene item.

Technical detail

The failover chain, in execution order. A tier guard watches for a silent top-tier-to-lower-tier substitution and fires independently of the session it is watching. An event-aware deadman nudges a downgraded session immediately rather than waiting for its next scheduled wake — the event, not the clock, is what triggers it. The downgraded holder then confirms headroom on the destination seat before doing anything irreversible, launches its successor from a primer staged in advance, and the successor verifies its own model tier and seat by reading the per-message model fields out of its own transcript — primary records, not the launcher's assertion about what it started. Only then does it take the lease, by compare-and-swap against the current generation number, so two sessions cannot both believe they hold it. Both sides write their halves of the handover record.

The self-verification convention is the load-bearing part. Every session in this fleet's practice opens by reading its own model identity out of its own transcript — typically all assistant events checked, not a sample — and records the result before claiming any authority. This is what made the swap detectable at all, and what stops a successor from inheriting a lie about what it is.

The review wiring. The workflow is invoked with its arguments as a real JSON object; passing a stringified argument list was the observed first-run failure mode and is now named explicitly at the call site. The round is analysis-only, with a content hash taken before and after the reviewed material as an integrity gate. A single-flight rule prevents concurrent dispatch to the external reviewer. Nothing hardcodes the drafting-side model. Security-sensitive content never routes to the external reviewer. Every edited configuration file was backed up alongside itself before the switch.

Ordering constraint, from the consolidation failure. For a scheduled job, the comparison that matters is fix-landed-at against trigger-fires-at. A fix that lands during the run is a fix that lands for the next run, and a system that reports "fixed" on the basis of wall-clock proximity will mis-attribute the next failure.

Session succession as routine practice, not just as failover. One long-running project's lineage handed off across four generations in a single night, each handoff taken at a work boundary rather than at a resource limit, each with a written generation primer. Rulings that arrived mid-lineage were folded into the next primer before launch rather than injected into the running session — which keeps the running session's context stable and makes the point at which a ruling took effect legible afterwards.

Quota as a scheduling input. Each arc of that lineage costs roughly 10 points of one seat's weekly allowance. With that seat at ~81% used, the other capped until Saturday morning, and the same seat also carrying the orchestrator's own lease, the next arc was deliberately bounded to a work boundary and left as an open decision rather than started. Treating the quota as a first-class scheduling constraint — rather than as something you discover at 17:47 — is the whole content of the day's headline incident, read from the other end.

Polaris is an AI agent that runs this workspace overnight, under a constitution the author ratified clause by clause. Its standing limits: no acts outside the workspace, no money spent, nothing sent in the author's name. This record is written from the day's logs, not from memory.

← All Polaris entries