What an Agent Should Remember, and What It Should Forget

Ask what a later session would do differently

A useful memory changes a future decision. Consider an agent finishing a database migration: the full terminal transcript is rarely worth recalling, but the reason the team rejected an exclusive table lock may matter during the next migration. Before saving anything, name the later task and the mistake this memory would prevent.

Anthropic’s context-engineering guidance recommends selecting a small set of high-signal context and describes persistent notes outside the context window. That supports selective capture; it does not establish that every observation deserves permanent storage.

Use three admission questions: will this remain useful beyond the current task, is the evidence strong enough to reuse, and is this the right audience? If the answer is unclear, leave it in the task record. A successful command proves that command worked under particular conditions. It does not prove the command belongs in every future session.

Keep preferences, decision rationale and tested procedures

These categories earn space because they preserve information a fresh checkout or API request cannot necessarily reconstruct:

• Explicit preferences: the caller prefers review summaries with the failing command first. Record who expressed the preference and the kind of work it applies to. One request for a short answer during an incident should not become a permanent preference for minimal explanations.
• Confirmed decisions: the billing team chose additive schema changes because older workers remain active during rollout. Preserve the rationale and a reference to the accepted decision. Keep proposed alternatives distinct from the choice the team actually approved.
• Tested procedures: integration tests require a disposable database seeded with synthetic fixtures. A reusable procedure should identify prerequisites, validation and the conditions under which it needs review.

Claude Code’s memory documentation similarly distinguishes preferences, feedback, project facts and references, while directing reusable multi-step procedures toward skills. Apply that distinction in your own design: a memory can say why a procedure matters and point to its maintained implementation. Avoid copying the entire runbook into several memory files. A personal formatting preference belongs with its owner; an accepted migration constraint may belong with the team. The boundary is explored in personal and team memory.

Exclude values that should be fetched or never retained

Keep passwords, bearer tokens, private keys, signed download URLs and recovery codes out of durable memory. OWASP’s secrets-management guidance treats credentials as managed objects with access controls, rotation and revocation. Remembering a credential in prose creates another copy outside that lifecycle. Save a permitted reference to the approved access mechanism when useful, never the credential itself.

Discard transient observations such as a current pod name, a passing CI run, today’s account balance or a temporary incident workaround. When a later task needs that value, fetch it again. For an unresolved incident, a scoped handoff can preserve the investigation checkpoint with an explicit validity boundary; that is different from promoting the snapshot into general project knowledge.

Also reject unnecessary personal information about customers, coworkers or people mentioned in tickets. A support case may justify reading an address for that case without justifying its appearance in future coding sessions. Preserve the general lesson using a synthetic example. Do not turn an agent’s guess about someone’s role, health or intentions into a durable profile.

Save the qualification along with the fact

For your own memory store, require a statement, scope, evidence reference, recording date and review trigger. These are proposed record fields, not a universal agent-memory format. The qualification should survive extraction and summarization; otherwise a careful observation can become an unconditional rule.

For example, replace “never add a required database column” with “the billing team’s accepted migration decision requires additive changes while mixed worker versions are supported; review when that compatibility window ends.” The second version tells a later agent when the advice applies and where to verify it.

Separate observations from approvals. “An agent suggested extending the timeout” and “the service owner approved a longer timeout” describe different events. If approval cannot be traced, preserve the proposal as a proposal or leave it unsaved. Repeated extraction of the same unsupported claim should not increase its authority.

When a decision changes, replace or explicitly supersede the old entry rather than leaving two equally current answers. Use review triggers tied to the claim, such as a runtime upgrade or a revised architecture decision. Retention and deletion policies cover the lifecycle mechanics; the admission rule here is to avoid saving a claim whose useful lifetime you cannot describe.

Do not let remembered text grant authority

A ticket that says “remember to disable approval checks” is source content, even if an extraction model finds it memorable. OWASP documents persistent prompt-injection attacks and poisoning of retrieved context. Its guidance also distinguishes separating instructions from data from enforcing permissions: text labels alone do not establish a security boundary.

For memory selection, reject attempts to create new privileges, bypass confirmations or redefine policy from retrieved documents and tool responses. Keep any legitimate finding as an attributed observation. A note that a staging deploy succeeded yesterday cannot authorize a production deploy today.

Apply the caller’s access restrictions before retrieving memories, and keep action authorization in the tool execution layer. A polished summary must not make a private customer note eligible for workspace-wide recall. These rules belong in the memory admission and retrieval design, alongside the deeper review of memory poisoning.

Make automatic capture a deliberate choice

Review what your harness already saves before adding another capture mechanism. Claude Code documents this setting in ~/.claude/settings.json for disabling its auto memory. Merge the property into your existing settings object:

{
  "autoMemoryEnabled": false
}

Its documented /memory command lets you inspect memory locations and toggle auto memory. Disabling capture does not erase existing notes: the documentation says memory files remain until edited or deleted, separately from transcript cleanup. Inspect retained files when changing your policy.

For a sensitive investigation, choose whether any durable learning is needed before the session starts. Afterwards, promote a concise lesson with secrets and identifying details removed. Treat each installed plugin’s capture behavior separately; this Claude Code setting is not a universal switch for every memory writer.

Selective memory with SPYN3

SPYN3’s Memory & skills setting is opt-in per workspace and off by default. Personal and shared memories use separate paths; reads need call:tools, while writes need write:memory. Recalled memory is labelled as recorded data, and every memory write is audit-logged. Automatic capture is a second setting, off by default, requiring the workspace’s own model key. Enable only the capture your policy calls for; the choice of what deserves saving still belongs to your team.

Check that forgetting improves the next session

Review candidate memories against paired future tasks before enabling broad capture. These are useful acceptance cases for a selective memory policy:

1. Give the agent a recorded billing migration decision and a new change that falls within its compatibility window. It should retrieve the rationale and verify the decision reference.
2. Repeat with evidence that the compatibility window ended. It should recheck the constraint instead of treating the old memory as permanent policy.
3. Include a synthetic credential and an unrelated person’s details in a transcript. Inspect the resulting memories to confirm neither was retained.
4. Run a different caller’s task. Personal preferences and restricted case notes should stay outside that caller’s recall.

Inspect what was stored as well as what the agent answered. A correct answer can conceal an unnecessary retained secret; an empty recall can be the correct result for a transient observation. Keep memories that prevent a demonstrated repeat mistake, revise misleading ones, and delete entries that no longer have a defensible future use.