I thought about AI agent Memory from the perspectives of correction, inspection, and deletion

Introduction

Hello, I'm Morishige from Classmethod's Manufacturing Business Technology Division.

I want AI agents to remember the circumstances and preferences I've told them before. If I can reduce the hassle of re-explaining background context every time, I'd want to give them long-term Memory. However, thinking about continued use, there are things I'm concerned about beyond just whether they can remember. Can I correct them when circumstances change? Can I notice incorrect memories? How much can I delete information that's no longer needed?

NVIDIA introduces a design in their Memory-Driven Chief of Staff recipe that organizes and updates business context, and connects human corrections to subsequent decisions. Using that approach as a guide, I traced the mechanisms for continuing to use memory over time.

https://developer.nvidia.com/blog/building-a-memory-driven-agent-with-nvidia-nemoclaw/

To examine the storage processing underlying the original article's design, I ran the public recipe with synthetic data and verified human corrections, Memory inspection, and message body retention periods. This is not a product adoption evaluation, but rather a verification to think about what operations I want to incorporate into my own agent.

Regarding the NemoHermes and OpenShell execution environment, I covered that in an article from June 2026. This time, rather than continuing from that setup, I'll focus on how stored information is handled.

https://dev.classmethod.jp/articles/dgx-spark-nemohermes-openshell-hermes-agent/

In this article, I'll think about operations for continuing to use long-term Memory while comparing NVIDIA's design philosophy with the behavior I observed locally. In the latter half, I'll extend that thinking to a fictional business case, tracing through changing priorities, reverting them, and deleting unnecessary records. I hope this resonates not just with NemoHermes users, but with anyone trying to give business agents persistent memory.

What the Original NVIDIA Article Is Trying to Convey

The original article, published September 4, 2026, introduces a design for passing daily-changing business context to agents to improve decision quality. At the center is a knowledge layer called the self model. It organizes people, cases, priorities, and their relationships, and regularly incorporates new activities and the person's own decisions for updates. For each task, only the necessary context is retrieved from there. Rather than storing large amounts of conversation, the goal is to be able to connect past decisions with the current situation.

To achieve this: separate the source material from derived knowledge and execution; use not just the urgency stated in a request, but the priorities the person themselves has indicated as the standard; have the person enter corrections for mistaken decisions, and reflect those corrections in subsequent decisions. These designs form the pillars of the original article. Furthermore, it emphasizes that memory is decision-making material and not permission to act, and that execution-time permissions are controlled on the OpenShell side.

I organized the relationships shown in the original article into a conceptual diagram.

Conceptual diagram based on the NVIDIA original article. Shows the flow of connecting business memory and human corrections to decisions. Not my local execution configuration.

Regarding performance, the article reports that in an evaluation of 186 questions using NVIDIA Nemotron 3 Ultra for both configurations, the overall accuracy of agentic RAG using multiple retrievals was 82.8%, while the configuration using a self model was 90.9%. On the other hand, some items such as questions looking for a single piece of information showed decreases, so the results don't mean that adding Memory improves everything. These are values reported in the original article, not my own measurements.

In other words, the goal of the original article is not to increase memory capacity, but to connect organized context, human corrections, and permission control to business decisions. Taking that as a starting point, this article delves deeper into how long memory whose situation has changed can continue to be used, and how much can be deleted when it's no longer needed.

The Problem Isn't Just Forgetting

What the original article points out is that conversation history mixes current priorities, past decisions, and temporary requests. In this article as well, I treat Memory as records that carry forward information obtained from conversations and business activities for use in future decisions. This is not about additional training of model weights.

For example, here is a fictional example. In a certain case, responses to customers are normally prioritized. Suppose a failure occurs and an instruction is given to prioritize incident response until recovery. Even if the past policy is remembered, it would be problematic if the system reverts to the normal priority order during incident response.

On the other hand, saving this temporary change as a continuous preference also seems wrong. An instruction that applies only to this incident versus the normal policy. Even though both concern priority order, the conditions for using them differ.

With the original article's approach, new priorities are connected to existing context and the memory used for decisions is updated. I wanted to trace that update not just when adding a temporary instruction, but all the way through to when the application ends. Below, I'll verify the correction, inspection, and deletion processing that provides hints for that.

Using the Public Recipe to Separate Memory Roles

NemoHermes is a NemoClaw configuration using Hermes. Memory-Driven Chief of Staff is a public recipe for that environment to organize received messages and indicate replies, decisions, and matters requiring follow-up. Rather than Hermes' standard Memory itself, it adds a mechanism for continuously tracking business situations.

In the recipe, business knowledge is held as Markdown Memory, and business states such as priorities and corrections are recorded in a SQLite Ledger. The Ledger is a ledger that records decisions and change history. In this article, I treat both as information carried over to future decisions, but what I verify in the correction tests below is the state of the ledger side.

The original article separates evidence, knowledge, and permission-controlled execution. Overlaying the recipe's ledger onto that approach, I organize it in this article into the following four roles.

This is a separation for explanatory purposes, not a proposal to split storage into four separate products. For example, having operational procedures written in Memory is separate from whether those operations are permitted to be executed. In this case, I did not test execution permissions; I verified changes in stored state.

The verification date was September 5, 2026, and the environment was Python 3.13.12 and SQLite 3.50.4. I passed synthetic messages and pre-prepared decision results to the version-pinned NVIDIA public scripts. From here on, I'll look separately at the observed behavior and the design considerations based on it.

Do Human Corrections Persist to the Next Session?

The original article introduces a design that honors the person's priority changes and ignore designations in subsequent executions as well. To see how storage processing supports this, I verified whether human corrections would not be overwritten in the next evaluation. For synthetic data items, I applied a correction lowering priority to low and an ignore designation, then applied a synthetic review result attempting to raise the priority. Here, "ignore" means designating the item as outside the scope of action, not deleting the source text.

In this test, the manually specified low designation and ignore state were maintained, and the original body text also remained unchanged. The results of re-sending the same correction are as follows. changed indicates whether the state changed with that operation.

Including the subsequent removal of the ignore designation, there were 3 user change events. This is behavior that does not count re-sending the same designation as a new correction, while retaining different changes in history.

What was confirmed here is not that the LLM understood human intent, but that the storage processing honors manually specified designations. For human-corrected content to be utilized next time, a mechanism that preserves corrections even after updating is fundamental. What I want to incorporate is distinguishing between the person's instructions and the agent's inferences, and being able to trace what was prioritized afterward.

The original article further introduces a flow for reflecting repeated corrections into policies that the person can review and edit. I would add to this flow a distinction between whether an instruction is temporary or a policy for continued use. As in the opening example, this is so that after recovery, the instruction to prioritize incident response can be ended.

The quality of policy updates, and the management of correction deadlines and scope of application, were not verified in this storage processing test. If extending this to my own operations from here, I'd want to include, along with the corrected value, whose instruction it was, which case it applies to, and when it should be reviewed.

Does Memory That Passes Inspection Mean It's Correct?

As a foundation for continuously updating the self model, the original article incorporates rules for indexes, cross-page references, and sources. So what can we learn when that structure breaks down?

Next, I introduced one defect at a time into normal synthetic Memory and ran the public recipe's memory_check.py. The inspection detects 6 types of structural anomalies, and the Memory itself was not rewritten before or after execution.

The source information inspection is the result for the page rules targeted in this case. I did not verify consistency with the source text for all descriptions.

The last example, where the case name was changed without breaking the format, passed inspection. This is not an evaluation of detection rates, but an example showing that passing inspection alone cannot confirm consistency with the source text.

The meaning of separating source material from derived knowledge becomes concrete here. The original article explains that this separation is to make it easier to investigate where the cause lies—in the evidence, the memory update, the search, or the final decision—when an incorrect answer is given. Rather than treating passing the structural inspection as approval of content, the design keeps you able to verify content against the source text after confirming the format.

I would separately verify structural anomalies that can be mechanically detected and whether summaries and current policies are consistent with their basis. Even when entrusting repairs to an LLM, I want to treat the process as a single continuum through to confirming not just the format after repair, but also what basis was used for the repair.

What Does Forgetting Mean—What Gets Deleted?

The design of separating source material from knowledge also relates to deletion. In the data lifecycle explanation included with the public recipe, the policy is to retain records of decisions and changes even after deleting body text that has passed its expiration.

I also verified which information is deleted when a retention period is set. I prepared 8 old body texts and 1 new body text in the synthetic data storage, and processed them with a retention period of 7 days. 7 days is a test condition, not a recommended value for actual operation.

The reference time is the time obtained by subtracting the retention period from the execution time. Messages with a timestamp earlier than that become deletion targets. The strict boundary comparison was verified by passing a fixed time to the public recipe's function, not via CLI. The deletion here refers to processing of body text fields, and does not confirm physical deletion from storage.

Even after deleting body text, the message metadata, incomplete items, audit events, and derived Memory remained. Files that had already been exported also remained.

Because body text and decision history are separated, even if the body text can no longer be read, how that item was handled can still be traced. This is the usage shown in the accompanying documentation. On the other hand, if the goal is to delete related information itself, processing that only deletes body text is insufficient.

What I want to decide for my own operations from here is how long to use derived knowledge. If body text is deleted after 7 days, how long can summaries created from it continue to be used? What about person information and decision history? These need to be decided separately for each storage location, independent of the source text retention period.

There is difficulty here between retaining a basis for decisions and deleting unnecessary source text. While I want to maintain the ability to return to source text to explain decisions, retaining source text indefinitely for that purpose may not align with the purpose of setting a retention period.

If adopting the original article's policy of updating and using knowledge, I want to make the handling when source text becomes inaccessible part of the update. Should it be re-confirmed with the person? Retained only as history? Should derived information also be deleted? I would decide this handling according to the purpose of the information and the purpose of storage.

Separating Memory Storage from Adoption in Decisions

So far, I've looked at the design philosophy of the original article and the behavior confirmed in the public recipe's storage processing. From here, I'll extend the concept of retrieving necessary context to a design for selecting which memories can be adopted for current decisions. The data examples and business cases below are concretizations of my own thinking and are not implementation specifications of the recipe. Decision quality and repair by actual LLM, resistance to external instructions, and continued operation in real environments are unverified.

I would separate the stage of storing records from the stage of adopting them into current decisions. This is because what was said in the past is not necessarily a currently valid instruction. In this design, I distinguish between expiration—when an instruction ceases to be used because its validity period or application conditions have ended—and deletion—when stored content is removed. Even if an expired instruction is retained as history, the retention period for storage is decided separately.

For example, suppose the instruction to prioritize incident response from the opening is recorded as follows. This example is YAML to show the information I want Memory to hold, not a configuration file to be passed directly to the recipe.

kind: temporary_instruction
statement: In this case, prioritize incident response over responding to customers
scope: This incident response for Case A
asserted_by: user
source_ref: Reference to the source text confirming the person's instruction
status: active
end_condition: Confirmation of recovery completion by the person
review_after: Start of next business day

end_condition is the condition for the instruction to end, and review_after is the timing for reviewing validity. The two are separated so that the mere arrival of the next business day is not treated as confirmation of recovery. In the explanatory example I've written in natural language, but in implementation I would include case identifiers, recovery confirmation records, and datetimes including timezone—values that the application can match against. Placing text alone does not mean conditions are automatically judged.

asserted_by: user also does not mean that if an LLM writes it freely, it becomes the person's instruction. It is set via the input path for corrections confirmed by the person, and is distinguished from candidates inferred by the agent. Even if an external message says "top priority," that alone does not elevate it to the person's instruction. Implementing this distinction and verifying permissions will be required separately.

When a search finds related records, I verify whether they can be applied to the target case, whether they have not ended, and whether they need reviewing. Conditions that can be formally judged are confirmed on the application side, and only valid instructions are selected for current decision input. When passing candidates or history to an LLM for investigation, they are distinguished as reference information rather than current instructions.

The judgment just before using a record divides into the following three, shown as a diagram.

This is the design proposal in this article, not the implementation specifications of the recipe. Whether to adopt for decisions and deletion of stored data are handled separately.

It does take effort to continuously update the scope of application and state, but it avoids adopting old instructions simply because they passed the structural inspection. Items whose validity cannot be confirmed are handled by asking the person rather than supplementing with inference.

Tracing Through Changing Priorities and Returning to Normal

I apply the flow shown in the original article—reflecting changes in situation and human corrections in subsequent decisions—to the fictional case from the opening. Here, I go one step further from honoring corrections, tracing all the way to ending the application of an instruction that is no longer needed.

In Case A, the person has decided that under normal circumstances, responding to customers takes priority. Because a failure occurred, a temporary exception was added to prioritize incident response until recovery is confirmed. This is a design example assuming that the normal policy and exception could be separately confirmed.

What matters in this flow is not so much the ability to lower and raise priority once, but that the reason to return to normal-time judgment remains. Not simply because a new message arrived, but because the end condition set by the person was satisfied, the application of the temporary exception ends. The explanation I'd want returned after recovery is something like the following:

Recovery for Case A has been confirmed, and the temporary instruction to prioritize incident response has ended.
Following the continuing valid normal policy, I'll start by preparing a draft response to the customer.

This is not actual LLM output, but an expected response example in the design. The goal of this case is to reach the point of not just remembering past instructions, but also explaining why they are not being applied now. Following the original article's policy of separating memory from permission to act, I'll stop here at preparing the draft response. Just the instruction to prioritize responses does not mean it's acceptable to send without the person's approval.

If the review timing arrives without recovery being confirmed, the state changes to "needs confirmation," new priority proposals are put on hold, and the person is asked to confirm. Neither reverting to the normal policy on its own, nor continuing to use the exception without confirmation, is done. What is put on hold here is the agent's prioritization, not an instruction to stop on-site incident response. If whether the normal policy is valid is also unclear, that is confirmed together.

For deletion as well, simply deleting the body text is not the end. In this example, the ended temporary instruction is chosen not to be used going forward, and its source text and derived summaries become deletion targets. Therefore, derived summaries also retain a reference to the original instruction like source_ref, so that records depending on the target instruction can be found. For summaries consolidating multiple pieces of information, removing the relevant portion or regenerating from remaining source texts is considered, and a blanket deletion of other cases is avoided.

If records have been replicated to search indexes or exports, their updates are also tracked. If the same body text has been copied and retained in correction history, that is also included in deletion targets.

On the other hand, if there is a requirement to retain something for auditing, rather than storing history indefinitely, I would first decide what items to retain, for how long, and who can access them. I'd want to think separately about whether it's necessary to replicate the original instruction content in the records of deletion processing. Explaining that backups and external storage are also deleted requires confirmation for each of those storage locations.

Of course, calling on a person for every confirmation increases the burden, defeating the purpose of an agent that handles things. I would make confirmations more thorough for decisions related to priority changes or externally-facing operations. Things like stylistic preferences that are easy to correct if wrong would be handled differently, and I'd want to avoid managing all Memory with the same strictness.

Selecting What Information to Store for Continuous Updates

The selective retrieval described in the original article is about extracting the scope needed for a task from stored knowledge. This is distinguished from reducing the stored information itself. In addition to that, I also wanted to select what to store long-term so that memory can continue to be updated.

For example, for information like order amounts or the latest deadlines where another system holds the authoritative record, I would first consider a design that references that authoritative record before making decisions. Even if values are copied to Memory, if updates can't be fully tracked, pathways to plausibly use outdated values increase. When memorizing, there is also the option of retaining not the value itself but where the current value can be confirmed.

Information that was looked up only once in the past may also be sufficient to simply search for the source text again when needed. Since search is a means of finding records, it can also be used to search organized Memory. The two are not mutually exclusive options. Whether finding source text or Memory, confirmation that the found record is still valid is necessary.

On the other hand, ongoing policies confirmed by the person, and background on cases that are frequently referenced, are information I'd want to use without re-reading history each time. From those, narrow down the targets, and store them with their origins and valid scope. If introducing long-term Memory, I'd start in that order.

The goal is not to make Memory small, but to avoid leaving context I want to reuse as outdated. This is not a conclusion reproducing the original article's performance evaluation, but an operational choice for starting within a range where I can continue updates and corrections.

Summary

What NVIDIA is showing is a Memory design that not only stores conversations, but organizes and updates business context and uses the necessary parts for decisions. Separating source material, derived knowledge, and the history of decisions and corrections, and reflecting what humans have corrected in subsequent decisions.

I want to extend this approach to cover the conditions for ending the application of instructions and the scope of deleting unnecessary derived information. As traced in the fictional case, not just honoring instructions during incident response, but returning to the valid normal policy after recovery. Rather than fixing and retaining what has been remembered, I want to think of keeping it in a state usable for the next decision—adjusting to changes in circumstances—as the operation of Memory.

Reference Links

• Building a Memory-Driven Agent with NVIDIA NemoClaw
• Memory-Driven Chief of Staff README
• Memory-Driven Chief of Staff fixtures
• memory_check.py
• Data lifecycle
• Trying out NemoHermes with a Hermes Agent on DGX Spark's OpenShell (Article from June 2026)