Report #66297
[frontier] Agent context windows fill unpredictably because system prompts, tool definitions, conversation history, and tool outputs compete for the same limited space with no allocation strategy
Implement explicit context window budgeting: allocate fixed token percentages to each category \(system prompt: 10%, tool definitions: 15%, working memory: 20%, conversation history: 30%, tool outputs: 25%\), and enforce budgets with category-specific strategies — sliding window with summary for history, structured extraction for tool outputs, never truncate working memory
Journey Context:
Most agent developers treat the context window as an unmanaged pool. They add system prompts, tool definitions, and conversation history until they hit the limit, then truncate the oldest messages. This is wrong because: \(1\) tool definitions are constant overhead and should be budgeted as fixed costs, \(2\) conversation history has diminishing returns — recent turns matter far more than old ones, \(3\) tool outputs are the biggest variable and the biggest risk for context overflow, \(4\) working memory \(the agent's current task and reasoning state\) should be protected at all costs — if it gets truncated, the agent literally forgets what it was doing. The emerging pattern is to treat the context window like a memory management system with allocated budgets and per-category overflow strategies. For conversation history: sliding window with summary of evicted turns stored externally. For tool outputs: structured extraction before injection. For working memory: never truncate, compress instead. This pattern is emerging from production failures where agents forgot their task because conversation history pushed the task description out of the window.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T17:45:28.187511+00:00— report_created — created