How to Give AI Agents Long-Term Memory with Redis
A practical look at using Redis as an MCP memory server so coding agents keep semantic, cross-session context instead of starting cold every time.
Why AI agents forget everything between sessions
Most AI agents have no memory once a session ends. Every new chat starts from zero: the agent doesn’t know your coding conventions, your past decisions, or what broke last time. That’s not a model limitation, it’s an infrastructure gap. Redis can fill that gap by acting as a persistent memory layer, accessed through a Model Context Protocol (MCP) server, that stores facts as searchable vectors so agents can recall them by meaning, not just keywords, across sessions.
TL;DR
- Agent failures usually trace back to context, not intelligence: broken relational links, stale data, and slow multi-hop queries make models “confidently wrong” even when reasoning is fine.
- Context engineering is bigger than prompt engineering: prompt engineering shapes a single instruction string, while context engineering is the runtime system deciding what data an agent sees at every step.
- Good context has to be navigable, fresh, fast, and compounding, meaning it links related entities, reflects live state, returns quickly, and gets richer the more the agent is used.
- Agents need two memory tiers: working memory for the active task (wiped after the session) and long-term memory for durable facts like project conventions and past fixes.
- Redis 8 can store memories as hashes with attached vector embeddings, which lets an MCP-connected agent search stored facts semantically instead of relying on exact keyword matches.
- A demo using a DeepSeek Coder model with a Redis MCP server showed an agent storing conventions in one session and applying them automatically in a brand-new session, without the user repeating instructions.
- Memory can grow passively: a plain conversation mentioning a preference (like using type hints) got extracted into long-term memory without an explicit save command.
What actually causes agents to fail in production?
Teams tend to assume an agent underperforming needs a bigger or newer model. In practice, three architectural problems show up repeatedly, and none of them are about model quality.
The first is a dead end: an agent looks up a customer support ticket but there’s no relational path to the associated order record because the two live in separate data silos. With nothing to retrieve, the model hallucinates an answer rather than admitting it can’t find one.
The second is stale state. The agent finds the right record, but it’s pulled from an outdated export, say twelve hours old. The underlying data (a package shipping) has since changed, but the agent confidently reports the old state as current, handing the user wrong information with total confidence.
The third is latency. The agent can find correct, current data, but doing so requires chaining multiple sequential calls across different APIs. By the time the answer comes back, the user has already given up and left the conversation.
In each case, the model’s reasoning holds up. What breaks is the pipeline feeding it information: no path to the data, outdated data, or data that takes too long to reach.
How is context engineering different from prompt engineering?
Prompt engineering operates on a single string: the wording of instructions, the examples included, the schema enforced on the output. It’s a useful lever, but it only affects what you say to the model in that one exchange.
Context engineering is the layer above that. It’s the system deciding, at every step of an agent’s execution, which customer record to pull, which live system state to check, and how to get that information to the model fast enough to be useful. Prompt engineering is the message. Context engineering is the infrastructure that decides what goes into that message and keeps it current.
What makes context “production-ready”?
Four mechanical requirements separate context that works from context that quietly breaks agentic systems:
Navigable. The agent needs to traverse relationships between entities (a user, their orders, their support tickets) rather than performing blind keyword lookups across unconnected text blobs.
Fresh. An agent acting on stale data doesn’t fail loudly, it fails confidently. Since agents don’t hedge the way a careful human might, out-of-date information becomes a wrong answer delivered with full certainty.
Fast. Any task requiring several sub-queries compounds latency at each hop. A workflow that needs eight round trips across three APIs isn’t a workflow that finishes before a user loses patience.
Compounding. This is the piece most setups skip entirely. When a session ends, context typically resets to zero. The same user returning tomorrow forces the agent to relearn who they are and what conventions apply. A production system that’s actually improving needs its context to accumulate rather than reset.
Why do teams struggle to build this themselves?
Built like a system. Not vibe-coded.
Remy manages the project — every layer architected, not stitched together at the last second.
The common failure pattern looks like this: one team builds an isolated vector database for document search. Another team rolls a custom persistence script over a separate store. A third stitches together a handful of tools. Each of these works fine in isolation.
The problem surfaces months later, when an organization ends up with a dozen disconnected data pipelines, none of which can guarantee freshness, and every new agent project has to rebuild the same context plumbing from scratch. Without a shared memory layer, context engineering becomes a repeated, siloed cost rather than shared infrastructure.
How do agents compound context across sessions?
Compounding context requires two distinct memory tiers.
Working memory is the active scratchpad for a task: immediate tool calls and their execution state. It’s meant to be temporary and gets wiped once the session ends.
Long-term memory stores durable facts that need to survive across sessions: project decisions, environment configuration, conventions, and edge cases discovered during debugging.
The hard part is moving facts from one tier to the other automatically. Manually tagging what’s worth remembering doesn’t scale, so an effective memory layer needs to parse conversations in the background and extract facts worth keeping. When a new session starts, it runs a semantic search against stored memory to pull only what’s relevant to the current task, rather than dumping the entire history back in. The system also needs to manage duplication and expiry so memory doesn’t turn into an unmanageable archive of noise, while still preserving permanent rules.
How does a Redis-backed MCP memory server work in practice?
A demonstrated setup connects a coding agent (running on a DeepSeek Coder harness with a DeepSeek model accessed via API) to a Redis agent memory server through MCP. Redis 8 stores each memory as a hash paired with a vector embedding, which allows retrieval based on meaning rather than exact keyword matches.
The integration itself is a YAML configuration pointing the harness at the MCP server, with a namespace in the URL scoping all stored memories to a specific project. Once connected, the agent can query the MCP server for available tools, typically including functions to create, search, edit, and delete memories.
In one session, telling the agent to use a specific dependency manager, a specific linter, and a specific coding style (pure functions returning new tuples) resulted in the agent checking memory first, finding it empty, then explicitly storing those three facts as separate long-term memories. Querying Redis directly showed the stored hash: the text of the fact, the namespace, the user, the topic, and its embedding.
A second, completely fresh session with no chat history was then given a coding task. Before touching any files, the agent called the search function against long-term memory, retrieved the stored conventions, and applied them automatically to new code, matching the described style without being told again. Verification steps (running tests and a linter) passed afterward.
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
Two further checks confirmed the behavior wasn’t just keyword matching. Asking about “which linter and package manager” the repo uses, using none of the literal words used in storage, still returned the correct stored facts ranked by semantic distance. Separately, a plain conversation mentioning a coding preference, without any explicit instruction to save it, still resulted in that preference being extracted into long-term memory automatically.
Is this approach worth adopting?
For anyone running agents across multiple sessions on the same project, the case is straightforward: the instructions and conventions repeated at the start of every conversation are exactly the kind of durable facts a memory layer is meant to hold. Storing them once and retrieving them semantically removes repetitive setup and reduces the chance of an agent drifting from established conventions. The tradeoff is added infrastructure: you now depend on a memory server staying available, scoped correctly by namespace, and pruned so it doesn’t accumulate irrelevant or contradictory facts over time. For a single-session, one-off task, the overhead isn’t worth it. For any agent expected to work on the same codebase or account repeatedly, persistent semantic memory addresses a real and common failure mode.
Frequently Asked Questions
What is context engineering in AI agents?
Context engineering is the system and infrastructure that decides what information an agent receives at each step of its work, such as which records to fetch and how fresh they are, as opposed to prompt engineering, which only shapes the wording of a single instruction.
How is Redis used as agent memory?
Redis can store agent memories as hashes with attached vector embeddings, accessed through an MCP server, so an agent can search past facts by semantic meaning rather than exact keyword matches, and retrieve only what’s relevant to its current task.
What’s the difference between working memory and long-term memory for agents?
Working memory holds the active task’s temporary state and tool calls, and is discarded when the session ends. Long-term memory holds durable facts, like project conventions or past decisions, meant to persist and be retrieved across future sessions.
Does adding memory to an agent slow it down?
The transcript’s demo showed the agent querying memory before reading files, adding a retrieval step, but avoiding it entirely can cost more time later through repeated instructions or wrong assumptions from missing context.
Can agent memory grow without explicit save commands?
Yes. In the demonstrated setup, a plain conversation mentioning a preference, without an explicit instruction to store it, was still automatically extracted and saved into long-term memory in the background.
