If you've run an OpenClaw agent through a long session — a multi-step research task, an autonomous build pipeline, anything that takes more than 30 minutes — you've probably seen it.
The agent starts forgetting. Instructions it acknowledged early in the session start getting ignored. Response quality drops. It begins repeating attempts it already made. At some point, it either resets abruptly or starts producing output that's visibly disconnected from the task.
Most operators blame the model. The model isn't the problem.
What's Actually Happening
Every OpenClaw session accumulates context: every message, every tool call, every result. The model processes this entire history on every turn. As the history grows, two things happen:
First, the model's effective attention dilutes. Relevant content from earlier in the session competes with everything that came after it. Instructions from turn 3 are less salient by turn 40, not because the model "forgot" them, but because they're weighted against a much larger context window.
Second, the model starts running out of space. Every model has a hard context limit. When you approach it, the model's quality degrades before you hit the wall — not after. The degradation is gradual, then sudden.
Default OpenClaw does nothing to address either of these. There's no mechanism that says "we're approaching a degradation threshold, compact the history now." There's no circuit that catches failed compaction attempts before they cascade. There's no verification that compaction actually reduced the context after it ran.
So the agent degrades. And operators think it's the model.
The Symptoms Are Distinctive If You Know What to Look For
- Instruction drift: The agent stops following rules it acknowledged early in the session. Not because it disagrees — because they've been diluted by context volume.
- Repetition loops: It attempts the same approach multiple times, apparently unaware it already tried. The record of the failed attempt is in the context, but it's no longer salient.
- Quality cliffs: Response quality drops noticeably at a specific session depth — not gradually, but in a step change. This is the model hitting a real threshold.
- Erratic tool use: Tool calls become inconsistent. The agent calls tools it already called, ignores tools it should call, or calls them with parameters that don't match the current task state.
- Abrupt resets: The session terminates or the agent loses coherent thread of what it was doing. This is often what context overflow looks like in practice — not an error message, just sudden incoherence.
What Compaction Is (And Why Default Setups Don't Have It)
Compaction is the process of summarizing and reducing session history to reclaim context space. The idea is straightforward: instead of keeping every message verbatim, replace older portions of the context with a condensed summary, then continue the session with a smaller footprint.
The execution is not straightforward.
Threshold management is harder than it looks. You need to know when to trigger compaction. Too early and you're compacting useful context. Too late and the model is already degraded when compaction fires — and degraded models produce worse summaries, which compounds the problem.
There isn't a single threshold. There are three: a warning threshold that signals compaction is approaching, a trigger threshold where it actually fires, and a block threshold where the context is too full to compact safely. These three values interact. Getting any one of them wrong creates either unnecessary interruptions (compacting too aggressively) or silent degradation (waiting too long).
The right values aren't intuitive. They're empirical — derived from measuring where quality actually degrades on the specific model you're running, not from the model's advertised context window.
Gate logic determines whether compaction should fire, not just whether it can. A single threshold check fires at the wrong time for roughly 30% of active sessions. Production compaction gates evaluate multiple conditions: token count, session age, the density of recent tool calls, the shape of the recent content. A burst of short tool calls looks different from a long narrative exchange, and they should trigger differently.
Circuit breakers prevent cascade failures. Compaction can fail. The summarization step can fail. The context reduction can be incomplete. If you retry immediately on failure — which naive implementations do — you can enter a loop that burns tokens, never reduces context, and leaves the session in a degraded state it can't recover from.
A circuit breaker counts consecutive failures and backs off. After a defined number of consecutive failures, it halts and surfaces the failure as a recoverable state rather than an unrecoverable loop.
Post-compaction cleanup verifies the result. After compaction runs, you need to verify it worked. Did the context actually shrink? Did the summary get written? Are there orphaned references to content that no longer exists in the context? Post-compaction cleanup is not optional — without it, you're trusting the compaction worked without checking.
Why This Is Hard to Get Right
The threshold problem alone has three sub-problems that interact. The gate logic has to account for session patterns that vary by use case. The circuit breaker parameters depend on failure rates that vary by model and task. The post-compaction verification has to handle partial failures.
None of this is rocket science — it's engineering work. But it's engineering work that most OpenClaw operators haven't done, because the default setup doesn't require them to think about it until something goes wrong.
Most operators discover this architecture gap after they've already watched an autonomous agent lose coherence on an important task. By then, the work is lost and the question is how to prevent it from happening again.
The answer is production-grade compaction architecture: validated thresholds, multi-condition gate logic, circuit breaking, and post-compaction verification. Not guesses — empirically validated constants derived from production deployments.
The Bottom Line
If your agent runs sessions longer than 30 minutes, handles multi-step autonomous tasks, or operates without supervision — you have an unaddressed context management problem. Whether you've seen the symptoms depends on how far you've pushed it.
The fix exists. It's not simple, but it's well-understood in production Claude Code deployments. The architecture is implementable in OpenClaw.
We published the production-validated solution — every constant validated in production Claude Code deployments — as the Agent Compaction Architecture skill on Claw Mart. If you want to understand the problem first without buying anything, the free Context Death Spiral Prevention primer covers the concepts without the production constants.
Top comments (0)