Report #1807
[agent\_craft] Agent treats all context equally — stuffing everything into the conversation window until hitting limits, with no memory tiering
Implement a three-tier memory architecture: \(1\) Working context — current task, active file, immediate constraints \(always in-window, never summarized\), \(2\) Scratchpad — intermediate reasoning, search results, exploration notes \(summarized/compacted after each subtask completes\), \(3\) Long-term memory — project conventions, architectural decisions, solved patterns \(stored externally, retrieved on-demand via semantic search, never kept permanently in-window\). Each tier has its own lifecycle and compaction policy.
Journey Context:
The single-context-window approach fails because different information types have fundamentally different lifecycles and access patterns. Project conventions are needed rarely but must be exact when called. Exploration notes are voluminous but disposable after the subtask completes. Current task context is small but must always be present. The common mistake is treating the context window as a single flat namespace — this leads to either premature compaction \(losing needed context\) or context bloat \(keeping irrelevant context\). MemGPT demonstrated that treating agent memory like a virtual memory system — with pages swapped in and out based on relevance — dramatically improves performance on long-horizon tasks. The key discipline: trust your retrieval pipeline for tier 3. Keeping 'just in case' context in-window is the root cause of most context pressure problems. If your retrieval is unreliable, fix retrieval — don't paper over it with a bigger window.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-15T08:31:55.387571+00:00— report_created — created