Agent Memory as a Bounded State Store

An agent should remember only information it is authorized to retain and can use responsibly. Its memory is not an archive of every message, tool result, or intermediate inference. It is a bounded, provenance-bearing state store: each retained item has a purpose, a scope, an accountable source, and a rule for review or deletion.

The distinction is between scratch memory and durable memory. Scratch memory supports the current task: temporary notes, intermediate calculations, working hypotheses, and tool results. Durable memory supports future tasks: a small set of user-approved facts or preferences likely to remain useful across sessions.

These stores require different controls. Scratch memory should expire when its task or session ends, subject to a clearly defined operational deletion process. Durable memory may persist longer, but persistence is conditional: the agent must know where an entry came from, when it was recorded, and when it must be reviewed or removed. Neither store should be treated as an unlimited transcript.

What belongs in each store

A temporary list of files inspected during a coding task belongs in scratch memory. A user’s explicitly approved preference for concise code explanations may belong in durable memory. A claim that a particular file implements an interface is more fragile: if retained, it needs a citation to the relevant code and validation against the current version before use.

The boundary is not simply “short term versus long term.” It also separates working material from reusable assertions. A tool result can be useful for the current task without becoming a trusted fact about the user. Likewise, an agent’s inference about a preference is not equivalent to a preference the user has confirmed.

Memory Mechanics: Write, Retrieve, Validate, Forget

Control the write path

Memory writes should be explicit operations, not automatic byproducts of conversation. Before storing a durable entry, the system should assess:

1. Purpose: Is the information likely to help with a future task?
2. Authorization: Has the user approved this category of retention or the specific entry?
3. Support: Is the entry grounded in an identifiable source rather than an unsupported inference?
4. Scope: Does it apply to this user, project, repository, or task—and no more broadly?
5. Sensitivity: Does it contain material that must not become reusable memory?
6. Lifetime: When will it expire, or what event will require review?

Passing these checks should produce a compact entry rather than a copy of the surrounding conversation. For example, “Prefers tables for comparison questions” is more appropriate than storing an entire exchange containing that preference, assuming the user has approved its retention.

Untrusted webpages, files, and tool outputs may contain instructions addressed to an agent. Those instructions must not be promoted into trusted durable memory. If an external document contains useful factual evidence, the agent can record a narrowly scoped claim with its source and trust level; it must not convert the document’s commands into governing instructions.

Attach provenance and lifecycle metadata

A practical durable entry should contain at least:

• Claim or preference: The smallest useful assertion.
• Scope: The user, project, repository, or context to which it applies.
• Source: A citation or traceable reference, such as a user statement or specific code location.
• Timestamp: When the evidence was observed and, where relevant, when the underlying fact was valid.
• Confidence: A calibrated assessment that distinguishes confirmation from inference.
• Expiry or review condition: A date, event, or change that triggers removal or reassessment.

A citation need not always be a public URL. For a user preference, it can be a protected reference to the relevant user statement. For code, it can identify a repository location and version context. The reference should be sufficient for authorized verification without unnecessarily reproducing sensitive source material.

GitHub describes an agentic coding-memory implementation that associates memories with citations to code locations and checks those locations against the current branch before relying on them. Contradicted or invalid citations are a reason to correct the memory rather than reuse it blindly. [1]

Retrieve narrowly and validate before use

Retrieval should begin with the current task and return only entries relevant to it. An agent answering a formatting question, for example, may need a formatting preference but not an unrelated project history. Scope filtering is especially important when an agent serves multiple users or projects.

A retrieved entry is a candidate for use, not an instruction to accept. The agent should check its citation against the available source, assess whether its scope still matches, and look for newer contradictory evidence. If the source is unavailable, the agent should not describe an old factual memory as freshly verified. If the evidence is missing or irreconcilable, it should ask for clarification or abstain.

Validation requirements differ by claim. A directly stated preference may remain usable until changed or due for review. A code-location claim can become stale after a branch change. A time-sensitive fact may need a fresh source every time it matters.

Define update and deletion behavior

A durable store needs explicit operations for correction, supersession, and forgetting. When a user changes a preference, the new authorized statement should replace the old active preference. When code changes contradict a stored claim, the claim should be corrected or removed after checking the relevant branch.

Expiry should have an enforceable effect. A review date that is repeatedly ignored is not a meaningful bound. If review cannot be completed, the entry should become unavailable for ordinary use or be deleted under the system’s retention rule. Scratch expiry should also cover temporary copies, indexes, and derived notes, with any backup deletion delay made explicit in the implementation.

Contrasting Memory Methodologies

Transcript accumulation versus selective state

A transcript-based approach retains broad context and retrieves passages later. It can preserve detail, but it also expands the material that must be searched, increases exposure to irrelevant or sensitive content, and makes it harder to distinguish a user instruction from an external instruction quoted in a tool result.

Selective state takes the opposite approach: retain only approved, supportable items that have a defined future use. It sacrifices some potentially useful detail for clearer boundaries and more manageable correction. This design does not guarantee accuracy; its advantage is that each remembered claim can be inspected, challenged, and retired.

Summarization versus cited memory

Summarization reduces volume, but a summary without provenance can turn an uncertain interpretation into an apparently authoritative fact. A cited entry preserves the connection between the assertion and its evidence. The citation also enables revalidation when the underlying environment changes. GitHub’s code-location checks illustrate this distinction for repository facts. [1]

The two methods can be combined: summarize scratch material for the current task, then propose only individual, cited claims for durable storage. Promotion should require the write checks above, including user approval where applicable.

Fixed recall versus managed change

A recall-only system rewards finding old information. A managed-memory system must also recognize when old information is wrong. MemoryAgentBench evaluates retrieval alongside deployment-time learning, long-range understanding, and conflict resolution. LongMemEval tests capabilities including temporal reasoning, knowledge updates, and abstention across 500 questions. [2][3] These benchmarks support a broader evaluation target: not just whether an agent remembers, but whether it updates and withholds unsupported answers.

As an industry participant, AI Plaza provides a practical catalog context for illustrating the workflow: an agent using GPT-6.1 Sol or Claude-Sonnet-5.5 could maintain task notes in scratch state and propose a verified, user-approved preference for durable storage. The model name does not replace the surrounding controls; authorization, source checks, expiry, and deletion must be enforced by the application.

Security and Long-Term Implications

Treat memory poisoning as a persistent threat

A poisoned scratch result may affect one task; a poisoned durable entry can be retrieved again in later sessions. Research on memory poisoning identifies this persistence as a distinct risk for agent systems. [4] Consequently, write screening and retrieval-time validation are complementary: blocking a suspicious write is preferable, but a stored entry must still be treated as potentially stale or compromised.

The system should preserve the trust distinction between a user’s authorized instruction, an agent inference, and content supplied by an external source. A citation proves where a claim came from; it does not, by itself, prove that the source is reliable or that instructions in it are authorized.

Establish material that must never become reusable memory

Credentials, API keys, passwords, private tokens, and malicious instructions must not be stored as durable, reusable memory. The same prohibition should apply to unnecessary copies of sensitive material encountered during a task. Where a tool must handle a secret to complete an authorized operation, the secret should be passed through a controlled mechanism rather than written into agent memory; transient exposure should be minimized and excluded from reusable notes.

A user request to remember something does not make malicious instructions or credentials safe to retain. Systems should also prevent these items from entering memory through summaries, citations, embeddings, or logs that function as a retrieval store.

Measure forgetting as well as recall

As agents operate over longer periods and across more tools, memory quality depends increasingly on lifecycle management. Evaluation should include tests for stale-entry removal, preference changes, conflicting sources, cross-user isolation, poisoned tool output, expired scratch retrieval, and abstention when a citation cannot be checked.

The operational standard is therefore narrower than “remember everything useful.” Remember only what is task-relevant, user-approved, and supportable; cite factual durable claims; expire temporary context; and make correction and deletion first-class operations. A memory system is trustworthy not because it never forgets, but because it can justify what it retains and stop using what it no longer has reason to trust.

References

[1] https://github.blog/ai-and-ml/github-copilot/building-an-agentic-memory-system-for-github-copilot/ [2] https://ar5iv.labs.arxiv.org/html/2507.05257 [3] https://ar5iv.labs.arxiv.org/html/2410.10813 [4] https://arxiv.org/html/2606.04329