![Cover image for [Agent Design #2] Context engineering: treating the context window as a budget](/assets/images/posts/2ccd4368-394d-435f-b416-66619687b32d/context-engineering-1.jpg)
Seeing the spec “200K-token context window,” you might think you can load most codebases in full. But once you do, response quality drops sharply.
Multiple studies have confirmed that models can miss information in the middle of long contexts. Being able to include something and using it effectively are different problems.
This led to the concept of context engineering. In short, it is a design technique that treats the finite context window as a budget and keeps only the most useful information available at each moment.
This article explains why context is a budget, four strategies for conserving it, and design criteria for always-loaded files such as CLAUDE.md.
Let’s start with the key takeaways.
- Context is not better when it is larger; it is better when it is more relevant.
- There are four main strategies: selective loading, summarization (compaction), isolation, and externalization (memory).
- Keep always-loaded files (such as CLAUDE.md) short and limited to “things that are always true.”
- Tools and instructions also consume context. A tool that is registered but never used is a cost.
Why a budget? The cost structure of context
A context window incurs three costs at the same time.
First, performance cost. The more irrelevant material there is, the more the model’s attention is diluted. In particular, the “lost in the middle” phenomenon is well known: information in the middle of a long context is less likely to be retrieved.
Second, monetary cost. Input tokens are billed on every request. As the conversation grows, the same content is charged repeatedly.
Third, opportunity cost. The more space clutter occupies, the less room remains for the code and documentation you actually need.
The perspective shift in context engineering is this: ask not “How much can I include?” but “Does this token deserve to be here right now?”
Strategies 1 and 2: selective loading and summarization
Selective loading (retrieval) means fetching only what you need, when you need it. Instead of reading a 2,000-line file in full, read only the relevant functions; instead of loading an entire document, search for the relevant section.
A Skill’s progressive loading—showing only a one-line description normally and loading the body only at execution time—follows the same principle.
Summarization (compaction) compresses accumulated history. Dozens of tool-call records become a paragraph such as “modified these files and the tests passed.”
That is the compression coding agents perform automatically when conversations get long.
Remember that summarization is lossy. Details can disappear when folded together, so it is safer to move important decisions into a file before summarizing.
Strategies 3 and 4: isolation and externalization
Isolation means moving context-cluttering work into a separate session. If a subagent performs large-scale exploration, the file dump is consumed in that context, while only a few lines of conclusions return to the main session.
It is the most reliable way to protect the main session’s budget.
Externalization (memory) uses storage outside the context. When a session ends, its context disappears, but what you write to a file remains.
A typical pattern is recording work status in Markdown for the next session to continue. Accumulating project knowledge in CLAUDE.md and memory files is another example.
| Strategy | One-line summary | Representative example |
|---|---|---|
| Selective loading | Fetch only when needed | Partial reading, progressive Skill loading |
| Summarization | Fold up the history | Automatic compaction |
| Isolation | Delegate it to another session | Subagent |
| Externalization | Write it to a file | Memory files, status documents |
Design criteria for always-loaded files
Files such as CLAUDE.md are fixed costs deducted from every session’s budget upfront. Their criteria therefore need to be clear.
Include “things that are always true and must not be violated,” such as coding conventions, prohibitions, and build commands.
Exclude “things needed only occasionally.” Put detailed procedures for specific tasks in a Skill, and move records of past work into memory files.
The same logic applies to tool registration. The more MCP (Model Context Protocol) servers you attach, the more tool definitions accumulate as fixed costs.
Ten unused servers are themselves a source of performance degradation. They are worth cleaning up regularly.
Conclusion
Context engineering is ultimately relevance management. Rather than filling a larger window completely, keep only what relates to the current task on the model’s desk at each moment.
When the execution loop covered in the Harness Engineering installment is combined with this article’s budget management, the big picture of agent design comes together. The next article will cover a pipeline assembled from these ideas in practice.