Your project used port 8080. The owner changed it to 9090. The agent retrieved the correction, then told the next session to use 8080 anyway.
Before changing your retriever, capture three separate things: which records were retrieved, which entered the answering context, and which support the final answer. Finding the correction and using it are different jobs.
Here is a small, original example you can adapt without adopting a new memory service.
Start with an explicit correction
Assume these facts are verified for the same owner and project. Dates describe when the configuration applies, not when an embedding was generated.
| ID | Record | Relationship |
|---|---|---|
| port-v1 | Cedar used port 8080 before November 10 | Previous valid configuration |
| port-v2 | Cedar uses port 9090 from November 10 | Owner-authorized correction superseding port-v1 |
| setup-note | Start Cedar on port 8080 | Derived instruction based on port-v1 |
Preserve source and scope on each record. A newer timestamp alone does not prove that a statement is authoritative, applies to the same project, or replaces an earlier instruction.
Case 1: Ask for the current value
Question: “Which port should Cedar use on November 13, 2026?”
Expected factual basis: port-v2. Expected answer: 9090.
Record whether port-v2 reached retrieval and whether port-v1 or setup-note still entered the final context as current instructions. If the correction never arrived, inspect ingestion, retrieval and eligibility. If it arrived but the answer uses 8080, inspect competing context and the answer's evidence selection. Do not assume a larger context window resolves the conflict.
Case 2: Ask a historical question
Question: “Which port did Cedar use on November 8, 2026?”
Expected factual basis: port-v1. Expected answer: 8080, explicitly describing the past.
A previous configuration can remain relevant to an authorized historical query without remaining eligible as a current instruction. Retain history only where retention and access rules allow it. An expired permission or deleted private record is not revived by calling the question historical.
This is a test-design distinction, not a promise that any particular memory backend supports historical queries.
Case 3: Inspect the dependent instruction
Question: “Can we reuse setup-note unchanged for the November 13, 2026 deployment?”
Expected decision: review or regenerate it before use. Its factual dependency, port-v1, was superseded. Changing one memory row while leaving a derived setup note active can reintroduce the old value.
Keep the dependency visible: setup-note depends on port-v1. A replacement note should cite port-v2 and have its own review record. Do not silently rewrite historical evidence as though it always said 9090.
Case 4: Keep an unverified claim separate
Add an imported note that says Cedar uses port 7070. It has a later timestamp but no authenticated source or established replacement relationship.
Expected decision: do not promote 7070 on timestamp alone. In this example, the verified owner correction remains the current basis; the imported claim remains unresolved. If conflicting authoritative evidence leaves the actual configuration uncertain, seek confirmation rather than guessing.
Run the diagnostic on your own system
Download the companion JSON and keep its expected decisions separate from the input when collecting an attempt. For each case, save:
- Retrieved record IDs and source/scope metadata.
- Exact context supplied to the answerer after filtering and formatting.
- Proposed answer and supporting record IDs.
- Whether the answer followed the requested time and respected dependent-record review.
The public answers make this a transparent debugging exercise, not a held-out model benchmark. The companion data is a new teaching format, not an import schema for your memory provider or an AOM product.
Why this distinction matters
The October 26 paper When Retrieval Is Not Enough: Obsolete Facts in Agent Memory studies obsolete competing statements in a specific MemoryAgentBench task. It separates retrieving an update from choosing that update when conflicting evidence is present. That supports inspecting both stages; it does not establish a failure rate for your production agent or a performance result for AOM.
Make memory corrections a repeatable workflow
Memory Lifecycle Desk provides four coordinated skills for reviewing new facts, reconciling corrections, retiring stale evidence and assembling task-specific context, with a local Python reference engine and worked examples.
Use it to organize review of supplied memory records and dependencies. It works alongside your existing agent and memory backend; connecting live writes is a separate integration.
One-time download, plus applicable tax. Python 3.10+ for local tooling. Commercial use included. See contents and purchase terms.