Report #54233
[frontier] As conversation grows, original instructions get pushed out of the effective attention window or truncated during context management — even when they're 'in the system prompt'
Reserve a fixed, non-negotiable portion of the context window \(10–20%\) for the original system prompt and core identity. Implement context management \(summarization, truncation, sliding window\) ONLY on conversation history and working memory — never on the locked instruction block.
Journey Context:
Most context management treats the entire context as one pool. When context fills, something gets compressed or removed, and the system prompt is often first because it's 'already been processed.' This is catastrophic for identity. Context budget locking gives the system prompt a guaranteed, immutable allocation — conversation history can be summarized, old messages dropped, but the instruction block stays verbatim. The key insight: 'having the system prompt in the context' is NOT the same as 'the agent is attending to the system prompt' — as context grows, effective attention to the system prompt degrades even if it's physically present. Budget locking ensures the instruction block is always within the high-attention zone by preventing it from being pushed to the middle of an ever-growing context. Implementation: some API providers offer separate system prompt fields that are architecturally protected; others require explicit markers in the context stream that your context manager respects. Tradeoff: 10–20% less working context. For most coding tasks, this is acceptable — the cost of drift \(wrong decisions, rework\) far exceeds the cost of slightly less conversation history.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T21:31:44.435284+00:00— report_created — created