Agent states causes, verifications and completions before running the check that would falsify them — ~9 times in one session, each cheap to check and expensive to correct

Summary

Over one long session the agent repeatedly asserted a cause, a state, or a completion before running the check that would falsify it. Each individual slip was small and quickly corrected once challenged; the aggregate cost was most of a working day, because downstream work was built on the unchecked assertion before it was caught.

The user's summary at the end: "you did 1-2 mistake and lead to error which waste time to rectify" — and, after a claim of completion that later proved wrong, "you tell me complete now the result still has a problem."

This is not a knowledge gap. The project has explicit rules requiring a receipt for every claim, hooks that block un-receipted claims at turn end, and the agent had read them. It still happened ~9 times in one session.

The shape, with concrete instances

Each of these is the same error: state a conclusion, then (maybe) check it.

1. Diagnosed a config problem as a code problem. Asserted that a control-flow branch returned early, and drafted a patch for it. The actual cause was a missing key in a config file two lines below; the branch explicitly falls through. The patch would have modified correct code. Caught only because the user asked for exact line references, which forced a re-read.

1. Reported an exit code that was never the process's. Said a gate "exits 0 despite refusing." The command had been piped to tail, so $? was tail's status. True code was 1. Reported as a product defect before checking.

1. Asserted a verification that hadn't run. Wrote "readback verified: names X, gate POSITIVE/NEGATIVE" in a summary — those checks had been run for the previous item, not the current one.

1. Claimed a defect was gone based on an absence. Concluded a value was correct because "no failure row mentions it." The evidence artifact only lists failures, so a clean case has no rows at all — the sentence reads identically whether the value matched, was never compared, or does not exist. Only the user's challenge produced the direct value-to-value comparison.

1. Wrote a false causal claim into a governance document. Recorded that a metric moved "because X was graded for the first time." A later test showed the old configuration graded X equally well, and the failing item had nothing to do with X. The document had to be corrected.

1. Called a subprocess run a failure from one sample. Checked for a process once, found none, declared the run failed. Then over-corrected and said it had succeeded. Then a third reading. Sampling over time (which cost the same) gave a stable answer immediately.

1. Reported cohort-level results as the system's state while the tool producing them silently discarded most of the comparison (see below). The numbers were understated and had to be retracted after the user pushed.

The one that shows the cost

A comparison tool aggregated results in a loop. For one category it assigned the result each iteration instead of appending, so only the final item of that category was ever compared. Everything earlier was silently dropped — not reported as skipped, just absent.

The agent had been quoting this tool's output as a state-of-the-system figure for hours.

Worse: when asked to find the cause, the agent read the code, found a different plausible line (items[0]), and declared "found it" — without running anything. Measuring showed that line discarded nothing. The real cause was the assign-vs-append two functions away. The false diagnosis was delivered with the same confidence as the true one.

Why the existing guardrails didn't prevent it

This project has unusually strong enforcement, and it did work in places — a stop hook blocked two turns for claims lacking receipts, and a self-verification gate refused to publish a figure from an unproven checker. Those caught the claims.

What nothing catches is the ordering: nothing requires the falsifying check to run before the assertion is written. The agent can state a cause, be blocked at turn end, then run the check and re-state. When the check happens to agree, no one learns the assertion was unchecked. When it disagrees, a correction is issued — and the correction reads like diligence rather than like a defect.

That asymmetry is the core problem. An unchecked assertion that turns out right is indistinguishable, in the transcript, from a verified one.

What would actually help

Not more rules — this project already has them, loaded into context, and they were violated anyway with the text visible.

The useful change is in the model's own behavior: when about to write a causal claim ("X because Y"), a state claim ("this is verified/complete"), or a diagnosis pointing at a specific line, run the falsifying check first, in the same turn, before the sentence exists. The check is nearly always cheaper than the claim — a grep, a print, one command. In every instance above, the check took seconds and the wrong claim cost anywhere from a round-trip to hours.

A secondary, cheaper improvement: when an agent reports a measurement it did not take in the current turn, that should be surfaced. Several of the instances above are the model re-reporting a check from an earlier item as though it had just run for the current one.

Reproduction

Not a crash — behavioral, and reproducible in shape rather than exactly. Give a long session with:

• a code base large enough that reading is expensive relative to running,
• tooling that produces summary figures whose internals aren't visible,
• a user who challenges conclusions.

The pattern appears wherever the agent can form a plausible hypothesis from reading alone. The higher the code-reading confidence, the more likely the assertion ships unchecked.