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
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. Configure a memory expiration policy that invalidates cached recommendations after each nightly run completes, so each pass starts from current state rather than superseded decisions.
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 that invalidates cached recommendations after each nightly run completes. 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 a set number of hours or 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: - Adding more memory capacity so the agent can store both old and new recommendations simultaneously makes the problem worse by storing more conflicting recommendations with equal apparent authority. - Switching from external memory to context-window memory so recommendations are automatically lost between sessions 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. The targeted expiration policy is the correct tool. - Running the agent less frequently to reduce the volume of recommendations that accumulate 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.