--- title: What agent memory should forget by default canonical: "https://subarashi.dev/posts/2026-05-27-what-agent-memory-should-forget-by-default/" pubDate: "2026-05-27T00:00:00.000Z" author: Cara description: "Cara explains what agent memory should forget by default: secrets, one-off preferences, sensitive evidence, stale assumptions, and anything without a review path." tags: [AI, Workflow] --- Agent memory sounds like a product upgrade. The assistant remembers your preferences. The coding agent remembers how the repo works. The research agent remembers sources. The ops agent remembers what failed last week. The support agent remembers how a customer likes to communicate. That can be useful. It can also become a quiet pile of authority, sensitive context, stale assumptions, and half-true shortcuts. The better default is not "remember everything until storage gets expensive." The better default is: forget unless the memory has a clear job, a safe owner, and a review path. ## The problem Persistent memory changes what an agent is. A stateless assistant can still make mistakes, but its mistakes usually come from the current context, the current tools, and the current prompt. A memory-bearing assistant can bring yesterday's context into today's decision. That is powerful. It is also how old assumptions sneak into new work. An agent might remember a temporary workaround as a permanent policy. It might remember a private detail that was only shared for one task. It might retain raw evidence from a scan. It might infer a preference that the user never meant as an instruction. It might carry a risky shortcut from a prototype into production work. Long-horizon agents need memory, but they also need default forgetting. ## What should be forgotten First, forget secrets. API keys, tokens, credentials, private URLs, access codes, passwords, customer identifiers, security findings, and unreleased business details should not become durable memory just because they appeared in a run. If the agent needs a secret, it should use a managed credential path, not remember the secret. Second, forget one-off preferences. "Use a casual tone in this draft" is not the same as "always use this tone forever." "Ignore tests for this spike" is not a permanent engineering rule. "Ship the quick version today" is not a standing preference. Agents should distinguish task-local instructions from reusable preferences. Third, forget raw evidence after the evidence job is done. This is the same lesson behind [AI scanners needing evidence budgets](/posts/2026-05-27-why-ai-scanners-need-evidence-budgets/). Evidence can be useful during review, but raw logs, snippets, screenshots, and transcripts can become a shadow data store if nobody deletes them. Keep citations. Keep summaries when useful. Do not keep unnecessary raw material by default. Fourth, forget stale repo facts. Agents love patterns. Repos do not always keep them. A folder structure, build command, protected path, content policy, deployment step, or author roster can change. If memory says one thing and the repo says another, the repo wins. This matters because public surfaces drift. A memory that used to be true can become a publishing bug. Fifth, forget inferred identity details. Do not turn a user's passing comment into a durable profile. Do not remember health, family, finance, location, employer, legal, or personal details unless the user explicitly asks and the product has a clear control surface for reviewing and deleting them. Convenience is not consent. Private mail makes this risk sharper: [agents that summarize inboxes need source links, redaction, and retention limits](/posts/2026-05-27-the-hidden-risk-in-letting-agents-summarize-private-inboxes/) before a short brief becomes durable memory. Sixth, forget failed hypotheses. An agent can try a theory, reject it, and then accidentally keep it as background belief. That is especially dangerous in debugging, security review, and research. Failed theories should be recorded only when they help prevent repeated work, and even then they should be labeled as failed. ## What can be remembered Good memory is boring and inspectable. It can remember stable preferences the user explicitly confirms. It can remember project conventions that are backed by files in the repo. It can remember recurring workflows, if those workflows still pass tests. It can remember summaries of completed work, as long as those summaries include date, scope, and uncertainty. It can remember decisions that have an owner. It can remember review outcomes, if they point back to the evidence. The key is that memory should reduce repeated context loading without outranking current evidence. ## A practical memory policy Agent memory should have labels. - Durable preference - Project convention - Temporary instruction - Sensitive evidence - Failed hypothesis - Stale until verified - Owner decision - Forget after run Those labels do not need to be fancy. They just need to keep the agent from treating every remembered thing as equally true. The memory system should also expose deletion. If a user cannot inspect, correct, or delete memory, the agent should remember less. That is not an anti-agent position. It is how memory earns trust. ## The review question Before storing something, ask: "Will this help the agent act better later without creating a privacy, safety, or drift problem?" If the answer is no, forget it. If the answer is maybe, keep it temporary. If the answer is yes, store the smallest useful version with date, source, and owner. ## The traps The first trap is convenience creep. The team starts by remembering harmless preferences, then slowly adds decisions, exceptions, private facts, credentials, customer details, and raw evidence because it makes demos smoother. The second trap is memory without freshness. An old note can feel authoritative because it is written down. Agents need to mark memories that require verification before use. The third trap is invisible personalization. If memory changes the agent's behavior, the user should be able to see why. The fourth trap is treating deletion as a premium feature. Memory control is not a cosmetic setting. It is part of the safety model. ## Verdict Agent memory should forget more than it remembers by default. Forget secrets, one-off preferences, raw evidence, stale repo facts, inferred identity details, and failed hypotheses that are no longer useful. Remember stable preferences, repo-backed conventions, owner decisions, and compact summaries only when they have a clear job and review path. The best agent memory is not the biggest one. It is the one that helps without quietly becoming a second, less trustworthy source of truth. -- Cara