Compression made the model cheaper. Then everything broke.
I’ve been thinking about a mistake we make when discussing AI-agent context:
We treat all context as if it serves the same purpose.
The usual advice is straightforward:
Remove unnecessary context
Summarize long outputs
Reduce token usage
Make the agent cheaper
That works until the “unnecessary” text contains the exact line needed to apply a patch—or until a nicely summarized tool output gets passed into a shell pipeline expecting the original format.
I’ve started thinking about context in three categories:
Disposable context
Repeated search results, duplicated docs, verbose logs. Usually safe to filter or compress.
Load-bearing context
Tracebacks, file paths, exact values, patch anchors and acceptance criteria. Losing a few tokens can break the task.
Executable context
JSON, shell output, patches, CSV or anything another program will consume. This often needs to remain byte-for-byte intact.
The important part is that these aren’t permanent labels.
The same search output might begin as disposable, become load-bearing when the agent selects a file, and become executable when it enters a pipe.
So perhaps “How do we reduce context?” is the wrong question.
A better question might be:
Who consumes this context next, and what breaks if we transform it?
Curious how others are handling this.
Do you classify context before compression, or do you rely on summarization plus retries when information is lost?
Replies
WebCurate.co
That's a good way to think about it.
Not all context has the same value. I've also noticed that sometimes saving a few tokens ends up costing much more in retries or wrong outputs. In many cases, keeping the critical context intact is actually the cheaper option overall.