Decide what to remember across sessions

Learning objective

Decide what belongs in Agent Platform Memory Bank and when an agent should retrieve it into a later session. This lesson focuses on memory selection and recall policy, not on session storage or general retrieval-augmented generation (RAG) design.

Core idea

Use two separate gates: a write gate decides what deserves to outlive the session, and a read gate decides what deserves space in the current model context.

Store a memory only when the information has future value, a suitable lifetime, an authorized identity scope, and acceptable privacy and integrity risk. Retrieve it only when it is relevant to the current task, still applicable, and useful before the agent responds or acts.

Memory Bank stores independent, self-contained facts in isolated scopes and makes them accessible across sessions. It can extract and consolidate facts from conversation history, but it does not make every event a memory. The Memory Bank overview describes memory extraction, consolidation, scoped retrieval, expiration, and revision history.

How it works

Apply the write gate

Evaluate a candidate fact against four questions:

1. Will another session benefit? Durable preferences, recurring constraints, significant user information, and important task outcomes can qualify. Intermediate reasoning, tool traces, greetings, and one-time details usually do not.
2. Is memory the right authority? Remember a user’s preference, but query the system of record for a current balance, entitlement, inventory level, or policy. Memory can personalize a decision; it should not replace authoritative operational data.
3. Is the scope and retention period correct? Bind the fact to the narrowest useful identity, such as a user rather than an entire application. Give temporary facts an expiration policy. Memory Bank supports time to live (TTL), after which a memory becomes unavailable and is deleted.
4. Is persistence permitted and safe? Exclude secrets and data prohibited by policy, minimize sensitive data, and support correction and deletion. Memory extraction is model-driven: Google cautions that its sensitive-data exclusion is not infallible in Generate memories.

Configure memory topics to encode the write policy. Managed topics include user information, user preferences, key conversation details, and explicit remember or forget instructions. Custom topics and few-shot examples can narrow what your application treats as meaningful. Generation extracts matching facts and, by default, consolidates them with existing memories in the same scope to remove duplicates or reconcile changes.

Apply the read gate

Retrieval is a context decision, not a consequence of persistence. Use this sequence:

1. Resolve the authenticated identity and request the exact intended scope.
2. Determine the user’s current intent before loading topic-specific memory.
3. Retrieve the smallest useful set: all memories for a small, bounded scope, or similarity search for a larger collection.
4. Exclude inapplicable or insufficiently relevant facts according to the application’s policy, then place the selected facts in the prompt before they can influence a response or plan.
5. Revalidate consequential facts against their source of truth before taking an action.

RetrieveMemories considers only memories whose scope exactly matches the request. Similarity search compares the request query with memory facts and returns the nearest results; retrieving without similarity parameters returns all memories in that scope. See Fetch memories.

Eager retrieval at session start suits a small set of broadly applicable facts, such as language or accessibility preferences. On-demand retrieval after the intent is known suits project history, prior outcomes, and other topic-specific facts. On-demand retrieval reduces prompt size and irrelevant influence, but it adds a retrieval step and can miss a useful fact if the query is weak.

Key distinctions and trade-offs

Agent Platform Sessions stores the events of one ongoing interaction, while memory is personalized information accessible across sessions. The Sessions overview defines this boundary. Persisting an entire transcript in Sessions and generating selected memories from it are different operations.

More memory can improve continuity, but it also increases storage, retrieval, prompt-token, privacy, staleness, and poisoning risk. Google identifies memory poisoning as false or malicious information that is stored and later affects the agent. Treat retrieved memory as contextual input, not trusted instructions or proof of authorization.

Architecture / decision scenario

A developer-support agent serves the same engineer across many sessions. During one session, the engineer says, “Remember that I prefer Python examples and concise explanations.” The write gate accepts these durable preferences under the engineer’s user scope. A transient stack trace stays in the session, and the engineer’s current support entitlement stays in the customer system.

In a later session, the engineer asks for a retry implementation. The agent first resolves the same user scope. Because presentation preferences apply broadly, it retrieves the small preference set before drafting the answer and produces a concise Python example. If the engineer instead asks whether premium support is active, the agent queries the customer system; it does not treat an old memory as authorization evidence.

Suppose an earlier conversation claimed that the engineer prefers Java. Memory consolidation can update the stored preference, and revisions can support audit or rollback. The application still needs a correction path and should not let an untrusted message store instructions that override system policy.

Common exam traps

• Treating Memory Bank as a complete transcript store instead of a curated set of cross-session facts.
• Assuming every persisted memory should be injected at the start of every session.
• Retrieving with the wrong or overly broad scope and risking cross-user context.
• Using similarity as proof that a memory is current, correct, or authoritative.
• Storing volatile business data in memory instead of querying its source system.
• Trusting model-based extraction to enforce privacy or resist memory poisoning without additional controls.

What to remember

• Use a write gate for future value, authority, scope, retention, and safety.
• Use a separate read gate for relevance, applicability, and timing.
• Keep session history, long-term memory, and external knowledge distinct.
• Retrieve all only for small bounded sets; use scoped, selective retrieval as memory grows.
• Treat memories as personalization context, not authorization or authoritative operational data.

Knowledge check

References

• Google Cloud, Agent Platform Memory Bank
• Google Cloud, Generate memories
• Google Cloud, Fetch memories
• Google Cloud, Agent Platform Sessions overview