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
Good baristas remember 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
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 the user-keyed external database approach is correct: An external database provides durable, scalable, per-user long-term memory that survives session boundaries and can serve multiple concurrent users.
Why storing preferences in the agent's system prompt and updating the prompt file after each conversation 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 asking users to state their preferences at the beginning of every conversation is wrong: Asking users to re-state preferences every conversation is a poor experience — exactly the problem long-term memory solves.
Why using model fine-tuning to bake in each user's preferences 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.