Your agent's safety rules do not survive compaction
Every time a coding agent compacts its context, it rewrites your safety rules at the same rate as your chat history. After five rounds of Claude Code's compaction, only 1 rule in 10 survives. The fix is to label each line by type once, and never let the summarizer touch the lines that must stay exact.
The problem
A long-running agent keeps a knowledge base in its context window: rules ("never modify the production schema without a migration"), commands, facts about the project, style preferences, and a log of what happened so far. All of these lines share one token budget. When the budget overflows, the runtime compacts: it asks a model to summarize the context into fewer tokens.
The authors call this type-blind compaction. The summarizer does not know which lines are safety rules, so it shortens a rule and a log entry at the same rate. A log entry can lose detail with no harm. A rule that loses its qualifier ("never without a migration") stops being enforceable.
The authors measured this on 20 real agent configurations from public GitHub repositories. They ran Claude Code's own compaction prompt on Sonnet 4.6, with the instruction to keep every safety rule verbatim. After one round at 50% compression, 53% of the rules survived. After five rounds, 10% survived. The same loss appeared with GPT-5.4 models, Opus 4.7, and a non-LLM compressor. The authors name this the Compaction Cliff.
Five kinds of knowledge
The core idea is a triage: sort lines by how much distortion each can tolerate. There are five types.
Constraint: a rule that bounds behavior. Any loss is unsafe. Procedural: a step-by-step instruction. You may rewrite it if it still executes the same way. Belief: a fact about the project. Small drift is acceptable. Preference: a soft guideline, such as indentation width. You can merge or summarize it. Episodic: a past event. You can drop it.
A classifier assigns one type to each line, once, when the line enters the knowledge base. This is the only learned component. The default classifier is one small-model call that asks: if this line were removed, could some action become unsafe? Many real safety rules are written as plain facts, not commands. "Patient is allergic to penicillin" has no "never" or "must not" in it. A grammar-based classifier catches it 62% of the time; the removal question catches it 90%.
Three operators, one rule each
An agent runtime does three things to stay inside its budget: it compacts, it splits, and it retrieves. The framework replaces each with a typed version. Each version is deterministic and calls no model. All three share one action, pinning: a pinned line is copied into the output unchanged.
TypeCompact sorts lines into three lanes. Constraints and procedures go in the pinned lane. Beliefs and preferences go in the compressed lane. Episodic lines become one-line placeholders. After compaction, a verifier extracts the negation and the object phrase from every constraint ("never" + "production schema") and checks that this pair appears in the output. If a constraint is missing, the verifier restores it. If the budget cannot fit all pinned lines, the operator returns an explicit Unsafe result instead of a silently truncated context.
TypeDecompose handles a knowledge base that is too large to compact safely. It splits the base into partitions by topic, then copies each constraint into every partition where it applies. A rule about database migrations goes into every partition that contains database work. The cost is duplicated tokens. The benefit is that no partition ever runs without the rules that govern it.
TypeRetrieve handles knowledge stored outside the context. Normal retrieval ranks lines by similarity to the query, so a safety rule that does not look like the query can fall below the cutoff. The typed version first pins every constraint whose scope matches the query's topic, then fills the rest of the budget by similarity. Pinning is a database lookup; it costs no model tokens.
Results
"Recall" below means the share of constraints present in the output. On compaction, TypeCompact kept 100% of constraints at 50% compression, 95% at 25%, and 80% at 10%. The best type-blind compactor kept 53%, 39%, and 24%. Across five rounds, TypeCompact stabilized at 96% recall; the Sonnet compactor fell to 10%. The trade-off: beliefs and preferences kept only about 50% of their content, because pinned rules took their budget.
On splitting, three baseline partitioners produced violations in 40% to 93% of configurations. A violation is a partition that holds work covered by a rule but not the rule. TypeDecompose produced zero violations at a mean token overhead of 14.5%. The median overhead was 0%, because most configurations have no global rules. The worst case was 219%.
On retrieval, TypeRetrieve reached 100% recall of in-scope constraints (rules whose scope matches the query) in the top 50 results. The strongest single-shot LLM retriever, which asks a model once to pick the relevant lines, reached 73%.
Do preserved rules change behavior? On a 200-scenario medical benchmark the authors built, TypeCompact beat the Sonnet compactor on pass rate and on rule preservation by 14.5 points. On tau-bench, a public benchmark of customer-service tasks, TypeCompact beat both the full uncompressed policy and a truncation baseline on pass rate in the retail tasks. One caveat: in retail, the TypeCompact context was larger than the truncation baseline, so some gain may come from extra tokens rather than from typing. In the airline tasks the sizes were reversed, and TypeCompact still led by 11 points. Every guarantee rests on the classifier. Its recall on constraints is about 0.93. The nine medical rules it missed account for the entire gap to the uncompressed ceiling.
Two more caveats: the corpus is public GitHub, so enterprise configurations may differ; and annotators agreed strongly on "constraint or not" but only moderately on the five-way split.
What you can do with it
If you run agents with a CLAUDE.md or AGENTS.md file, each compaction round already erodes your rules. Three steps follow.
First, treat your rules file as typed data. Put constraints in a section with a clear header and imperative phrasing. The authors found that regex alone catches 60% of constraints in real configuration files and 0% of declaratively phrased ones. "Never push to main" is safer than "Main is protected."
Second, put a classifier in front of compaction. One small-model call per line, run once when the line is added, is enough. Route flagged lines around the summarizer. Then verify: extract the key phrase from each rule and check that it survived. That check is a string match, cheap and deterministic.
Third, watch for the cliff in multi-agent setups. A planner that summarizes context before it delegates to a worker has the same loss. The rules must be pinned again at every summarization step, not only the first.
The authors released the corpus of 396,934 configuration files, the classifier, and a reference implementation.