Redis Agent Memory vs MemoryRouter: Two Retention Clocks

John Rood··4 min read

A conversation expires after a day. A fact extracted from it remains searchable for a year.

That can be the retention policy you wanted. It can also be the one you never meant to configure. Redis Cloud's Agent Memory setup guide documents those defaults: 24 hours for session memory, 365 days for long-term memory.

Redis Agent Memory and MemoryRouter both support memory beyond one conversation. Decide what should stop being available, and when. If your application needs configurable automatic expiry, evaluate Redis's TTL controls. If you want decisions available across supported AI tools, MemoryRouter offers a shared vault with explicit deletion, not those two TTL settings in its documented MCP interface.

The conversation and its extracted facts have separate clocks

Redis Agent Memory stores conversation events in session memory. Its background extraction creates separate long-term memories from useful information in those events. The long-term memory guide explicitly says to configure the long-term TTL separately from the session TTL.

Changing the short-term setting is therefore not a policy for both layers. A one-day conversation history and a year of extracted preferences are a deliberate combination, not a contradiction.

That distinction matters when someone asks for a short-lived assistant. Does "keep this for a week" mean the conversation, the extracted facts, or both? Write down the answer before choosing settings. Redis's session guide says expired session events are no longer available through session-memory retrieval. Do not read that as a statement that every derived memory has expired too.

These are documented application-retrieval behaviors, not a claim about backup erasure or a compliance certification.

Updating a fact can restart its lifetime

Redis documents that a long-term memory replacement with PUT restarts its TTL. Most PATCH updates do too. A patch changing only namespaceId preserves the existing expiration instead.

A 30-day lifetime that restarts on an update is different from deletion 30 days after initial collection. If the latter is your requirement, changing a preference or reorganizing a record needs to be part of the retention evaluation. Setting a duration alone does not establish that deadline.

Use the current update contract when designing that workflow. Do not assume the creation timestamp determines expiry after every write.

MemoryRouter exposes deletion rather than a TTL on each save

We built MemoryRouter so useful conversational context can be retrieved in another session or supported tool. Its MCP interface connects each authorized client to the vault selected during sign-in. store_memory accepts content and optional tags. It does not expose a TTL parameter.

The controls are explicit. delete_memories deletes listed memory IDs; forget_all_memories deletes the connected vault's entire memory. Both require delete scope and their exact confirmation phrase. Read or write permission alone does not authorize deletion.

Reflections need their own attention. Consolidation keeps source memories and adds higher-level entries. Deleting a raw memory does not delete reflections built from it. The same documentation exposes inspect_memory for examining that lineage. Removing one source is not a promise that its information is absent from every reflection.

A date filter is not a substitute. date_search_memories narrows a retrieval window and has no deletion side effect. Asking only for this week's memories does not establish a one-week retention policy.

Choose the policy before connecting real work

For work you want to continue across supported assistants, the MemoryRouter MCP setup connects them to the same selected vault. Saved memory goes to MemoryRouter's servers; this is not a local-only store. Generic MCP capture and retrieval remain model-directed. Inspect the save and search results rather than assuming a connection proves either action ran.

Use a disposable fact for that first check, and review the deletion controls before sending anything you cannot retain.

Create a MemoryRouter vault.