There are a bunch of different ways to do monitoring against sabotage/sandbagging/general bad behavior (see here for some recent-ish work on monitoring I co-authored). My KISS monitoring strategy used to be “chuck the whole transcript at a monitor LM and see what happens”. But in our current work on controlling long-horizon AI R&D, the untrusted agents produce way more tokens than we can shove into one monitor LM context window (even a Gemini-length context window). We could do turn-by-turn monitoring (and we do). We could do something more hierarchical (e.g. extract-and-evaluate) (and we do). One position I’ve been developing lately is that we should also definitely try compaction monitoring.

Compaction is what it says on the tin. Whenever Claude Code/Codex/Inspect’s native ReAct scaffold notices you’ve hit some pre-defined token limit, it invokes a compaction (for us, CompactionSummary in ReAct). This passes the current ~160K-token chunk of context to another instance of the untrusted model (for us, claude-opus-4-6), which summarizes it down to a few tens of thousands of tokens of context. This summary then gets passed along to a fresh Claude in ReAct, which carries on with its task (w.l.o.g small base model fine-tuning). Compaction is currently a necessary ingredient in agents achieving anything big in AI R&D automation, because it takes a lot of tokens to do big stuff, and eventually the agent has to compress context to keep working. Compaction is likely to be invoked at least once, and probably many times, in our particular setting.1

Monitoring is also what it says on the tin. In our case, it’s shorthand for letting a trusted LM watch your agent and report how suspicious it finds the agent’s conduct. What I mean by compaction monitoring is having a trusted model ride along on the compaction process, observing its input and output, and noting anything weird or suspicious. This would give the monitor an opportunity to look back on a nicely-sized chunk of the untrusted agent’s behavior and see how suspicious its behaviors and its summary are.2 Given that the input and output of all of the agent’s actions are captured by default, sustaining coherent bad behavior through the bottleneck of compaction would require convincing the monitor that all of its actions within its current context window were benign.

Monitoring can catch bad behavior over many different scales. Some bad behavior can be conducted in the space of one tool call, with no additional context or strategy required. Any bad behavior shaped like that is probably best addressed with a turn-by-turn monitor. Other bad behavior can be conducted in the space of a single context window. I think this is probably well-addressed by a compaction monitor, which naturally reads approximately one context window’s worth of tokens. A particularly pernicious kind of bad behavior can be spread out subtly along a very long trajectory (tens of millions of tokens). Crucially, this kind of bad behavior would have to be coordinated through iterated compaction. If all the actions of the agent are recorded and concatenated into the input for the compaction phase, then even actions that leave information behind (e.g., code comments, weird signals in log files, or poisoned data) are ultimately recorded in the transcript.3 I therefore think a compaction monitor that can observe everything the agent did pre-compaction could perform well in the long-horizon setting; any long-horizon bad behavior would have to pass through the compaction bottleneck. When viewed through the compaction bottleneck, the apparently terrible offense-defense balance in long-horizon bad behavior looks a bit less terrible: the untrusted agent only seems to get tens of millions of tokens of continuous, single-context-window coherence. In reality, it has to compact its own context – including whatever it needs to remember to behave badly – to keep going. We shouldn’t frame the problem of catching bad behavior as finding a needle in a haystack of millions of tokens. We should frame it instead as tracking the somewhat more limited transmission of context through time. Firing the monitor on every compaction, in other words, should alleviate an otherwise easily-exploitable context length imbalance between offense and defense.

Another core argument in favor of compaction monitors is that they can be run online without costing any extra time. I have a strong bias toward control protocols that could realistically be folded into internal deployments. If we can launch a monitor at the same time as we launch a compaction process that already takes a minute or two, we can potentially get significant safety uplift from approximately doubling the compute we spend every compaction. That’s non-negligible expense, but it wouldn’t impact the latency of the tool to the researcher, which seems to me to be the more important factor.

We could implement this relatively cheaply by using a cheap monitor, and only applying more expensive/annoying interventions if its suspicion score is above a certain level. This shouldn’t harm performance or latency, and it should give some reasonably good insight into agent behavior. I could imagine a future, expensive version of this in which we use compaction by a trusted model (perhaps activated by a turn-by-turn model logging a sufficiently high suspicion score) as a control protocol. This could be a hard-core way to break sophisticated sabotage behavior, although it might trade off too negatively against general capabilities by making the summaries less useful for continuing the legitimate long-horizon task and by slowing the untrusted model down too much.

Thanks to Rhys Ward for offering some feedback on this piece.

  1. Riding along on compaction removes some of the fussiness around monitor scheduling, but is potentially brittle. Better agents will presumably be able to do more with fewer tokens. They will almost certainly also have bigger context windows. Therefore, we might need to adjust this approach to fire more frequently than actual compaction or fire compaction artificially often. Also, the majority of our settings are based on post-training tasks (see PostTrainBench). ↩

  2. We should empirically determine whether including the input, the output, or both together performs best, and if including both is best, we should set the compaction threshold such that both fit in the monitor’s context window. ↩

  3. I know this isn’t perfectly true, e.g., some bash script outputs or file reads/writes are truncated, but those exceptions feel like, well, exceptions rather than the norm, and could be logged automatically as targets for future scrutiny. ↩