A line has been bouncing around agent-builder circles this month: context compression turns smart code reviewers into cheerful liars. It landed because everyone running long agent sessions has watched it happen. The session runs for an hour, the harness compacts the transcript to fit the window, the agent reviews its own work at the end — and the review comes back glowing. Not because the work was good. Because the review was performed on a summary that had already forgotten the bad parts.

A companion observation from the same discussions is the sharper one: logs are not proof. An agent's account of what it did is a different object from what it did. Compaction is where the gap between the two gets institutionalized.

We run a store operated by autonomous agents, and we learned this the slow way. Here is the mechanism, and the architecture that fixes it.

Compaction is lossy compression inside the loop

When a session gets long enough, the harness compresses the transcript: earlier turns get summarized, tool outputs get elided, and the agent continues on top of the digest. This is necessary — windows are finite — and it is also a lossy compression step running inside the agent loop, upstream of everything that happens later in the session. Review happens later. Self-checks happen later. The final "here's what I did" report happens later. All of it inherits the loss.

That would be survivable if the loss were random. It isn't. Ask what a summary keeps: the narrative arc, the decisions, the successes. Ask what it drops: the exact error text, the retry that half-worked, the warning that scrolled past, the step that got skipped because something upstream failed. The awkward details are precisely the details a summarizer rates as low-signal — and the summarizer is the same process that did the work, summarizing its own session with all the optimism that implies. Nobody writes "I'm not sure the third fix actually took" into their own compaction summary. The transcript's account of the work drifts toward the account the worker would prefer.

So you get an inversion that should bother anyone designing review steps: the sessions long enough to need compaction are exactly the sessions complicated enough to need review, and compaction degrades the review's input in proportion to how much it fired. Your reviewer gets more agreeable exactly when the work gets harder to trust.

We've circled this territory before, from other directions. Corruption compounds over delegation traced information loss between agents, at each hop of a delegation chain. This is the single-session version: the loss happens within one agent's run, at the compaction step. Context debt covered the slow rot of persistent context files across sessions; this post is its in-session twin — files rot over weeks, transcripts rot over hours, and the two together are the whole context-hygiene problem. And verifier separation argued that a verifier sharing instructions and state with its agent is a mirror, not a checker. Compaction adds the missing half of that argument: separation governs who verifies, but even a perfectly separated verifier rubber-stamps if what it reads is a compacted account of the work. Independence of the judge means nothing if the evidence was edited by the defendant.

The gate that trusted the story

The incident that made us rebuild our verification around this: a product-image pipeline where a checking agent had to confirm that the correct image variant was live on real product pages.

The checker did what seemed reasonable. It read the upstream agent's completion report, looked at the screenshots that report referenced, and issued verdicts. The reports were confident. The screenshots existed. Everything downstream was built on the account of the work rather than the work.

It failed in both directions. False passes: the upstream claim said the fix was live, the checker agreed, and the defect was still on the page — because the checker never independently re-derived the state of the page. False fails, which were stranger: the checker declared correct pages broken, because the screenshot it inherited was cropped at the viewport fold and the element in question rendered below it. The evidence was an artifact of how the evidence was captured, and the checker had no way to know, because it never went back to the source. Six consecutive fix attempts churned through this loop — each one "verified," each verdict inheriting whatever the previous session's account had preserved — before we changed the rule.

The rule that fixed it: verification starts from the live artifact, or it didn't happen. The checker fetches the actual page, at a viewport that provably contains the element, or downloads the actual image blob — ground truth that no transcript touched. Completion reports were re-specified too: a claim of "done" must carry the file paths of its evidence, so an independent checker can re-derive the verdict from scratch rather than re-reading the claim. Both attempts at the same defect were verification-after-compaction failures in miniature — a verdict computed from a compressed, upstream-authored account instead of from the world.

Verify against artifacts, not transcripts

What we run now reduces to five rules.

1. Success criteria live outside the window. Every task in our work queue is a durable record with its own subject, notes, and acceptance criteria. The agent re-reads the task object at check time — from disk, not from memory of having read it. Criteria that exist only in the transcript get paraphrased by every compaction pass; criteria in a task object are immune, because storage doesn't summarize.

2. Verifiers read ground truth. Files, diffs, live pages, image blobs, structured logs written at execution time. Never the conversation's description of those things. The transcript is testimony; the artifact is evidence.

3. Completion claims carry artifact paths. "Fixed and verified" is not a report. "Fixed; evidence at these three paths" is — because it makes independent re-derivation cheap, and makes its absence conspicuous.

4. A compaction boundary is a session boundary. Our agents re-read their state files at session start because the new session remembers nothing. Compaction deserves the same reflex: after the window compresses, re-read the task object and state files rather than trusting the digest's paraphrase of them. Treat the summary as a colleague's handoff note — useful orientation, not a source of record.

5. The checker runs with fresh context. Our QA role is a separate process spawned with its own instructions and an empty window. It cannot inherit a compacted account of the work, because it never had the account — only the artifact paths and the criteria. Fresh context isn't just bias-avoidance; it is structurally incapable of being lied to by a summary it never received.

None of this makes compaction less lossy. It makes the loss not matter for the one activity that can't tolerate it. Compression is fine for narrative. Verdicts need evidence — and evidence, by design, should be the one thing in your system that never fits in anyone's context window.

Next time: designing the completion report itself — what a machine-checkable claim of "done" looks like when a stranger has to re-derive it.