An agent that remembers too much, too little, or the wrong things
20-minute memory review
Separate preferences, facts, procedures, and run history
Keep less, but keep it on purpose
An agent that saves everything slowly gets worse. Old preferences compete with new ones, a single request starts behaving like a standing rule, and nobody can say why a given fact still shapes the work. The fix is not a bigger memory or a smaller one. It is a habit: before anything is remembered, decide whether it still deserves to influence future work—and for how long.
The method is four quick decisions. Sort each item into a type, test it before you save it, give it an expiry, and record where it came from. The rest of this note works through each step, but the whole thing fits one sentence: keep what is stable, sourced, and still true, and let everything else stay in the run where it happened.
How to judge it: open your agent’s memory and read three entries at random. If you cannot tell what each one is for, where it came from, or when it should be revisited, the memory is collecting clutter, not context.
The trade-off is honest. A strict habit means you will occasionally re-explain something you could have saved. That is cheaper than the alternative—an agent acting with quiet confidence on a preference you abandoned months ago.
Sort every memory into four kinds
Different information ages differently, so it should not all live in one pile. Before saving, name what you are looking at:
- Preferences—stable choices about how you like work done, such as report format, tone, or the length of a summary.
- Facts—specific, sourced details about a person, product, or process: a client’s billing contact, a plan’s limits, the address a delivery goes to.
- Procedures—approved steps for a job the agent repeats, like how a weekly update gets assembled.
- Run history—what happened in a single session. Useful in the moment, but not a rule. “The client asked for X on Tuesday” is a record, not a preference.
Why it matters: the first three earn a place in durable memory; the fourth almost never should. Most bad memory comes from promoting run history into a permanent fact—one Tuesday’s exception quietly becomes every week’s default.
How to judge it: for any saved item, you should be able to say which of the four kinds it is in one word. If you cannot, it is probably run history wearing a preference’s clothes.
The trade-off: sorting adds a small step to every save. But a labeled memory is one you can later search, review, and expire by type—an unlabeled pile is one you eventually have to distrust wholesale.
Use case: what to remember from one client call
Devi runs a solo analytics consultancy, and her agent drafts each client’s monthly performance report. After a half-hour call with a client she calls Northwind, the agent asks a fair question: which parts of this should I remember?
The call produced five things it could save: use Northwind’s new brand blue on the charts, add a product-launch section this month, get the report out early because the launch lands on the 2nd, “make it punchier,” and a passing gripe that last month’s PDF ran too long (already fixed). Saving all five feels efficient. It is also how memory quietly rots.
Devi had three honest options: save everything from the call as standing preferences, save nothing and re-brief every month, or sort the five items one at a time. She sorted. The brand blue is stable, sourced, and scoped to Northwind, so it becomes a durable preference. The launch section and the rushed deadline are real but temporary, so they get review triggers tied to the launch, not permanent status. “Punchier” is too vague to act on, and the PDF-length gripe is already resolved—both stay in the run, not in memory.
The lesson is the whole method in miniature: the win was not remembering more of the call. It was deciding that exactly one item from it still deserved to influence next month’s report—and writing down where it came from and when to check it again.
One client call, sorted into keep and expire
Illustrative figures from Devi’s Northwind call—an example of sorting one conversation into keep, expire, and drop, not a customer result.
Requests and asides from Devi’s one call with Northwind.
Only the scoped brand-color rule was stable, sourced, and reusable.
The launch section and the rushed deadline got review triggers, not permanent status.
Run the SAVE test before you save
When something looks worth remembering, put it through four questions. Save it by default only if it clears them:
- Stable—is it likely to still be true next month?
- Actionable—will it actually change how future work is done?
- Verifiable—can you point to a source or an owner for it?
- Expected—would a reasonable person assume the agent should remember this?
Why it matters: each question blocks a common failure. Skip “stable” and you save a deadline that has already passed. Skip “verifiable” and you keep a fact no one can defend when it turns out wrong. Skip “expected” and the agent starts surfacing things people did not realize it was storing, which reads less like help and more like surveillance.
How to judge it: if an item fails two or more of the four, do not save it—note it in the run and move on. A borderline item that passes three is usually worth keeping with a short review date.
The trade-off cuts both ways. Set the bar too high and your agent forgets useful preferences, so you re-explain them; set it too low and old context drifts into today’s decisions. When unsure, prefer asking again over guessing from a stale memory—re-asking costs a sentence, while acting on the wrong memory can cost the work.
Give every memory an expiry
The most useful question you can attach to a saved item is, “When would this stop being true?” Some answers are “not until I change it”—a tone preference, for instance. Others have a date or an event baked in: a campaign ends, a launch ships, a customer’s temporary issue gets resolved. Write that trigger down next to the memory.
Why it matters: data you keep past its usefulness does not just sit there quietly—it keeps voting. A resolved complaint that never expires makes the agent treat a fixed problem as ongoing. Public guidance on holding data is blunt about this: keep information only as long as you need it, and review it on a schedule rather than by accident.
How to judge it: every durable memory should carry either “until changed” or a specific review trigger. An item with no expiry answer at all is the one most likely to age badly.
The trade-off: review triggers create a little maintenance—someone has to revisit them. Keep that load small by giving “until changed” to genuinely stable preferences and reserving dated reviews for the handful of items that really do go stale.
Write it so a person can audit it
A memory the agent can act on but you cannot inspect is a liability. Save each durable item in plain language with four parts, so anyone can read it and decide whether it still holds:
Remember: the useful fact or preference. Source: the person, record, or conversation it came from. Use when: the situation it should apply to. Review: the date or trigger to revisit it.
Why it matters: the “Source” and “Use when” lines are what stop a preference from over-reaching. Without a scope, a rule you set for one client’s reports silently applies to all of them. With one, the agent knows exactly where the memory is allowed to speak.
How to judge it: a good entry can be understood by someone who was not in the original conversation. If reading it raises the question “says who, and for what?”, it is missing its source or its scope.
The trade-off is a few extra words per saved item. In return you get a memory store you can revisit in six months—or hand to someone else—without having to trust it blind.
Good memory reduces repeated explanation without preserving accidental context forever. The goal is an agent that remembers on purpose—and forgets on schedule.
Try this next
- Open your agent’s saved memory from the dashboard and label each entry: preference, fact, procedure, or run history.
- Run the SAVE test on every durable entry—stable, actionable, verifiable, expected—and delete any that fails two.
- Add a source and a scope to each memory you keep, so it only speaks where it applies.
- Give every kept item an expiry—“until changed” or a review date—and set a reminder to revisit the dated ones.
Sources and further reading
These primary references support the article’s approach to keeping only what you need, holding it no longer than it stays useful, matching what you store to what people expect, and managing the risk of remembered data.
The principle that data held should be adequate, relevant, and limited to what is necessary—the case for selective memory over saving everything.
Information Commissioner’s Office (ICO)Storage limitationOfficial guidance to keep information only as long as you need it and review it on a schedule—the basis for giving every memory an expiry.
Google PAIRMental ModelsOn setting user expectations and signalling that a system adapts over time—support for the “Expected” test and for re-asking rather than silently storing.
NISTPrivacy FrameworkA structured way to identify what data you hold and manage its risk—useful for keeping remembered facts sourced and reviewable.
Ready to put one useful workflow to work?
Start with one clear job, a result you can review, and boundaries you understand.
See launch pricing