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?

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, which explains the tripled latency after 30 days.

The missing design decision is a memory pruning strategy that defines rules for which entries to keep and which to remove or archive. Common approaches include: - Time-based pruning: remove entries older than a defined retention window - 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 fixed number of 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

The weekly restart choice clears the in-memory log but does nothing about the persistent context store, which is the root cause of the latency problem.

The faster SSD choice 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.

The larger instance type choice also addresses the symptom rather than the design flaw. Scaling hardware to accommodate unbounded growth is expensive and only defers the problem.