Add Redis Agent Memory Server as a memory type

[justin-cechmanek]

Is this a new feature, an improvement, or a change to existing functionality?

New Feature

How would you describe the priority of this feature request

Medium

Please provide a clear description of problem this feature solves

I want to extend NeMo Agent Toolkit to be able to use Redis Agent Memory Server as a MemoryManager. I want to implement this so that I can used the more advanced memory management offerings from Redis Agent Memory Server within Nvidia-nat.

Describe your ideal solution

NeMo already supports Memory modules and an Automatic Memory Wrapper Agent. These modules already include a basic Redis implementation. Redis Agent Memory Server offers more advanced and configurable automatic memory management as compared to the current Redis module. My proposal is to add Agent Memory Server as an additional offering, and not replace the current Redis module.

Additional context

I have linked the Redis Agent Memory Server above. I would like to begin this implementation and would appreciate guidance and feedback once I submit a PR.

Code of Conduct

• I agree to follow this project's Code of Conduct
• I have searched the open feature requests and have found no duplicates for this feature request

[AnuradhaKaruppiah]

@mnajafian-nv Can you pls take a look a this?

[justin-cechmanek]

Hi @AnuradhaKaruppiah and @mnajafian-nv. I've opened a draft PR to begin addressing this. I'll tag a few other people interested in this work also.

[zhuamber370]

+1 on adding Redis Agent Memory Server as an additional option (not a replacement).

A practical way to keep this maintainable is an adapter contract with strict parity tests against existing memory managers: namespace semantics (tenant/agent/session), deterministic IDs, filter behavior, and error normalization.

I’d also add a degradation path for temporary memory-server outages (queue/retry + bounded local fallback), so workflows don’t fail hard on transient infra issues.

Would it help if this issue tracked a small acceptance matrix (p95 read/write latency, retrieval hit quality, and migration compatibility)?

[mnajafian-nv]

Thanks for the proposal and draft PR @justin-cechmanek. I've gone through the draft PR (#1702), the agent-memory-client SDK docs, and the Agent Memory Server documentation.

There's real potential here! NAT already ships three memory backends (self-hosted Redis, Mem0, Zep Cloud), each with a distinct use case. I want to make sure Agent Memory Server lands with the same clarity, so NAT users know exactly when and why to reach for it.

Looking at the current PR, it implements MemoryEditor (add/search/remove) against the long-term memory API. At that level, it covers similar ground to our existing nvidia_nat_redis plugin. Where I see Agent Memory Server's real differentiation is in its more advanced capabilities: two-tier memory (working + long-term), automatic summarization, forget policies, and the memory_prompt API.

I'd like to set up a short call to align on scope before doing a detailed code review. Specifically:

• What should v1 scope look like so Agent Memory Server's unique capabilities (e.g., two-tier memory, forget policies) are front and center?
• How should working memory and lifecycle management surface in NAT's config and agent wrappers?
• Maintenance expectations: our team has historically maintained shipped plugins long-term, so we need to understand agent-memory-client stability given it's pre-1.0

Would you be open to a 30 min sync so we can align on an optimal path?

[AnuradhaKaruppiah]

Thx @mnajafian-nv. Agree with your suggestions, the design/purpose (and use-case interest) needs to be hashed out first.