A developer support agent should remember user preferences (e.g., preferred coding language, test framework) across conversations. Which approach correctly implements this long-term memory?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A good barista remembers your order without you repeating it every time. Long-term memory for agents works the same way: store what you know about each user in a real database, then greet them with their preferences already loaded.
Full explanation below image
Full Explanation
Long-term memory for agents requires external, durable storage keyed to a persistent identifier (e.g., user ID). At conversation start, the agent retrieves the relevant user's stored preferences and injects them into context.
Architecture: 1. External database (PostgreSQL, DynamoDB, Firebase, etc.) with a table keyed by user ID. 2. On conversation start, query by user ID to retrieve preferences. 3. Inject retrieved preferences into the system prompt or first user message. 4. On conversation end (or preference update), write updated preferences back to the database.
Why B is correct: An external database provides durable, scalable, per-user long-term memory that survives session boundaries and can serve multiple concurrent users.
Why A is wrong: Updating the system prompt file after each conversation is not scalable (one prompt file cannot serve multiple users), is error-prone (concurrent users would overwrite each other's preferences), and requires file I/O that introduces race conditions.
Why C is wrong: Asking users to re-state preferences every conversation is a poor experience — exactly the problem long-term memory solves.
Why D is wrong: Fine-tuning model weights to encode per-user preferences is impractical: it requires a separate fine-tuned model per user, retraining whenever preferences change, and does not scale beyond a handful of users.