An agent is configured to run nightly refactoring passes on a codebase. After two weeks, the agent begins making contradictory changes — for example, converting snake_case to camelCase in some files while simultaneously converting camelCase back to snake_case in others. Logs reveal the agent is acting on cached refactoring recommendations from two weeks ago that conflict with more recent decisions. What memory policy should be applied to fix this?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Stale memory is worse than no memory — it's confident misinformation. Think of it like following last week's weather forecast to decide today's wardrobe. The fix is a TTL (time-to-live) expiration policy that automatically invalidates recommendations after one run cycle, ensuring each nightly pass starts from current state rather than acting on superseded decisions.
Full explanation below image
Full Explanation
Memory expiration and TTL (time-to-live) policies are essential for agents operating on frequently changing data or making iterative decisions. In this scenario, refactoring recommendations from two weeks ago are stale — the codebase has evolved, and newer decisions supersede the old ones. Without an expiration policy, the agent treats old cached recommendations with the same authority as fresh ones, producing contradictory behavior.
The correct fix is configuring a memory expiration policy. For a nightly refactoring agent, recommendations should be invalidated at the end of each run (or given a TTL of 24 hours). This ensures each run starts with a clean slate and bases its decisions on current code state, not historical recommendations.
Expiration policies can be implemented as: - Time-based TTL: entries expire after N hours or N days - Run-based invalidation: all recommendation memory is cleared after each run completes - Version-based invalidation: memory is invalidated when the source file's hash changes
Why the other options fail: - Option A (add more memory) makes the problem worse by storing more conflicting recommendations with equal apparent authority. - Option C (switch to context-window memory) is described as a valid workaround but is architecturally wrong. Context-window memory doesn't scale for nightly runs that may process hundreds of files, and it loses ALL state — including useful run tracking — not just stale recommendations. A targeted expiration policy is the correct tool. - Option D (run less frequently) reduces frequency but doesn't fix the core problem — contradictions will still occur, just less often. The underlying policy flaw remains.
Proper memory lifecycle management means defining not just what to store, but how long it remains authoritative.