Industry insight / T SALON

EDITORIAL

Why AI Agents Need to Know When a Memory Is Out of Date

An agent can recall an old project date accurately and still give the wrong answer. What separates thread memory from stored facts, and how metadata and correction APIs decide which version a later task actually uses.

Deciding which stored version of a project plan an agent should use
Deciding which stored version of a project plan an agent should use

TL;DR

  • Keeping both the original and the updated date is not enough; the agent still needs to know which one applies to the current task.
  • Metadata such as source, approval status and effective time separates an approved plan from an old draft or an open question.
  • A correction only counts once the next answer changes, so the memory that reaches the model has to be checked after an update.

An AI agent can remember a project plan correctly and still give the wrong deadline. Suppose a software release was planned for Thursday. Testing takes longer than expected, so the project lead moves it to the following Monday. In a new conversation, the agent finds the old brief and says the release is on Thursday.

The original brief really did say Thursday. The mistake is treating that old plan as the current one.

An agent that helps a team over several days or weeks needs more than a saved date. It also needs to know where the date came from, what it applies to, and whether the plan has changed.

Which date applies now?

LangGraph's documentation separates memory within one conversation thread from longer-term information shared across threads. This helps explain how information can remain available in later conversations.

Saving both dates still leaves a question: which one should the agent use? Monday is the current plan. Thursday may be the right answer when someone asks about the original plan, if that history is still available.

The newest message is not always a new decision. "Could we still make Thursday?" remains a question, even after Monday has been approved. The application needs to tell questions from decisions and know whose instructions can change the plan. Without that distinction, better retrieval may just find the wrong instruction faster.

Keeping useful details with each memory

MemOS, developed by MemTensor, offers one way to organize this work. The MemOS paper describes a unit called MemCube. It holds memory content and metadata: details used to identify, manage, and track the use of that memory.

For the release example, an application could store the date with its project, source message, approval status, and when it applies. These details help separate an approved plan from an old draft or an open question. They only help if the application has understood the message correctly.

In the open-source v2.0 architecture, MemReader processes inputs, MemScheduler handles background storage and indexing, and MemFeedback handles corrections. MemChat coordinates memory retrieval, response generation, and storage. Developers can inspect these components to see how information is captured and updated.

A correction needs to change the next answer

MemOS Cloud offers two ways to correct memory. The update API takes a memory ID and changes to its content or title. The feedback API takes feedback in plain language, along with user and conversation IDs.

One route edits a known record; the other lets the user describe a correction in conversation. The application still needs to treat "We have approved Monday" as a change, while keeping "Could we still make Thursday?" as a question.

After an update, check which memory reaches the next answer. An earlier summary may still contain Thursday even after one record has been changed to Monday. A successful update response is only part of the check.

Frequently Asked Questions

Why does an agent repeat a date that was already changed?
Because the stored brief was accurate when it was written. The defect is that the memory carries no signal that a later decision replaced it, so retrieval returns the old plan as if it were current.
Is storing the newest message enough to fix this?
No. A question such as "Could we still make Thursday?" arrives after the decision and is not a new decision. The application has to tell questions from approvals, and know whose instruction can change the plan.
What should be stored alongside a date or fact?
The project or scope it belongs to, the source message, its approval status, and when it takes effect. These fields let a later task separate an approved plan from a draft or an unanswered question.
How do you know a memory correction worked?
Check which memory reaches the next answer. An earlier summary can still contain the replaced value even after a single record has been updated, so a successful API response is only part of the verification.