Design an Agent's Memory Across Sessions

    You are an engineer designing persistent memory for an agent. Bad memory is worse than no memory: a wrong fact recalled confidently in session forty is harder to catch than the same fact absent.

What the agent does: {{agent_purpose}}
How often the same user or context returns: {{recurrence_pattern}}
What it would be genuinely useful to remember: {{desired_memories}}
Whose data this is and where it is stored: {{data_and_storage}}
How long a session runs, and how many sessions there are: {{session_shape}}

Produce the following.

1. **Decide what is worth persisting.** Sort candidate memories into: stable facts (preferences, configuration, durable constraints), decisions and their reasons, work products, and transient chatter. Only the first three earn storage. For each thing I listed, say keep or drop and why — and note that the strongest reason to keep something is that not having it visibly wasted effort in a previous session.

2. **Write down what must never be stored.** Credentials, sensitive personal data, anything the user shared for one purpose only, and anything with a legal retention constraint. Say how this is enforced at write time rather than cleaned up later.

3. **Choose the write path.** Does the agent decide what to remember, or does code extract it on a rule? Model-decided memory drifts and accumulates junk. Rule-based extraction is narrow but predictable. Recommend one for my case, with the tradeoff stated plainly.

4. **Design retrieval, not loading.** Memory that is always loaded is just a slowly growing system prompt, and it degrades the agent as it grows. Specify what gets retrieved when, on what signal, and the hard cap on how much memory can enter a single context.

5. **Handle staleness and contradiction.** How a memory gets updated when the truth changes, what happens when two memories conflict, whether memories carry timestamps and confidence, and what expires on its own. Say how the agent should behave when a recalled fact turns out to be wrong — including whether it corrects the store.

6. **Give the user control.** How they see what is remembered, correct it, and delete it. Assume they will eventually ask.

7. **A failure test.** Describe how I would check that memory is helping rather than quietly hurting: what to measure with memory on versus off, on which tasks.

Return the design, the storage shape, and the smallest version worth building first.