NVIDIANVIDIA-Certified Professional: Agentic AI2026-101.4 Manage short-term and long-term memory for context retention.
Scope memory and retire invalid facts
Completed by the knowledge check
Learning objective
Define memory isolation, retention, and invalidation per user and tenant.
Core idea
A memory design needs three independent decisions: who can read or write a record, how long it can remain, and what makes it unusable before that period ends. Relevance answers none of these questions. A highly similar memory can belong to another tenant, exceed its retention period, or describe a fact that has been corrected.
Use the storage roles from 1.4.1, then define a lifecycle for each scope. Ranking, decay, and deletion implementation belong to 5.1.3; the architect must first say which records those mechanisms are allowed to expose or retain.
How it works
Bind identity before memory access
NeMo Agent Toolkit documents SessionManager.session(user_id=...) for production integration with custom authentication middleware. Resolve identity from authenticated application credentials and supply that identity to the session. Do not ask the model to decide which user’s memories it may search from text in the request.
The wrapper’s configuration page also shows X-User-ID for testing and a console default of nat_run_user_id. Neither a test identity nor a shared console default is a production authorization design. Use the documented session integration rather than promote a client-supplied user label into authority. Conversation-aware backends can use conversation_id to distinguish conversations belonging to the same user; support is backend-specific. For Zep Cloud, omitting conversation_id uses a deterministic per-user default thread, so separate sessions without explicit conversation IDs share that thread. Supply conversation_id when those conversations must remain separate.
The wrapper documentation calls its mechanism “Multi-Tenant Memory Isolation”, implemented through runtime user_id extraction. That user-ID boundary does not itself distinguish an organization from its users. Tenant identity needs an equally explicit treatment. If two organizations both have a local user 42, those labels must resolve to different authorized memory subjects. One application design is to map the authenticated tenant-and-user pair to a globally unique subject supplied as user_id. Keep the reverse mapping in the identity service. This is an application naming design, not a toolkit tenant field or an automatic guarantee about every provider.
Make scope part of the access path
LangGraph’s store uses tuple namespaces and item keys. An application can define a namespace such as (tenant_id, user_id, "preferences"); the tuple layout is application-defined. The server constructs it from verified identity and the permitted memory purpose. store.get(namespace, key) addresses one record, while store.search(namespace_prefix, ...) searches under a prefix.
Prefix matching matters: a search using only (tenant_id,) can span that tenant’s user subnamespaces. Broadening a namespace for convenience can therefore broaden the data returned. Give a user-memory operation the intended user prefix, and reserve tenant-wide retrieval for an explicitly authorized shared-knowledge operation. Separate namespaces organize data; the application still authorizes which namespace a caller may use.
Thread identifiers require the same ownership check. LangGraph identifies checkpointed conversations through configurable.thread_id. Resolve or validate that thread against the authenticated user and tenant before invoking the graph. A random-looking thread ID is an identifier, not proof that its caller owns the thread. Changing the long-term namespace alone does not fix a request that resumes another user’s conversation.
Define retention separately from usefulness
Produce a memory-policy table with a row for each purpose and scope. Specify allowed content, retention period, the event that starts that period, invalidation triggers, and an accountable owner. Do not copy one expiration value onto raw conversations, user preferences, and shared organizational facts because they use the same backend.
NVIDIA’s MemoryItem.metadata is an extension point for application-defined fields. A custom provider can record expires_at, source_id, source_version, and status there. These names are an example schema, not built-in NeMo Agent Toolkit expiration or filtering keys. The provider’s MemoryEditor.add_items writes the metadata, search enforces eligibility before returning content, and remove_items implements deletion through its backend. Confirm that an existing provider offers the required behavior before choosing it instead of a custom implementation.
Expiration and deletion are separate obligations. Eligibility checks stop a logically expired record from reaching inference even if physical cleanup runs later. Cleanup removes the retained copy according to policy. The platform owner must include derivative summaries, indexes, and logs in the retention inventory. The wrapper’s verbose defaults to False to help prevent logging sensitive data; setting it to True logs memory operations and intermediate steps. Include those logs in a separate retention policy. Removing a source message while leaving a readable summary can preserve the information the policy intended to retire.
Invalidate when the source changes
Retention is the maximum permitted lifetime, not a promise of accuracy for that entire period. A user correction, account move, revoked sharing permission, or changed source document can invalidate a memory immediately. Define those events in the policy before selecting a backend.
For example, use the application-defined source_id and source_version to find records derived from a replaced policy document. Mark them ineligible through the provider’s write path and exclude them in search while deletion or rebuilding completes. For a LangGraph store integration, aput(namespace, key, value) writes a replacement value and adelete(namespace, key) removes an item. The application must enumerate affected keys; changing a source document does not itself describe which stored derivatives to remove.
Expiration and invalidation each stop a record from reaching inference before cleanup or deletion removes it.
Read-time checks must also apply to summaries or memories already selected for a pending response. At response assembly, compare their recorded source version or status with the application’s authoritative version registry. This is application logic at the memory-to-context handoff, not a promised toolkit callback. See 5.1.3 for implementing the retrieval and expiry machinery; the policy here determines when an answer must refresh its sources.
Key distinctions and trade-offs
User-private memory and tenant-shared knowledge have different readers. An employee’s preferences need not become shared knowledge merely because every employee belongs to one tenant. A tenant-wide policy document, conversely, should not be copied into hundreds of private profiles without a way to invalidate the copies.
Logical namespaces make shared infrastructure economical but rely on correct authorization at every access path. Dedicated stores can support stronger operational separation at greater administrative cost. Neither choice removes retention and invalidation responsibilities. Select from the tenant’s requirements, then verify the chosen provider’s access and lifecycle behavior.
Automatic capture expands the retention surface. The auto_memory_agent flags save_user_messages_to_memory and save_ai_messages_to_memory both default to true. Disable the applicable writes when policy forbids those messages in that destination; disabling future capture does not retire records already stored there.
Architecture / decision scenario
A payroll assistant serves 12 client companies, each with its own employee identifiers. Its delivery policy permits raw conversations for 7 days and confirmed language preferences for 90 days. Client policy changes must stop influencing answers within 5 minutes. These are scenario requirements, not product defaults.
An engineer proposes one namespace per employee number and nightly cleanup. The security owner rejects that design: employee 42 occurs in multiple tenants, and a 24-hour invalidation delay exceeds 5 minutes. The application instead resolves authenticated tenant-and-user pairs into distinct session subjects, authorizes conversation ownership, and constructs full user namespaces for private memories. Shared payroll rules use a separate authorized tenant namespace.
The data owner approves the 7-day and 90-day retention rows and defines policy-document replacement as an immediate invalidation event. The provider enforces application metadata during search; a source-version check at response assembly excludes superseded material even before physical cleanup. The platform owner handles deletion of source records and derived summaries. This design satisfies distinct isolation, retention, and invalidation requirements without treating nightly deletion as the answer to all three.
Common exam traps
- Treating
user_id,conversation_id, orthread_idas authentication credentials. - Assuming a tenant prefix restricts retrieval to one user within that tenant.
- Reading the toolkit’s “Multi-Tenant Memory Isolation” as an organization boundary: its mechanism isolates by
user_id. - Confusing a retention deadline with a guarantee that a fact remains valid until then.
- Deleting raw messages while leaving their readable derivatives eligible for retrieval.
- Presenting application metadata names as portable provider configuration keys.
What to remember
Authenticate the subject, authorize the thread and namespace, and define separate retention and invalidation rules. Enforce those rules where stored memory becomes model context. Assign a data owner for policy and a platform owner for removal, including derivatives; automatic capture and similarity ranking cannot replace either responsibility.
Knowledge check
A NeMo Agent Toolkit assistant with auto_memory_agent serves 12 client companies, and each company numbers its own employees, so employee 42 exists in several of them. Custom authentication middleware verifies the tenant and the employee on every request. What should the application pass as the memory user_id?
X-User-ID headeruser_id , so two companies’ employee 42 would share one memory subject unless the application maps the verified pair to a globally unique subject and supplies it through SessionManager.session(user_id=...) . X-User-ID is the documented testing path, and a conversation ID identifies a session rather than the durable tenant-and-user subject.A NeMo Agent Toolkit workflow uses auto_memory_agent with Zep Cloud. The front end sets user_id through SessionManager.session but supplies no conversation_id. Users report that one support session’s discussion surfaces in another, while their preferences should still follow them across sessions. What should the team change?
user_id for each support sessionsave_ai_messages_to_memory to false in the wrapper configX-User-ID headerconversation_id for each support sessionconversation_id separates the sessions while user_id still names the person; a random or header-supplied user ID splits the user’s memory and abandons the authenticated identity, and disabling assistant writes still leaves user messages shared.A LangGraph store keeps each employee’s private preferences under (tenant_id, user_id, "preferences") and the tenant’s shared payroll rules under (tenant_id, "shared"). A preference lookup calls store.search((tenant_id,), query=...) and starts returning other employees’ preferences. What fixes the leak?
limit so that it returns fewer items(tenant_id, user_id, "preferences") prefixstore.search matches by namespace prefix, so (tenant_id,) spans every user’s sub-namespace within that tenant. A user-memory operation needs the full user prefix, built on the server from the verified identity. A dedicated store per tenant separates tenants, but this leak is between users of one tenant, and a lower limit only returns fewer of the wrong records.A payroll assistant stores memories derived from each client’s policy documents, with application metadata source_id and source_version, and a nightly job deletes superseded records. Unchanged policies must remain available for 90 days. A replaced policy must stop influencing answers within 5 minutes, including responses whose memory search has already run. What meets both requirements?
search . At response assembly, check the recorded source version or status against the authoritative registry to catch records retrieved before invalidation. Five-minute retention loses unchanged policies needed for 90 days; ranking and nightly deletion do not meet the invalidation deadline.A memory provider must retire conversation content after 7 days. It stores raw messages and rolling summaries generated from them. After 7 days the platform deletes the raw messages, but the assistant still answers with conversation details from summaries retrieved from that provider. What does the retention design lack?
save_user_messages_to_memory for that provider’s wrappersearch_params.top_k for the memory searchtop_k still returns retained summaries, and deleting a checkpoint leaves the provider’s retrieved summaries in place.References
- NVIDIA, Configure the Automatic Memory Wrapper Agent
- NVIDIA, Adding a Memory Provider
- LangChain, Stores
- LangChain, Persistence