CORE GUIDE
Finite context budget
Context engineering is allocation: decide which instructions, evidence, memory and tool state deserve the next token of budget.
Mental model
Every context item spends scarce capacity. The correct question is not 'Can it fit?' but 'Is it worth occupying the model's working set for this decision?'
Why it matters
Large windows can hide poor selection policies. When everything is retained, stale facts, repeated instructions and verbose tool traces increase cost and can weaken the signal of critical evidence. A budget forces the system to express priorities.
01
Budget by information role
Divide context into categories such as invariant instructions, current task state, authoritative evidence, working memory and transient traces. Give each category a policy for retention, refresh and compression instead of applying one generic truncation rule.
02
Example: preserving the release veto
A release agent has 40 pages of test logs plus one unresolved safety veto. Blind summarization drops the veto because it appears once. A budget policy classifies vetoes as non-compressible constraints while reducing repetitive logs.
Common failure modes
- Using first-in/first-out truncation for all content.
- Spending most of the window on verbose tool output.
- Compressing critical constraints with the same policy as background detail.
Engineering heuristics
- Reserve protected budget for invariants and unresolved blockers.
- Track token cost by source category.
- Compress repeated observations into state, not prose history.
Takeaways
- 01A context window is capacity; a context budget is policy.
- 02The budget should reflect decision importance, not arrival order.
- 03Protected information classes prevent silent loss of critical evidence.
Related concepts from the Knowledge Graph
These relationships come from the canonical graph, not a separate Guide taxonomy.