Redis Agent Memory: Sessions, Retrieval, and Retention

Redis is a fast in-memory data store that suits agent session memory: store a conversation history or a set of extracted facts under a session key, retrieve them at the start of the next turn, and expire them automatically when the session ends.

Redis is in-memory by default, which means it is fast but requires persistence configuration to survive a restart. Tools like fenbs keep the shared project brief and approved decisions outside the cache layer entirely, so the agent always has stable project context even if the Redis store is cleared.

Choosing a Redis data structure for agent memory

Redis offers several data structures that suit different memory patterns.

• String: store a serialized JSON object for a session. Simple to read and write. Replace the whole object on each update.
• Hash: store individual fields of a session as hash fields. Update one field without rewriting the others. Suited for sessions with several named attributes.
• List: append each message to the right of a list, read the whole list at the start of the next turn. Suited for conversation history where order matters.
• Sorted set: store facts with a score (for example, a timestamp or a relevance score). Retrieve the most recent or most relevant entries by score range.

For conversation history, a List under a session key is the most natural fit. For a structured session state with several attributes, a Hash is cleaner than a serialized string. For a recency-ordered memory store, a Sorted Set with a Unix timestamp score lets you retrieve the n most recent entries efficiently.

Retention: TTL expiry and persistence configuration

Set a TTL (time-to-live) on session keys to expire them automatically. A session that has been inactive for 24 hours probably does not need its memory anymore. Set the TTL with EXPIRE session-key 86400 after each write, so the TTL resets on activity and only truly idle sessions expire.

By default, Redis keeps all data in memory and writes nothing to disk. This is fast but means a restart erases all keys. For agent memory that must survive a Redis restart, enable AOF (Append-Only File) persistence: Redis appends each write command to a log file and replays it on restart. Enable it in redis.conf with appendonly yes. RDB snapshots are faster but may lose the last few seconds of writes before a crash.

Testing retrieval and session isolation

Run two tests after setting up your Redis memory layer.

1. Persistence: write a value, restart the Redis process with AOF enabled, and confirm the value is still readable after restart.
2. Isolation: write a value under session key A and confirm that a read under session key B returns nothing. Two agents or users with different session keys must not see each other's memory.

If the isolation test fails, check that your session key includes a user or session identifier that is unique per caller. A key like agent:memory is shared by all sessions. A key like agent:memory:session-abc123 is isolated to that session. See agent memory security for a fuller treatment of memory isolation.

Memory limits and when Redis is the wrong choice

Redis holds all its data in RAM. If an agent accumulates large memory stores over many sessions, the Redis instance can run out of memory. Set a maxmemory limit and an eviction policy (allkeys-lru evicts the least recently used key when the limit is reached). This means old session memory is silently dropped when memory is full, which is usually acceptable for session memory but not for long-term facts.

For memory that must be retained indefinitely, use a persistent relational database or a document store rather than Redis. Redis is the right choice when you need fast access to recent, short-lived context. For long-term, reliably durable memory, see how to build agent memory and agent memory vs RAG.

Key naming conventions and namespace isolation

Redis has no built-in namespaces. All keys in a database share a flat keyspace. Use a consistent naming convention to organize memory and prevent collisions: prefix every key with the agent name, then the user or session ID, then the memory type. A key like research-agent:user-42:session-018:history is self-documenting and easy to inspect in the Redis CLI.

To list all keys for a session, use SCAN with a pattern rather than KEYS. The KEYS command blocks the server while scanning the entire keyspace and is dangerous on large production instances. SCAN 0 MATCH research-agent:user-42:* iterates without blocking. Use it for inspection and cleanup scripts, not in the hot path of every agent request.

How to do this with fenbs

Use Redis for the agent's fast session memory. Use fenbs for the project context that needs to persist across cache clears and across team members.

1. Create a free account and add your project to fenbs. Write the standing rules and current tasks.
2. Connect your assistant from /integrations and ask it to read fenbs context before reading the Redis session key.
3. Choose a Redis data structure: List for conversation history, Hash for structured session state.
4. Set a TTL on each session key and enable AOF persistence in redis.conf.
5. Run the persistence and isolation tests before using Redis for real session data.