Architecture Cannot Be a Prompt: What Context Compaction Silently Drops

The failure nobody watches happen

A repository has a rule. Database access goes through the repository layer, never directly from a feature component. It is written in an architecture decision record, it is mentioned in the repository instruction file, and the coding agent clearly understood it at the start of the session.

Twenty tasks later, the session has grown long enough that the harness compacts the context. The current task survives compaction, because the task is what the summary is about. The architectural rule does not.

The agent then writes a feature component that calls the database directly. The code is correct. The tests pass. Nothing hallucinated. A constraint simply stopped existing, and no event was logged when it did.

What the COMPINT results show

This is now measured. Lost in Compaction, from a Penn State team, examines a category the authors call session constraints: instructions meant to bind behaviour for the remainder of a session rather than to describe the immediate task. Their example is an operational one, do not delete any emails until I confirm, and the shape generalizes cleanly.

Their evaluation suite, COMPINT, tests compactors across three long-context settings: multi-turn chat, agentic trajectories, and long-horizon research. The headline result is that current compactors retain, on average, 17% of injected session constraints. Most performed worse than running the same task with no compaction at all.

Retention varied sharply with the compactor used, the prompt, the context length, how the constraint was phrased, and where in the context it was injected. That variance is the important part. It means the loss is systematic rather than an artifact of one badly built summarizer, and it means you cannot reliably fix it by rewording the rule.

The authors also propose a remedy: a constraint-aware extractor running alongside the compactor, which lifts retention above 90%. Worth noting, because it establishes that the problem is tractable when something is explicitly responsible for the constraint.

Being precise about scope: this study does not examine coding agents losing architecture decision records. It establishes something more general and more useful. Persistent constraints encoded only in context are structurally fragile.

Architecture is made almost entirely of standing constraints

Now map that category onto a real codebase. Every one of these is a session constraint in the paper's sense, except that it is meant to hold for years rather than for a session:

• Services do not query the database directly.
• Components in the domain package cannot import from infrastructure.
• Authentication goes through the existing identity provider.
• No new persistence engine is introduced.
• Cross-domain communication uses events, not direct calls.
• Dependencies point inward.

None of these describe a task. All of them constrain how any task may be completed. They are exactly the class of instruction that COMPINT found compactors discard first, because a summarizer optimizing for task continuity has no signal telling it that a rule mentioned once, forty turns ago, still governs everything that follows.

Architectural decisions are persistent constraints over code generation. That is the whole category, and it is why drift is the default outcome rather than an unlucky one.

The chain that has to hold

Repository instruction files are useful. This is not an argument against them. It is an argument about what they can guarantee.

For an instruction file to change what an agent builds, every link in a chain has to hold: the agent loads the file, the relevant rule reaches active context, the rule survives whatever context management the harness performs, the model interprets it correctly, and the model then selects an implementation consistent with it.

That is a long probabilistic chain to hang an architecture on, and compaction attacks it in the middle where nothing is watching. Prompt persistence is not architectural persistence.

Three levels, and only the third is guaranteed

It helps to separate what each available mechanism actually promises.

Level one, instructions. Repository instruction files, rules files, system prompts. Cheap, immediately useful, excellent for discovery and for conveying things that resist formalization. Entirely probabilistic in effect, and vulnerable at exactly the point COMPINT measured.

Level two, persistent architectural context. Decisions live outside the conversation in a durable corpus, and the relevant ones are retrieved for the change being attempted. The agent no longer needs to carry every decision through the whole trajectory, because relevance is computed per change rather than per session. This is what the paper's constraint-aware extractor is doing in a general setting.

Level three, deterministic enforcement. For rules that can be expressed mechanically, the proposed action is evaluated rather than the agent reminded. An attempt to add a prohibited dependency returns a verdict, regardless of what the model currently remembers.

The distinction between level two and level three is the one worth holding onto. Recovering a constraint into context makes it more likely the model sees the rule. Enforcement reduces the dependence on whether the model obeys it.

Longer trajectories make this compound

Compaction is not an edge case. It is the mechanism that makes long-running agents possible at all, and its use grows with exactly the autonomy the industry is racing toward. As agents move from prompt-and-patch toward an objective producing hundreds of actions, architectural integrity stops being a generation-quality question and becomes a state-management question.

Compaction is also only one of the ways a standing decision comes loose. Trajectory length and agent handoffs do their own damage, which we covered separately in what happens to an architectural decision after ten agent turns. Compaction is the version that happens inside a single session, silently, as a side effect of a feature working correctly.

One forgotten rule produces one violation. A rule that is forgotten reliably, across many sessions and many agents, produces an architecture nobody decided on.

A hypothesis worth testing

The useful version of this argument is falsifiable, and COMPINT suggests the shape of the test.

Establish an architectural rule. Run a long coding trajectory with unrelated intermediate tasks. Allow normal context compaction to occur. Then issue a task where violating the original rule is the path of least resistance. Compare the agent alone, the agent with repository instructions, the agent with the decision retrieved into context, and the agent under deterministic enforcement.

Measure four things: functional completion, architectural compliance, violations attempted, and violations actually committed. The gap between the third and fourth is where enforcement earns its place, and if that gap turns out to be small, that is worth publishing too.

Architecture belongs firmly in the second category. The next phase of agentic software development will not be reached by making prompts larger. It will need decisions that persist outside the conversation, retrieval that surfaces them when they apply, and deterministic controls around the ones that matter most.