An agent that monitors GitHub repositories accumulates every event it processes into an in-memory log and a persistent context store. After 30 days of operation, the agent's context store has grown to 2 GB and the agent's response latency has tripled because it loads the entire context store into its working memory on each invocation. No data has ever been removed from the store. What design decision was missing?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Keeping every event forever without pruning is like never throwing away mail — eventually the mailbox blocks the front door. Memory that grows without bounds eventually degrades everything that depends on it. The fix is a pruning strategy: summarize or archive old entries past a defined retention window, keeping the context store trim and fast.
Full explanation below image
Full Explanation
Unbounded memory growth is a common failure mode in long-running agentic systems. Every event stored without a removal policy causes the context store to grow indefinitely. When the agent loads its entire context on each invocation, loading time scales linearly with store size — hence the tripled latency after 30 days.
A memory pruning strategy defines rules for which entries to keep and which to remove or archive. Common approaches include: - Time-based pruning: remove entries older than N days - Relevance-based pruning: summarize or compress low-priority events into aggregate statistics, retaining only high-signal events in full - Size-based pruning: keep the most recent or most-accessed K entries and archive or delete the rest - Tiered storage: move old entries to a separate cold store that is not loaded on every invocation, only on explicit query
Option A (weekly restart) clears the in-memory log but does nothing about the persistent context store, which is identified as the root cause of the latency problem.
Option C (faster SSD) reduces I/O time per byte loaded, but if the store grows to 20 GB in 60 days, the SSD improvement will be quickly overwhelmed. This treats the symptom (slow loading) rather than the cause (unbounded growth).
Option D (larger instance type) also addresses the symptom rather than the design flaw. Scaling hardware to accommodate unbounded growth is expensive and only defers the problem.