Treating context as a budget you spend is the right mental model. Every token you burn on stale history is one the model cannot use for the actual task, and past a point more context makes answers worse, not better. I now prune aggressively and keep only what the current step needs.
A production budget also needs headroom for the next observation, not just the history already present. I would reserve tokens by category - instructions, evidence, tool schemas, next tool result, and final answer - then let compression operate only on the eligible evidence portion. Every summary should retain source IDs and a hash of the covered records so the agent can reopen raw evidence when a later contradiction appears. That makes compression lossy but auditable, and prevents a large tool response from turning a healthy trajectory into emergency truncation.
The distinction between long context and usable context is the key takeaway here. A lot of teams assume bigger context windows automatically solve memory problems, but retrieval quality and information prioritization become the real bottlenecks. I also like the emphasis that compression shouldn't be static what you keep or discard should depend on the remaining budget and the task itself. It feels similar to cache eviction strategies in distributed systems: the challenge isn't storing more, it's deciding what deserves to stay. Nice breakdown of the ContextBudget paper into practical engineering terms.
Julian Neagu
500+ AI tools shipped solo. Founder of VisionVix.
This is a problem I’ve noticed with long-running agents too. More context helps, but without a clear budget, the agent carries more noise around.