An agentic system uses a long-term memory store to cache API contracts for internal services it frequently calls. After a major service update, the agent continues calling old API endpoints stored in its memory, causing 404 errors on 100% of calls to that service. The team has confirmed the root cause is stale cached API contracts. Which memory refinement strategy BEST prevents this class of failure while retaining the performance benefits of caching?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A cache that doesn't know when its source changed is a museum masquerading as a library. Event-driven invalidation is the subscription that notifies the library the moment a new edition ships — the stale entry is cleared and the next request fetches fresh. You keep speed without the blindness to updates.
Full explanation below image
Full Explanation
The fundamental problem with time-based expiration (option C) is that it is a guess about when data might go stale. A service could be deployed twice in one day (leaving the cache stale for hours between the first deployment and the next TTL expiry) or not at all for months (causing unnecessary refreshes). Time-based approaches are inherently disconnected from the actual source change lifecycle.
Event-driven invalidation solves this by making the cache a subscriber to the source's lifecycle:
1. Deployment webhook: When the internal service is deployed via CI/CD, a webhook fires with the service identifier 2. Invalidation handler: The handler receives the event and deletes the specific cache entry for that service's API contract 3. Cache miss → fresh fetch: On the agent's next call to that service, it finds no cached contract (miss), fetches the current API documentation, stores it back with a TTL as a secondary expiration mechanism 4. Cost of miss: One fresh fetch per deployment per service — negligible cost
Option A (disable caching) eliminates performance benefits for no reason — the agent would make API documentation requests on every single run, adding latency and network load. Option C (weekly clearing) creates a 7-day window during which a newly deployed service's contract is stale. Option D (storing multiple versions) introduces version selection ambiguity: the 'most recently stored' might be the old version if the cache write for the new version fails; it also complicates rollback scenarios where the older version temporarily becomes current again. The exam-level principle is that cache invalidation should be source-synchronized (triggered by source changes) not time-synchronized (triggered by elapsed time).