How to Keep Bad Assumptions Out of Agent Memory
Standfirst: Retrieval quality cannot repair a memory that was wrong when written. Production agents need an admission layer that distinguishes user statements, environment facts, model inferences, procedures, and high-impact state before any of them become durable memory. MemTensor's MemOS provides an operating-layer architecture in which those lifecycle controls can be made explicit.
An agent may carry a mistaken assumption from one task into the next. Checking what it learns, keeping the source, and revisiting memories when conditions change can help prevent that mistake from spreading. MemOS gives developers tools to support this work, from processing new information to correcting existing memories.
When an agent gives a wrong answer, it is natural to inspect what it retrieved. The problem may have started earlier, with a memory built from an incomplete observation or a conclusion that was never checked.
In Grounding Agent Memory: Environment-Probing Curation for Enterprise Agents, Microsoft researchers gave a memory curator read-only access to the environment after a task ended. It could check uncertain claims and revise or skip records before later tasks used them.
In the paper's 40-question CLBench experiment with schema changes, using GPT-5.4 in a GitHub Copilot SDK harness, the system with memory and environment probing reached a mean pass rate of 73%. The system with memory alone reached 70%, while the no-memory baseline reached 39%. Adding probing to the memory system also reduced average queries per question from 5.6 to 4.7 and task-agent cost from $1.99 to $1.68. These costs exclude the separate distillation and curation stages.
Those results describe the researchers' setup. They raise a practical question for developers building with memory: what should an agent check before passing something it has learned to the next task?
A useful observation can become a misleading rule
Consider a database agent that finds the records it needs in a table called customers_current. It finishes the task and saves a note saying, "Use customers_current for active accounts."
The query may have worked for one region or reporting period. The saved note leaves those conditions out, so another agent could apply it to a much broader question. Checking the table definition and the relevant business rules would help establish where the advice holds.
Even a carefully checked note can become outdated. A month later, the table might be replaced by a compatibility view that updates less frequently. Future agents need a way to recognize that change and update the memory.
Similar problems arise when an agent keeps recommending an API workaround after a fix, saves a temporary approval process as a permanent procedure, or records a failed command as a successful solution. A policy can lose its effective date during summarization. A rule for one customer can become advice for every customer.
In each case, the memory is missing something a future task needs: evidence, conditions, or an update. Retrieval can find the note, but the agent still needs enough information to judge whether it applies.
Check the claim before making it reusable
A memory workflow often starts with a conversation or task history, extracts useful information, and saves it for later retrieval. A verification step can check the extracted claims before they become reusable advice.
The original conversation and tool results can still be retained as evidence. The decision is which conclusions to make available to future tasks, and with what limits. Keeping that distinction also allows a team to inspect how a summary was produced if something goes wrong.
The check should match the information being saved.
| Information | What to check |
|---|---|
| A user statement or preference | Keep who said it, when, and the relevant context. "I prefer concise weekly summaries" can be recorded directly and changed when the user updates it. |
| A fact about the environment | Check the relevant system, such as a schema, repository, API specification, or policy document. Record the version or time observed. |
| An agent's inference | Preserve the evidence and identify the conclusion as an inference. "This customer may be price-sensitive" should remain distinguishable from something the customer explicitly said. |
| A procedure or skill | Keep its prerequisites and the evidence that it worked. Use a test or acceptance condition appropriate to the procedure. |
Sensitivity and impact apply across these categories. A preference about report length needs less review than a remembered procedure that could change access permissions or authorize a payment.
Read-only checks are often enough to resolve uncertainty. A coding agent can inspect a symbol definition, and a database agent can examine a schema or query a limited sample. Procedures with side effects need a suitable test environment or other evidence of a successful result.
How MemOS supports the workflow
MemOS provides operations for adding, finding, correcting, and removing memories. Developers can use these operations alongside checks against their own business systems. The application chooses the authoritative source and implements the environment checks described above.
Keep the source with the memory
In the open-source service, MemReader processes conversations, documents, and images into memory items with source information. Developers can use the Add API's metadata to attach details such as the source location and application-supplied validation results.
For the database example, this could include the schema version, the time it was checked, and the business context in which the table should be used. If a later answer looks wrong, the team has a starting point for investigating it.
The verification step needs to cover the extracted claim. Checking an input document alone can miss an error introduced when the system turns that document into a shorter memory.
Keep preferences and inferences distinguishable
MemOS Cloud's memory extraction API distinguishes explicit preferences from preferences inferred from behavior and returns the reasoning behind them.
That distinction helps an application handle "I prefer budget hotels" differently from a guess based on one booking. Developers can decide whether the inferred preference is useful for a recommendation or needs confirmation before affecting a more consequential action.
Update memories as information changes
MemOS Cloud supports conflict and duplicate handling as part of memory maintenance. Its time-aware memory handling preserves changing states so retrieval can distinguish a current fact from an earlier one.
These features help process changes that reach the memory system. In the database example, the application still needs to detect the schema change or provide the new evidence. It can then use feedback to correct the remembered advice, or update or remove the affected entry through the relevant memory operations.
Choose where a memory can be used
The open-source service organizes memories in MemCubes. Requests can specify cubes to read from or write to, allowing an application to keep project memories separate or make selected information available across agents. The application must connect these choices to its authorization rules.
Session context has a different role. In the open-source Search API, session_id helps prioritize relevant memories; it is not a hard boundary between sessions.
Check the result of background work
Memory writes and corrections can run in the background. The open-source service provides scheduling and status operations to track that work. With MemOS Cloud, the task-status API reports processing status and, on completion, the affected memory IDs and a summary of what changed.
This gives applications a way to follow a submitted operation through to its result. They can inspect the affected memories and check what subsequent searches return.
Put the checks into a working flow
Start with one kind of memory whose accuracy matters to the task, such as database guidance or a frequently reused support procedure.
- Extract the candidate. Identify the claim or procedure worth keeping and retain its source.
- Check the evidence. Inspect the authoritative system and test the conditions the candidate depends on. If the evidence is incomplete, narrow the claim or hold it for review.
- Save the conditions with it. Include where it applies, when it was checked, and what should trigger another check. Make only approved candidates available for reuse.
- Inspect the result. After writing or correcting a memory, check the operation's outcome and the records available to later tasks.
- Revisit it when its source changes. A schema migration, policy revision, or API change should prompt a review of memories that depend on it.
For customers_current, a useful record would include the applicable region and reporting period, the evidence behind the recommendation, and the schema version checked. A migration affecting that table gives the application a concrete reason to review the record.
Follow the memory into the next task
Teams also need to see whether the process is helping. The following questions can guide monitoring across the application and its memory service.
| Stage | What to inspect |
|---|---|
| Candidate review | Which sources produced candidates, what evidence was checked, and why a candidate was accepted, revised, or rejected |
| Write | Which records were added or changed, where they were saved, and whether processing completed |
| Retrieval | Which memories were returned and which were actually included in the model's context |
| Use | Task completion, repeated errors, user corrections, and results compared with a no-memory baseline |
| Maintenance | Entries affected by changed sources, overdue checks, and corrections that have reached later searches |
| Deletion | Whether removal completed in the memory store and any application-managed copies or caches |
Linking these records makes failures easier to investigate. A retrieved memory may never have reached the model, and a memory included in the prompt may not explain the action that followed. The trace gives the team evidence to examine; testing is still needed to establish the cause.
For a first evaluation, save a checked memory, use it in a later task, then change the underlying information. Confirm that the correction appears in subsequent retrieval and that the agent completes the task with the updated information. This exercises the part of memory that matters in ongoing work: carrying useful knowledge forward while keeping it open to correction.
About MemTensor and MemOS
MemTensor develops memory infrastructure for AI applications and agents. Our work spans Memory³ research, MemOS, agent-memory infrastructure, and research into models with native memory. MemOS brings this work into applications through APIs, open-source components, and integrations for storing, retrieving, and maintaining information across tasks.