[Feature Request]: Agent Memory Explorer

Problem description:

Teams building agents on Redis agent memory (the OSS agent-memory-server or the Redis Cloud agent memory service) need an intuitive User Experience for inspecting what their agents store.

Currently, checking a session's working memory, the extracted long-term memories, or the computed summary views means direct API calls or reading raw Redis keys.

Proposal: an Agent Memory explorer in RedisInsight as a top-level tab, displaying:

• Endpoint management for both backends (OSS server and Redis Cloud), API keys encrypted at rest.
• Working memory per user/namespace/session: messages with roles, timestamps, and extraction status, session TTL and running summary, injecting events (including creating new sessions), clearing a session.
• Long-term memory: semantic + keyword search, filters (user/owner, namespace, sessions, memory type, topics, entities), click-to-filter cards, per-record delete, copy key/session id.
• Summary views: browse LLM-computed profiles, recompute a profile, generate an empty view, create default views, delete a view.
• Auto-refresh option to fetch and view the updated working memory and long-term memory automatically.
• Store configuration screen

How often do you encounter this problem

Every debugging or development session against an agent memory server - there is currently no visual tooling for this data. I have been developing demos that uses Redis for agent memory, and often have needed to give learners and teams a clear understanding of how extraction, search, and retention actually behave.

Alternatives considered:

1. Direct API calls / curl: no visualization, no cross-referencing between working and long-term memory.
2. Reading raw Redis keys in the RedisInsight Browser: but it's not very intuitive
3. App-specific memory panel UI for web apps that uses Redis for agent memory: however we end up having to create and bake in the same custom viewer every single time for each app.
4. A standalone browser-extension inspector: Works, and built it as a solution to above 3. But can't be used on-prem alongside existing RedisInsight workflows and requires separate distribution.