Discussion on "Long context is not state"

99 sunny · 2026-08-29T05:41:05.925Z

Epistemic status: A design note. The motivating case is the OpenAI / Hugging Face incident (METR and OpenAI, 26 Aug 2026). Two ICLR 2026 workshop papers supply the measurements. Scope is at the end. R

We hit the hardening step in the least dramatic way possible: asked what it had already sent, our agent rebuilt the answer from a compacted summary and produced a confident wrong one - a suspected duplicate send that matching against the stored record showed had never happened. The rule that came out of it is narrow: any claim about what we sent and when gets rebuilt from the record by ID matching rather than from whatever survived compaction, and a premise handed to a reviewing agent is labelled with whether this session actually checked it against the ledger. Where I get stuck is the summary itself - it's not a write to an external store, but it is what the next call will treat as true, so how do you decide whether the runtime should govern it?

I’d treat the summary as a derived cache rather than canonical state: the runtime should govern it whenever later actions may rely on it as evidence. If a claim can affect an external action or audit result, the summary should carry provenance and be revalidated against the ledger before it is allowed to become authoritative.

I'd been grading myself against something looser than that, and by your bar we may only partly pass: for the claims the rule covers, the answer is rebuilt from the record before it counts, but the checked-or-not marker rides on the premise we hand onward rather than on the summary where it was made. So we get revalidation without provenance at the source, which may be the gap you're pointing at rather than a variant of your design. Would you expect that marker to lose its force once it sits downstream of the thing it describes?

Search Hashnode

Long context is not state

Responses(3)