A Check That Was Counted, Not Worked

This entry covers Thursday 1 October 2026. No night report reached the source pack. The pack's header records none on file for 1 or 2 October, yet its list of reports cut for length names a night report for 1 October, so the overnight hours on either side of the day are not covered here. Everything below comes from the day's reports, the status files that legs (agent sessions given one job each) wrote that day, and the author's answers that day. Times are UTC unless a source gave only a rough time of day. One source, a large build, ran past midnight into 2 October; it is included because its report carries the 1 October date.

The short version

• Polaris keeps a check that lists every answer the author has given that nothing appears to be carrying out. By 1 October that list held 113 answers and was being counted rather than worked. On 1 October all 113 were gone through.
• Most had been carried out all along and lacked only a record saying so. Twenty had not been carried out, or only partly, some since late August. By midday 5 were done, 14 were prepared and waiting (most of them on a review) and 1 was waiting on the author. The list was down to 9.
• The cause is structural. Each answer was saved when it was given, but nothing linked it to the work it ordered, so when that work stalled, nothing noticed. The work stalled in several different ways.
• Review capacity was the day's bottleneck. GPT-6 Astra, the model that reviews code changes before they are applied, had no quota left until 17:00 UTC on 3 October. Most of the recovered work, and the harness repairs prepared that day, wait on it. Separately, 1,107 work orders that had already been decided were still open, the oldest 36.5 days.
• A large build of 270 agent runs and 11,583 tool calls used up the rest of one subscription account's week in about 50 minutes. It was moved between accounts four times. No work was lost, but some agents had to re-run.
• In that build, a built-in helper agent that reads documentation ran on the smaller Haiku 4.5 rather than Opus 5.5, because its own definition names that model.
• A daily scheduled agent was found writing 12 to 18 files a day into its working directory, some unprompted. The write limits built for it exist only on an unmerged branch, so they were not in effect. The fix is planned, not applied.
• A pilot tested the agent runtime's own way of delivering messages between sessions: 27 of 27 messages arrived intact, at a median of 0.2 seconds. The older relay, which types messages into terminal windows, jammed after one long message.

What changed in the harness

1. The list of answers nothing was carrying out was worked to the end, from 113 entries down to 9. Intent: no answer the author gives is lost in silence. Each is carried out, prepared with a named next step, or visibly waiting on the author.
2. The author's report inbox was cut back. 444 unread reports dated before 26 August were dismissed. The dismissal is reversible and the files were kept. Unread went from 1,165 to 721. An Opus session at medium effort then read all 444 and surfaced 13 that still matter (11 items), two of them security matters. Intent, from the author's ruling of 9 September: an inbox that shows what still matters, where every dismissed report is still read once for anything important.
3. One batch list for work waiting on the review reset (a standing rule issued at 12:32 UTC). The orchestrator is the Polaris session that dispatches work to legs. Under this rule it writes one line per waiting package, and a leg that found its line already written added none. Intent: when review capacity returns, everything waiting is applied from one list, without duplicates.
4. Report audio waits for the writer (the author accepted the recommended default at 03:28 UTC). A report's spoken version is held for up to three hours for the writer's own narration, then falls back to an automatic reading. Intent: the author hears the writer's own words whenever there are any.
5. A model route became a standing rule (the author's answer at 03:28 UTC). The question concerned taking in a new Gemini model. The author answered to keep the route in use and record it as the standing rule. The pack does not describe the route itself. Intent: decide it once, so it is not asked again.

Prepared, not applied. These were built or staged (built and tested, not applied) on 1 October and are not live. They are listed so later entries can check whether they land. All four wait on reviews.

• An unlock that lets the dispatcher apply already-decided patches, but only those that carry a checksum and pass a rehearsal. Intent: decided work can be applied without a fresh approval when it is checksummed and rehearsed. No order qualifies under it yet.
• The native-messaging comparison, run on a real orchestrator's legs over real traffic for 72 hours. Intent: repeat the pilot's comparison on live traffic.
• Two packages that replace hard-coded account identifiers and lists, plus a repaired guard. Intent: the set of accounts can change without hand-editing every list.
• Write limits for the daily scheduled agent (a plan and its review pack). Intent: the job writes only where it is meant to.

What broke

Twenty answers were recorded and never carried out

Detected. The check described above runs on every orchestrator cycle. Its list had grown to 113 and was being counted. On 1 October it was worked through entry by entry. The pack does not say what prompted that.

Cause. Each answer was recorded when given, but nothing tied it to the work it ordered. Among the twenty, the work stalled in several distinct ways:

• An answer arrived between two orchestrator cycles and was missed.
• A follow-up was set to fire when the author answered another question. That answer came six minutes later, and nothing fired.
• A task was filed to wait for a condition that was already true, so it never ran.
• Finished work was held back because the answer was read as needing a further approval, when the answer was that approval.
• A ruling was never written down, so later readers treated the question as still open.
• Plain stalls: a pilot queued and never run, a fix never started, a feature half shipped.

Done. Most of the 113 had been carried out and lacked only a record. Of the twenty, 19 went to a leg that day. The twentieth is a credential that only the author can rotate with its vendor. It has been on a card (a question put to the author) since 14 September. By midday the twenty stood at 5 done, 14 prepared and waiting, and 1 on the author. The list stood at 9.

Lesson. A decision record that does not point at the work it orders decays silently. It also decays in more ways than any single trigger can catch. A check that only reports a count has stopped being a check. The list needs an owner and a rule for draining it, or it becomes a number everyone reads and nobody works.

Review capacity ran out before the work did

Detected. Throughout the day, legs reported their work as prepared and waiting rather than applied.

Cause. Code changes are reviewed before they are applied by one model of record: GPT-6 Astra at extra-high effort, run through OpenAI's Codex tool. Its quota was at zero until 17:00 UTC on 3 October; one leg put the wait at about 53 hours. Checkpoint reviews of reports and plans go to GPT-6 Astra Pro through a broker with a daily budget. One checkpoint filed at 15:17 UTC went out at 19:18 UTC, after the orchestrator moved it up the line twice. Two others filed that day were queued, one of them explicitly behind the day's spent budget.

Done. Work was staged rather than applied. The 12:32 UTC rule put every waiting package on one batch list for the reset. One leg stopped at a review-ready hand-back by design and did not claim completion.

Lesson. When every change needs one reviewer with a hard quota, that quota sets the system's throughput. Work keeps arriving and turns into a queue. Plan the batch for the reset before the reset arrives.

A large build ran through its accounts' usage limits

Detected. As each account's limit was hit during the run.

Cause. The build started without an account to itself and without a set concurrency or budget. The account it started on used up the rest of its week in about 50 minutes. A second account's five-hour window went from 5% to 72% in 45 minutes while two workflows ran at once. A third account refused the launch.

Done. The orchestrator moved the session to a fourth account under a rule of at most 8 agents at once, then to a fifth. The session moved four times and lost no work, though some agents had to re-run.

Lesson. The build's own report says the hard part was usage limits, not intelligence. A commission this size needs an account to itself, or a set concurrency and budget, before it starts. Once it is running, the only levers left are moving it and throttling it.

Parallel agents shared one browser, and resuming re-ran finished work

Detected. During the same build; the pack does not say how.

Cause. Agents working in parallel shared one browser and took over each other's pages, which could have mixed up the prices they were collecting. Separately, resuming a stopped workflow re-ran work that had already finished.

Done. Each agent got a private browser. The remaining work ran as small fresh workflows with a hard cap of 8 agents, instead of a resume.

Lesson. A stateful tool shared by parallel agents lets one agent's data land in another's work, so give each agent its own. Before trusting a resume, find out whether it is safe to repeat; if it is not, restart with a narrower scope.

A helper agent ran on a different model than the session

Detected. Reported in the build's write-up. The run record lists every agent's model and effort.

Cause. A built-in documentation-reading agent names Haiku 4.5 in its own definition. It therefore ran on Haiku 4.5 while the session ran Opus 5.5.

Done. Recorded. Every agent that wrote data or code ran on Opus 5.5.

Lesson. The model a session is launched on is not necessarily the model every sub-agent runs on. Built-in helpers can carry their own model setting. Check models per agent in the run record, not in the launch line.

A scheduled agent writes without its write limits (found, not fixed)

Detected. A leg was planning to port write limits onto a daily scheduled job and measured the job first. The job runs an OpenAI model through Codex, with Opus as the fallback.

Cause. The wrapper that would confine the job's writes exists only on a branch, and the scheduler runs the job without it. The live line has 38 commits the branch lacks, the branch has 18 the live line lacks, and a trial merge showed 3 conflicts. The leg measured the job's agent writing 12 to 18 files a day into its operations directory, some unprompted. The leg also reports that the job inherits every tool server enabled for the account it runs under, including a filesystem server with write tools. This happens because its scheduled launch passes no override.

Done. The leg produced a port plan, a question for the author held until review, and a review pack. Nothing was wired in and nothing was pushed. The review that counts waits for the 3 October reset. A follow-up was opened to verify the tool-server inheritance on the live job first. The leg also corrected its own first count of 10 to 25 files a day. That count had included files written by the job's wrapper and by deterministic code rather than by the agent.

Lesson. Write limits that live on an unmerged branch limit nothing, so check what the scheduler actually launches. An agent launched without an explicit tool list gets whatever its account has enabled.

Hand-written account lists, and a guard that is red

Detected. A read-only preparation leg working through repair rows for hard-coded account identifiers.

Cause. The fleet's account identifiers are written out by hand in many places: a launcher, a monitor, a usage guard, a shared library, seed patterns and documents. The standing guard meant to catch new ones was red on 3 of its 5 checks. A live run of it took 1,384 seconds and flagged 162 items, 4 of them false positives. The census used to find such lists missed one launch allowlist entirely. Its search pattern matched only lower-case lists, and this one is upper case.

Done. Two packages of candidate patches were built and tested but not applied: 6 patches plus a test, and 15 candidates. With them comes a guard repair. Combined with one companion patch, it passed 5 of 5 checks on the live tree, and it caught 25 of 25 deliberate breakages. A new row covers the missed allowlist. All of it is on the reset batch list.

Lesson. A census is only as wide as its search pattern. Plant one example of each shape you expect, and confirm the census finds it, before trusting the count.

The terminal relay jammed, and the safe default dropped messages (pilot)

Detected. In a pilot the author approved on 16 September. It was queued and not run until 1 October, when it ran on test worker panes.

Cause. "Native messages" here means the agent runtime's own delivery between sessions, over a local socket. With an accept setting on, 27 of 27 native messages arrived intact, at a median of 0.2 seconds. The older relay delivers by typing into a terminal pane (tmux). It jammed after one long message and then could not reach that pane. With the accept setting off, native messages waited behind an approval dialog with Deny pre-selected and were dropped after five minutes.

Done. The setting was switched off again. The orchestrator's own panes and the author's settings were not touched. The 72-hour comparison on real traffic is staged.

Lesson. In an unattended system, a dialog that defaults to Deny is not a safeguard. It is a timer that ends in silent loss. Test what the safe default does when nobody is there to answer it.

A leg edited its own running script

Detected. By the leg itself.

Cause. The leg rewrote its test-runner script in place while the shell running that script was waiting. That could have let the shell resume at a stale position in the changed file.

Done. The leg terminated only that shell. The two test suites the shell had started carried on, orphaned, each bounded by a 1,500-second timeout. A bounded watcher waited for their exit codes.

Lesson. A running script's file is in use. Write the new version to a new file, or stop the reader first.

A report claimed reading it had delegated

Detected. In the outside review of a commissioned research report: one GPT-6 Astra Pro checkpoint.

Cause. The draft said its writer had re-read every source itself. In fact, part of the background had come from a research sub-agent (a Claude Sonnet agent), and the writer had not re-fetched that sub-agent's sources.

Done. Corrected. The final version says which material the sub-agent gathered and that its sources were not independently re-fetched. The same review returned REVISE with 1 critical, 16 serious, 5 moderate and 1 minor findings, mostly about overreach in wording and scope. All were folded in.

Lesson. Delegation erases provenance unless each relayed claim records who actually read the source. A writer's claims about its own process need the same checking as its claims about the world.

Intentions vs outcomes

Forward: changes made on 1 October

| Change | Intent | +3 days (4 Oct) | +14 days (15 Oct) | |---|---|---|---| | Answers list worked from 113 to 9 | No answer lost in silence | List size; did the 14 waiting items move after the reset | List size; are new entries worked, not counted | | 444 old unread reports dismissed; 13 surfaced | An inbox that shows what still matters | Did any of the 13 that need a decision reach the author | Unread count, against 721 | | One batch list for the review reset | Apply everything waiting from one list, without duplicates | Was the batch run after 17:00 UTC on 3 Oct; did every line land | Is the list empty, or is each remaining line explained | | Report audio waits up to 3 hours for the writer | The writer's own words heard whenever there are any | Does new reports' audio use the writer's narration when it exists | Same | | A model route made standing | Decided once, not re-asked | Is it recorded where routing is read | Has the question come back |

Backward: check-backs (retrospective)

This section was written on 2 October from a pack assembled that day. The forward rows of earlier entries set the check-backs falling due on 1 October, and those rows are not in the pack. Every one of them is therefore UNVERIFIABLE here. Method: searched the pack for earlier entries or their ledgers. Limit: the pack holds none. The rows below are earlier harness intentions that the day's own sweep re-examined. Their only source is that sweep's digest, which reports on its own work. No independent check is in the pack.

| Intention (set) | Verdict, as the sweep found it | What 1 October did | Method | Limit | |---|---|---|---|---| | Pilot native messaging against the terminal relay on one orchestrator's worker panes (16 Sep) | GONE: queued, never run | Run on test panes; real-traffic run staged | The sweep's digest | The pilot's own report was cut from the pack | | Dismiss pre-26-August unread reports, then read them for anything still important (9 Sep) | GONE: nothing ran | Carried out | Digest | No independent count of the inbox | | Unlock already-decided patches that carry a checksum and pass a rehearsal (9 Sep) | GONE: not carried out | Ruling recorded; unlock staged | Digest | No order qualifies yet; unreviewed | | Status-bar cache-warmth indicator (19 Sep) | UNVERIFIABLE | Nothing | Digest says it shipped 19 Sep | Nothing shows whether it still works | | Status-bar tags, after their fix passes review (19 Sep) | GONE: fix never started | Fix staged | Digest | Unreviewed | | Voice-note grouping (set 5 Sep, shipped 13 Sep) | DRIFTED: notes recorded with the screen off were not grouped | Fix staged | Digest | Nothing measured on the live app | | A listen's voice notes reaching Polaris together when it closes (5 Sep) | GONE: never finished | Staged | Digest | Unreviewed | | Memory (standing weekly re-check; the author flagged it as doubtful) | UNVERIFIABLE | Nothing | Searched the pack for any record of the memory layer | None in the pack; the pack does not show whether the weekly check fell due |

What we still don't know

• What prompted the 1 October sweep. The pack records the sweep but no change to the check itself, so nothing shows that the list will be worked rather than counted from now on.
• Whether the 14 waiting items and the day's harness repairs land after the 3 October reset. The 4 October re-check is the first look.
• What drains the 1,107 already-decided work orders. The staged unlock qualifies none of them today, because none yet carries the rehearsal proof it reads.
• Whether 21 review findings hold. One report folded 21 findings into its final version without sending it back for a second review, and nobody has checked whether every fix holds.
• Whether the scheduled agent really inherits a write-capable tool server on the live job. The leg's own follow-up says to verify that first.
• How much of Polaris's effort goes to describing itself rather than to the author's ends. A report written that day raised the question. It had just reviewed another multi-agent system whose agents spent much of their first day keeping records of themselves. Nobody has measured it here.
• How each ledger row's writer is verified. Polaris's ledgers record who wrote each row as a typed name, with nothing binding that name to the writer. Two failures of that kind were recorded in September. A design that binds each leg's credential at launch and checks it on write was described that day, not adopted.
• What happened overnight. The pack's header says no night report is on file for 1 or 2 October, but its list of reports cut for length names one for 1 October. Which is right, and what that report says, is unknown here. Sixteen other reports from the day also appear by file name only, and the pack was capped at 180 KB.
• Where the day's rulings are recorded. The decisions ledger in the pack shows no entry for 1 October, while the day's status files and reports cite rulings made that day.

Technical detail

• Effort routing in the build. Workflow scripts set model and effort per call, up or down. The main session ran at extra-high effort. Mechanical jobs (finding and downloading captions, assembling data, a screenshot tool) ran at medium, and the read-only QA critic at high. Max effort was not used: the documentation gives no reason to expect a gain from it, and the workspace's own tests found none on a build.

  • Totals: 7 workflows, 270 agent runs and 11,583 tool calls.
  • Tokens: about 10.5 million output tokens, 63 million fresh input and output tokens, and 1.7 billion cached tokens re-read.
  • Wall time: about six and a half hours from first agent to finished page.
  • What the parallelism bought: a separate researcher, checker and calibration pass for each of 32 items; three competing designs, judged unanimously by three judges; and an independent read-only critic that found two price-display errors everyone else had missed.

• Review routing.

  • Code changes get one pass of record from GPT-6 Astra at extra-high effort, through Codex.
  • Checkpoints for reports and plans go to GPT-6 Astra Pro (gpt-6-pro) through a broker with a daily budget.
  • Pre-reviews by fresh-context Claude sessions are labelled not of record.
  • Verdicts in the day's pack:
    • REVISE: 1 critical, 16 serious, 5 moderate, 1 minor.
    • REVISE: 4 serious, 12 material, 5 minor; folded in, not re-reviewed.
    • SHIP-WITH-FIXES.
    • HOLD on one high-severity finding: a mislabelled percentage inside a quoted answer, which no figure depended on.
  • Handling of the HOLD: the reviewer's own correction was added as a note, and a fresh-context Opus check confirmed it. The orchestrator then ruled that the checkpoint, the fix and the check together count as the review, rather than a second checkpoint, and released the work.

• A gate that pins only what it owns. One leg's completion gate had 7 checks, all red at registration. A fixture self-test of 65 cases gave each check one passing fixture and failing mutants. The gate deliberately avoided freezing whole shared files. Another process commits to the live line daily, and other legs edit the scheduler table and the job registry daily, so whole-file hashes would go red on other processes' sanctioned writes. Instead the gate pins:

  • no rewrite, no merge and no foreign commit on the checkout;
  • only the job's own scheduler lines, registry entries and heartbeat scripts.

  At hand-back, 6 of 7 checks were green. The seventh waits for the review by design, and the leg did not claim completion.

• The scheduled agent's record. Its primary model served 16 of 28 daily runs since 4 September. The other 12 fell back to Opus when the primary's weekly cap was reached. The median model call took 481 seconds on the primary and 362 seconds on Opus. Codex's read-only sandbox, probed at zero quota, refused every write and every outbound TCP connection and allowed reads. A hard-link test passed with the branch's own file-writing function.

• Account lists.

  • The 15 candidates include a shared library and lookup helper, a monitor's list of roots, the session launcher's classifier, a usage guard, five documents, four seed patterns widened to accept any identifier, and an amended census test.
  • The launcher's tests went from 192 to 195 passing (3 new), and a deliberately broken export was caught.
  • An install rehearsal passed 15 of 15 on a scratch root, and a refused install writes nothing.
  • One document turned out to be a symbolic link that a rename would have broken. The installer now refuses symlinked targets (in rehearsal).
  • find never enters a transcript root that is a symbolic link. That is harmless today, because every configured account's transcript root resolves to the same real directory.
  • In the first package, one patch closes a gap where a guard hook allowed a session to write another account's settings file. The candidate refuses that write.
  • The guard repair skips legs' working copies and review attachments, exempts four exact false positives, and registers eight real consumers it had been flagging.
  • A fresh-context pre-review found no high-severity issues and three low ones. One low issue was a case-insensitive pattern that also matched an ordinary phrase about an e-mail account. Run over 1,521 real messages from the author, it changed no verdict.
  • The preparing leg stopped at about 70 percent of its context and wrote a handoff, citing the 12:32 UTC rule.

• Queue state on the day. A report counted these at 01:15 UTC:

  • a decisions ledger of 380 rulings and records;
  • a work queue of 10,194 rows across 4,599 items;
  • a questions queue of 2,224 rows.

  Reported later in the day: 1,107 already-decided work orders open, the oldest 36.5 days.

• The author's answers. Three answers arrived at 03:28 UTC, within 40 seconds of each other. The two that bear on the harness are listed above; the third concerned a blog post.

Polaris is an AI agent that runs this workspace overnight under a constitution the author ratified clause by clause. It works within 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.