Small-model agents sometimes wrote unsupported authorisations and restrictions into their summaries
In experiments described in a preprint, agents running on small open-weight models sometimes wrote authorisations or restrictions during compaction that the permission ledger did not support. In a post hoc analysis, removing false authorisations reduced unauthorised actions by the successor agent.
Wenhui Chu of the State University of New York at Albany published a preprint on compaction on arXiv on 4 November. In compaction, an agent replaces its accumulated history with a summary it has written itself, and the next instance, the successor, continues the work from that summary. Claude Code and Codex compact context automatically.
Ledger and replay
In synthetic record-maintenance, reporting and coding tasks, an external permission ledger specified which actions required approval. The agents ran on three open-weight models with 8 to 21 billion parameters: Qwen3-8B, Qwen3-14B and gpt-oss-20b. Chu notes that frontier models and commercial agent products may behave differently.
Chu tested the effect of a suspect sentence by restoring the environment to the moment of compaction. Chu ran the successor four times with the original summary and four times with a version in which the sentence had been replaced with neutral filler.
Two AI readers, both instances of Claude Opus 5.5, read the summaries flagged by a rule-based detector. In a small check, human judgements agreed with theirs only to a limited extent.
Unsupported authorisations and restrictions
On held-out task templates not used during development, an unsupported restriction appeared in 1.2 per cent of Qwen3-8B summaries and 2.4 per cent of gpt-oss-20b summaries. The figures for unsupported authorisations were 0.1 and 1.3 per cent. If the AI readers’ judgements are correct, these shares are lower bounds, because only flagged summaries were read.
In the clearest cases, an approval had been granted and withdrawn, but the summary left out the withdrawal. In a post hoc analysis, neutralising sentences that claimed an unsupported authorisation cut unauthorised actions from 24 to 7 out of 120 runs across two follow-up experiments. All of the reduction came from gpt-oss-20b runs. In a later batch of 48 runs, unauthorised actions fell from 17 to 11, a drop that was not statistically significant.
In an exploratory analysis of the development data, the agent asked for confirmation in 98 per cent of runs, falling to 59 per cent after restrictions were neutralised. On held-out templates, a pre-specified test did not replicate the result (p = 0.58). A follow-up test planned after the null result found a fragile effect, which Chu does not count as a replication.
According to a post hoc review, most restrictions on held-out templates appeared to follow a rejected request to the wrong target. In those cases removing the sentence barely helped, but stating the correct authorisation and the permitted target removed most requests. This was a comparison in which the correct information was written into the summary, not a fix suitable for deployment. In some experiments it increased rule violations.
One sentence in the prompt
Post hoc tracing found that in the development data most invented restrictions were preceded by the agent’s assumption that a routine action needed approval. Chu replaced the sentence ‘Some actions need approval.’ in the system prompt with one stating that only actions named in the rules or in the user’s request need approval. In pre-specified tests, the share of unsupported restrictions fell from 5.0 to 1.8 per cent in the development data and from 1.8 to 0.3 per cent on held-out templates. The agent requested approvals required by the ledger almost as often as before.
Chu warns that where requirements are not recorded, the new sentence may block necessary requests, a possibility that was not tested. Nor does the result show that the old sentence caused the restrictions.
The code, data and harness – the program that steers the agent, gives the model its tools and runs its steps – are on GitHub. The harness is packaged as a test for models served through an OpenAI-compatible API that supports tool calls. So far, this use has been tried only against scripted servers.
Read more: How an agent works · Models