NVIDIANVIDIA-Certified Professional: Agentic AI2026-105.1 Implement memory mechanisms for short- and long-term context retention.
Reconcile facts before writing durable memories
Completed by the knowledge check
Learning objective
Write long-term memories with extraction, deduplication, and updates that avoid reinforcing errors.
Core idea
A memory write changes what the agent can treat as background context in later conversations. If the agent guesses a delivery preference, stores its answer, retrieves that answer, and writes it again, repetition can make one unsupported claim appear well established. Durable memory needs a reconciliation step between observing text and committing a fact.
The store-selection and authorization decisions belong to 1.4.1 and 1.4.2. This lesson implements the write path: extract a candidate claim with its source, find any existing claim about the same subject, and choose insert, no-op, correction, or unresolved conflict. A successful database write proves persistence; the reconciliation decision determines whether the stored content deserves to influence a later answer.
How it works
Extract claims with their origin
LangChain’s memory overview distinguishes an updated JSON profile from a collection of narrower memory documents. A profile concentrates related facts but becomes harder to update without losing fields as it grows. A collection makes individual facts easier to generate, while shifting complexity into matching, updating, deleting, and retrieving documents. Choose a representation before designing the extractor.
For a collection, give the extraction output an explicit schema. A practical application schema includes subject, attribute, value, source_id, source_version, and status. These are fields you define, not NeMo Agent Toolkit configuration options. Preserve whether the source is a user’s explicit preference, an authoritative tool result, or an assistant proposal. A generated answer can describe a proposed memory, but cannot independently confirm its own content.
NVIDIA’s extension interface provides a concrete place to implement this: MemoryItem carries textual memory, conversation, user_id, tags, and metadata; MemoryEditor.add_items accepts the items. Put the reconciliation schema and provenance into the provider’s data model or MemoryItem.metadata. Implement extraction and validation in a workflow function before calling add_items, or inside a custom provider’s write implementation. Choose one owner so an unfiltered path cannot bypass the check.
The model-invoked path is functions.add_memory with _type: add_memory, exposed through the agent’s tool_names (see 1.4.1). Its tool action calls the selected memory client’s add_items. Model-proposed content therefore needs reconciliation in that provider’s write implementation; otherwise, leave the tool out of tool_names for the durable fact destination. A tool invocation is not proof that its proposed fact is supported.
Validate the schema and the candidate’s support before committing. For example, an assistant saying “I have upgraded your account” is not an authoritative account-state observation. Require the account tool’s result before writing that status. A malformed extraction is rejected for repair; an unsupported claim stays uncommitted. Retrieval of the same assistant text later does not supply an independent source.
Deduplicate by meaning and identity
Exact event identity and semantic equivalence solve different problems. Record source_id so replaying one input does not create another observation. Then match on a stable subject and attribute: two differently worded statements about the same person’s preferred delivery window may represent the same fact. Embedding similarity can find candidates, but two opposite values for the same attribute are also highly related. Compare their structured values before deciding.
LangGraph’s store interface makes the persistence operation explicit: aget(namespace, key) reads a known record, and aput(namespace, key, value) stores or overwrites it. A stable key for a single-valued attribute lets the writer reconcile against the existing value instead of assigning an unrelated identifier for every paraphrase. For multi-valued attributes, include the value’s identity in the key and retain its individual provenance.
For a matching supported value, perform a no-op or attach a genuinely independent source to the same record. Do not increase confidence because the same source_id reappears, because a summary repeats it, or because the agent quoted it. For a different value, determine whether the source supplies a correction, a time-bounded change, or an unresolved contradiction. Similarity search alone does not decide which one applies.
Apply corrections without feeding back errors
Use an application-defined source_version to order revisions from the same authoritative source. Read the existing value before producing the replacement. An explicit correction can replace a prior preference; two disagreeing systems of record may require a conflict status and review. Wall-clock arrival time alone does not make the last received statement the most authoritative one.
aput supplies overwrite behavior, not your conflict-resolution rule. Serialize writes for a subject and attribute, or use the selected backend’s concurrency controls, so two read-modify-write operations do not silently discard each other’s provenance. Likewise, MemoryEditor is an extension interface: the custom implementation owns reconciliation rather than inheriting a universal upsert policy from the method name add_items.
The automatic wrapper described in 1.4.1 and 1.4.2 defaults both save_ai_messages_to_memory and save_user_messages_to_memory to true. Set save_ai_messages_to_memory: false to disable automatic assistant-message writes. Use that control when raw assistant answers must not enter the durable fact destination. If user utterances also need extraction and verification before persistence, disable save_user_messages_to_memory for that destination and route accepted candidates through the explicit writer. Excluding assistant messages reduces one feedback path; the candidate checks still determine whether remaining content is valid.
Key distinctions and trade-offs
Make each write outcome observable in the writer’s result or audit record:
| Candidate condition | Write decision | Concrete mechanism | Trade-off |
|---|---|---|---|
| Supported fact with no existing match | Insert | Accepted MemoryItem through add_items, or aput at an unused key | Adds durable coverage and storage |
| Same source replay or equivalent value | No-op or merge independent provenance | source_id comparison and stable-key lookup | Matching costs work but prevents duplicate reinforcement |
| Authoritative correction | Replace the active value | Compare source_version, then aput on the same key | Preserves one active answer; requires concurrency control |
| Unsupported or conflicting claim | Reject or retain as ineligible for answer generation | Schema validation and application-defined status | Reduces automatic coverage and can require review |
LangChain documents writing on the response path and in a background process. Synchronous reconciliation makes an accepted correction available immediately but adds extraction and storage latency. Background processing separates that work from the response, at the cost of a period when another conversation can read the previous value. Measure that freshness interval rather than promise immediate memory after an asynchronous acknowledgment.
Architecture / decision scenario
An online retailer’s customer assistant receives 20,000 preference statements per day. In a replay sample, 6,000 are repeated deliveries of the same source event and 2,000 are paraphrases of an already stored value. Another 200 explicitly correct a delivery window. The service owner allows background preference extraction to lag by 30 seconds, but requires explicit corrections to affect the next answer immediately. These are scenario requirements.
A proposed append-only writer stores all 20,000 statements and all assistant acknowledgments. It is attractive because it avoids reconciliation reads, but it multiplies repeated values and leaves the 200 corrections competing with superseded values. An assistant’s mistaken acknowledgment can become another retrieved statement supporting itself.
The memory engineer instead extracts supported preferences, checks source_id, and reconciles each subject-attribute key. The 8,000 repeated or equivalent candidates create no duplicate fact records; accepted corrections overwrite the active value after comparing provenance. Background processing handles ordinary candidates within the 30-second allowance. The correction path completes the write before the assistant confirms that the preference is remembered.
The commerce data owner decides which account source resolves conflicts. The workflow owner disables automatic raw-message writes into the preference destination and routes candidates through the explicit writer. Release evaluation replays each source event twice and injects contradictory assistant text: the active preference count must remain stable, and an unconfirmed assistant assertion must not replace the authoritative value.
Common exam traps
- Treating automatic message capture or model-invoked
add_memorywrites as validated fact extraction. - Confusing semantic similarity with equivalence or authority.
- Counting paraphrases of one source as independent confirmations.
- Appending a correction while leaving the superseded value equally eligible.
- Assuming
aputoradd_itemssupplies conflict resolution and concurrency control. - Promising immediate cross-conversation freshness from a background write.
What to remember
Extract a claim with provenance, reconcile it against a stable identity, and commit an explicit outcome. Separate repeated observations from independent support and corrections from unresolved conflicts. Use the documented write interfaces to persist the decision; keep verification and reconciliation in an owned implementation that cannot be bypassed by automatic capture.
Knowledge check
A preference writer keeps one record per customer and attribute and increments a support_count each time it stores a matching value. A message-queue retry delivers an already stored chat event three more times, and the record’s count rises from 1 to 4. Which check prevents this reinforcement?
source_id and treat any repeat as a no-opsource_id and ignoring a repeat keeps the count honest. Similarity matching compares content; it does not distinguish a replay from an independent event with the same text. A key per delivery multiplies duplicate facts instead, and ordering by arrival time says nothing about whether a delivery is new evidence.A memory writer deduplicates delivery preferences by embedding similarity: a candidate scoring above a threshold against a stored memory is skipped. A customer who preferred morning delivery now asks for evening delivery, and the new statement is skipped. The two statements score higher against each other than most genuine paraphrases do. Which change fixes the writer?
A NeMo Agent Toolkit automatic memory wrapper runs with its default settings in front of an order assistant. After the assistant wrongly tells a customer “your address is updated”, later conversations retrieve that sentence as if it were account state. The account tool is the authority for addresses. Which change stops raw assistant answers from entering this durable memory?
add_memory to the agent’s tool_names for address factstop_k used when searching the stored memoriesMemoryEditor.add_items as an upsert per customersave_ai_messages_to_memory: false for this destinationsave_ai_messages_to_memory closes that path; the address status should come from the account tool through an explicit writer. A model-invoked add_memory is another unverified write path, an upsert still stores the wrong claim, and a smaller top_k only retrieves it less often.Two workers handle corrections to the same customer’s delivery window at the same moment. Each calls aget on the stable key, builds a replacement record with merged provenance, and calls aput. Audits show one correction’s provenance missing from the final record. Which change prevents the loss?
aput to merge both replacements written to one keyaput stores or overwrites; it supplies no conflict resolution, so two concurrent read-modify-write cycles let the second write discard the first one’s provenance. Serializing writes per subject and attribute, or using the backend’s concurrency controls, closes the race. Last-arrival wins is exactly what lost the data, and separate keys leave competing active values.A travel assistant extracts preferences in a background process that lags by up to 20 seconds. The product owner requires an explicit seat-preference correction to shape the very next answer, including one in a conversation the traveler opens straight afterwards; other preferences may lag, and ordinary extraction must stay off the response path. Which write design meets this?
References
- NVIDIA, Adding a Memory Provider
- NVIDIA, Configure the Automatic Memory Wrapper Agent
- LangChain, Memory overview
- LangChain, Stores