An agent must remember details across sessions. What do you configure?
Why C is the answer
A persistent datastore
Sessions end, so details that must last belong in a persistent datastore that the agent reads back.
In detail
- Sessions end, so memory has to live outside the model.
- A persistent datastore keeps memory beyond a single session.
- Let users see and delete what is stored about them.
Use case
An illustrative scenario, not a real incident.
A travel agent should remember a customer's seat preference next month. A persistent datastore holds it, and the agent reads it at the start of each session.
See it in different ways
sequenceDiagram
participant U as User
participant A as Agent
participant I as Vector index
participant T as Tool
U->>A: Question
alt General policy
A->>I: Search documents
I-->>A: Passages
else Live or per-record fact
A->>T: Call with a key
T-->>A: Current value
end
A-->>U: AnswerstateDiagram-v2 state "Session one" as s0 state "Save preference" as s1 state "Datastore" as s2 state "Session two" as s3 [*] --> s0 s0 --> s1: preference learned s1 --> s2 s2 --> s3: load at start s3 --> [*]
Key point: Memory across sessions needs a datastore.
Why the other options are wrong
- A. A larger chunk size, so past turns fit in one chunk
- Chunk size concerns retrieval, not memory.
- B. A new embedding model
- Embeddings have nothing to do with keeping details.
- D. A longer system prompt
- A system prompt is not memory for each user.