Zep vs MemoryRouter: When Did a Fact Change?
A release decision changes on January 12. Your agent hears about it on January 20. Which date should memory use?
Both matter. One tells you when the decision applied. The other tells you when the agent could have known about it. Sorting memories newest first does not separate them.
This is a useful dividing line in the Zep vs MemoryRouter comparison. Choose Zep when your application needs structured fact-validity intervals. Choose MemoryRouter when you need the decision and its explanation available in another session or tool, with the agent interpreting the record.
Put a late correction in the evaluation
Use this synthetic fixture before wiring either system into a workflow. The dates below are hypothetical recording dates:
- January 5: "Beacon releases are scheduled for Fridays."
- January 20: "Beacon releases moved to Tuesdays, effective January 12. The review team changed its availability."
Then ask two different questions:
- What release day applied on January 15?
- What release day had been recorded by January 15?
The first answer is Tuesday, using the later correction. The second is Friday, because that was the information available at the time. A system that answers Tuesday to both has lost the distinction between history and hindsight.
Keep the reason for the change in the fixture. A scheduling agent needs the current day. An agent proposing another schedule change needs to know why Friday stopped working.
Zep gives the change a structured interval
Zep's fact documentation distinguishes four timestamps on a fact. created_at records when Zep creates the edge. valid_at and invalid_at describe when Zep infers the fact applies. expired_at records when Zep marks it invalidated.
That gives a late-arriving correction somewhere to go besides its arrival date. Zep uses episode content and reference_time to infer validity. Its example distinguishes "Bob works at Acme" from "Bob started working at Acme one week ago," even when both statements arrive on the same date.
The inference still needs checking against your fixture. Zep explicitly says those timestamps do not establish that the source content or the derived fact is true. An inferred interval is a representation you can inspect, not proof that the decision happened.
Preserve that representation when building the prompt. Zep's custom context guide says to include valid_at and invalid_at, and identify facts that are no longer valid. Stripping every search result down to its text throws away the distinction you selected the graph to keep.
MemoryRouter retrieves the record for the agent
MemoryRouter's MCP tools expose semantic search and date-window search. date_search_memories accepts a start date, an optional end date, and an optional relevance query. Returned memories carry timestamps and content.
That is a retrieval contract, not Zep's fact-validity contract. The documented store_memory tool takes memory content; it does not take separate valid_at and invalid_at fields. Put "effective January 12" in the saved decision rather than expecting a search window to encode it.
If the records were actually saved on January 5 and January 20, a January 15 cutoff could exclude the later correction. Retrieve that correction too when reconstructing the effective schedule. The agent has to distinguish dates in the content from the record's timestamp. The documented store_memory tool has no timestamp input, so saving this fixture today does not backdate the records.
This fits a different job: carrying the release decision and its rationale from one assistant to another. Connect both supported clients to the same vault, explicitly save the fixture, and inspect the retrieval in a fresh conversation. That demo tests retrieval of the dated content, not a reconstructed January storage window. Generic MCP use is model-directed; a connection alone does not guarantee that either save or search ran.